Azure propose-t-il https pour "cloudapp.net"?
L’utilisation de Azure Websitesconstitue un grand avantage: je peux obtenir un protocole HTTP sécurisé (HTTPS) sans rien faire: je tape simplement https://xyz.azurewebsites.net et cela fonctionne. Je n'ai pas à m'inquiéter des certificats car j'utilise le sous-domaine qu'Azure me fournit (dans l'exemple, il s'agirait de xyz)
Donc, ce que je fais habituellement, c’est que les gens passent par un domaine enregistré que j’ai, par exemple. http://www.my-application-homepage.com, et là, s’ils veulent utiliser mon application, je les redirige vers le sous-domaine à azurewebsites.net, en utilisant HTTPS.
Maintenant, après avoir dit que:
J'ai besoin d'une mise à niveau vers Azure Cloud Services ou Machines virtuelles Azure , car ces fonctionnalités ont des fonctionnalités qui Sites Web Azure n'ont pas. Ces deux offrent également un sous-domaine gratuit: xyz.cloudapp.net, mais ma question est la suivante: vais-je également obtenir le protocole HTTPS? et comment?
J'ai cherché dans google quelques exemples de cloudapp et ce que j'ai testé est le suivant:
1) Connectez-vous via HTTP (par exemple, tapez http://xyz.cloudapp.net). Résultat: travaillé
2) Connectez-vous via HTTPS (c.-à-d. Tapez https://xyz.cloudapp.net). Résultat: n'a pas fonctionné (chrome a donné ERR_CONNECTION_TIMED_OUT)
Non. HTTPS n'est pas proposé pour le domaine .cloudapp.net à compter d'aujourd'hui. De plus, comme vous ne possédez pas de domaine .cloudapp.net, je ne pense pas que vous puissiez acheter un certificat SSL pour cela. Si vous le souhaitez, vous pouvez créer un certificat auto-signé et l'utiliser.
Je parcourrais la documentation énumérée ici: http://Azure.Microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/
Comme vous obtenez un délai d’expiration avec HTTPS (plutôt qu’une erreur de certificat), vérifiez que vous avez un point de terminaison HTTPS défini dans ServiceDefinition.csdef.
De plus, sachez que l'approche de redirection vers un sous-domaine n'est pas beaucoup plus sécurisée que l'utilisation d'un certificat auto-signé. La raison pour laquelle les navigateurs rejettent les certificats auto-signés est qu’ils sont vulnérables aux attaques par usurpation: un utilisateur ne peut pas détecter si un attaquant a, par exemple, détourné le DNS pour qu'il pointe vers son adresse IP plutôt que la vôtre, où il héberge votre site qui ne fait que collecter des mots de passe ou autre chose.
Dans votre scénario, le site cloné pourrait rediriger vers un autre clone, une façade de votre site cloudapp.net. Il pourrait même être sécurisé avec le certificat SSL de l'attaquant. À moins que l'utilisateur soit formé à reconnaître le nom d'hôte du vrai cloudapp.net, elle ne saura pas qu'elle se trouve sur le site "sécurisé" de l'attaquant.
** Mise à jour: Cette méthode n’est pas valide non plus, le certificat a été révoqué après une semaine d’utilisation **
Nous utilisons cette approche pour les serveurs de staging/dev:
Si vous ne souhaitez pas utiliser un certificat auto-signé, vous pouvez acheter un certificat SSL bon marché, par exemple:
https://www.ssls.com/comodo-ssl-certificates/positivessl.html
Ensuite, une fois que vous devez l’approuver, vous devez demander à l’assistance technique de modifier le processus de validation de l’approbateur: au lieu d’envoyer un email à [email protected], vous pouvez demander à changer le processus de validation pour placer un fichier donné avec un fichier donné à la racine de votre site Web (vous devez vous renseigner sur cette option dans l'assistance/le chat room).
Plus d'informations: