Est-il possible d'utiliser HTTPS avec les CDN et CNAME CloudFront d'Amazon?
Nous utilisons le CDN CloudFront d'Amazon avec des CNAME personnalisés suspendus sous le domaine principal (static1.example.com). Bien que nous puissions casser cette apparence uniforme et utiliser les URL originales quel que soit 123wigglyw00.cloudfront.net pour utiliser HTTPS, existe-t-il un autre moyen?
Est-ce qu'Amazon ou un autre fournisseur similaire propose l'hébergement HTTPS CDN?
TLS et son chiffrement sélectif sont-ils disponibles pour une utilisation quelque part (SNI: Server Name Indication)?
Note de bas de page: en supposant que la réponse est non, mais simplement dans l'espoir que quelqu'un le sache.
MODIFIER: utilisez maintenant Google App Engine https://developers.google.com/appengine/docs/ssl pour Hébergement CDN avec support SSL.
CloudFront avec CNAME et HTTPS n'est pas pris en charge, voir la première note dans le documentation CloudFront CNAME .
Je ne pense pas que les CDN à faible coût prennent en charge les CNAME et HTTPS ensemble. Pour ce faire, ils auraient besoin d'un moyen de télécharger votre certificat non crypté sur leur réseau CDN.
VEUILLEZ NOTER LES MODIFICATIONS ET LES MISES À JOUR CI-DESSOUS
Dès que j'ai écrit ceci (23 mai 2012), SSL est pris en charge via l'URL de distribution CloudFront. seulement. Signification, vous ne pouvez pas CNAME l'URL SSL. Concrètement, vous pouvez référencer un élément via SSL en tant que:
https://[distribution].cloudfront.net/picture.jpg
mais non:
https://cdn.mydomain.com/picture.jpg
où cdn.mydomain.com est un CNAME pour [distribution] .cloudfront.net. À l'heure actuelle, vous obtiendrez des erreurs SSL.
Cela signifie que vous ne pouvez pas utiliser votre nom de domaine ou votre certificat SSL. Cela peut entraîner des problèmes avec les stratégies interdomaines dans le navigateur, ainsi qu'une complexité supplémentaire pour la maintenance d'un site.
Le personnel d’AWS nous a assuré que la prise en charge HTTPS des CNAME de distribution figurait dans leur liste de fonctionnalités, mais qu’elle avait besoin de la communauté pour la définition des priorités. Pour vous aider dans cet effort, veuillez remplir l’enquête CloudFront (voir ci-dessous) et noter cette demande de fonctionnalité. Le personnel AWS utilise les données collectées à partir de l'enquête pour planifier et hiérarchiser la feuille de route CloudFront.
Assurez-vous de noter que la prise en charge de HTTPS CNAME est nécessaire lorsque vous répondez à l'enquête CloudFront: http://aws.qualtrics.com/SE/?SID=SV_9yvAN5PK8abJIFK
EDIT: A noté dans un article du 11 juin 2012 qu'AWS avait mis à jour le lien de l'enquête:
Nouveau lien de sondage: http://aws.qualtrics.com/SE/?SID=SV_e4eM1cRblPaccFS
Je pense que cela vaut la peine de leur donner le retour d’information sur la prise en charge de CNAME + SSL.
EDIT: Annoncés le 11 juin 2013, les certificats SSL personnalisés avec des adresses IP dédiées sont désormais pris en charge avec CloudFront sur AWS:
Voir l'annonce de la fonctionnalité sur le blog AWS: http://aws.typepad.com/aws/2013/06/custom-ssl-domain-names-root-domain-hosting-for-Amazon-cloudfront.html
Un élément à considérer avant de compter sur cette route, vous devez voir la valeur significative de la déviation de la route https: // [distribution] .cloudfront.net car le prix est de 600 $ US par mois pour l'hébergement certificats SSL personnalisés.
EDIT: Annoncé le 5 mars 2014, des certificats SSL personnalisés à l'aide de l'indication de nom de serveur (SNI) sont désormais pris en charge avec CloudFront sur AWS - NO. FRAIS ADDITIONNELS:
AWS prend désormais en charge les certificats SSL personnalisés via SNI. C'est énorme car cela ouvre la possibilité de tirer parti de l'infrastructure existante d'AWS (adresses IP). En tant que tel, AWS ne facture pas de supplément pour ce service! Pour en savoir plus, consultez l'article sur le blog AWS: http://aws.typepad.com/aws/2014/03/server-name-indication-sni-and-http-redirection-for-Amazon -cloudfront.html
Un élément à noter cependant, l’indication de nom de serveur (SNI) présente certains inconvénients qu’il convient de prendre en compte avant de s’y fier complètement. En particulier, il n'est pas pris en charge par certains navigateurs plus anciens. Si vous voulez mieux comprendre cela, voir: https://stackoverflow.com/questions/5154596/is-ssl-sni-actually-used-and-suppsu-supported-in-browsers
EDIT: AWS a annoncé le 21 janvier 2016 qu'ils fourniraient GRATUITEMENT des certificats SSL personnalisés!
Pour en savoir plus sur l'annonce complète sur le site AWS: https://aws.Amazon.com/blogs/aws/new-aws-certificate-manager-deploy-ssltls-based-apps-on-aws/
Amazon a annoncé un nouveau service appelé AWS Certificate Manager, qui offre des certificats SSL/TLS gratuits pour les ressources AWS.
Ces certificats sont généralement achetés auprès de fournisseurs de certificats tiers tels que Symantec, Comodo et RapidSSL et peuvent coûter entre 50 USD et plusieurs centaines de dollars, en fonction du niveau de vérification de l'identité effectuée.
L'obtention d'un nouveau certificat a toujours été un peu compliquée, nécessitant la génération d'une demande de signature de certificat sur le serveur protégé, l'envoi de cette demande à un fournisseur de certificat, puis l'installation du certificat une fois qu'il a été reçu. Étant donné qu'Amazon gère l'ensemble du processus, tout cela disparaît et les certificats peuvent être rapidement émis et provisionnés sur les ressources AWS automatiquement.
Il existe quelques limitations aux certificats. Amazon ne fournit que des certificats validés par le domaine, une vérification simple dans laquelle la validation du domaine est effectuée par courrier électronique. Si vous souhaitez un certificat de validation étendue, vous pouvez vous en tenir à leurs fournisseurs de certificats actuels. De plus, les certificats ne peuvent pas être utilisés pour la signature de code ou le cryptage de courrier électronique.