Aller au contenu

AWS Mis à jour le 2026-09-29

Domaine personnalisé et HTTPS sur CloudFront : les certificats ACM bien faits (le piège us-east-1)

Mettez votre propre domaine en HTTPS sur une distribution CloudFront en demandant le certificat ACM dans us-east-1, en le validant par DNS et en réglant l'erreur CNAMEAlreadyExists quand un nom d'hôte est déjà pris.

Vous voulez que www.example.com s’affiche en HTTPS depuis votre distribution CloudFront, le réseau de diffusion de contenu (CDN) d’AWS qui sert votre site à partir de serveurs proches de vos visiteurs. Le certificat vient d’ACM (AWS Certificate Manager, le service de certificats d’AWS) et doit être demandé dans la région us-east-1, peu importe la région du reste de votre infrastructure. Validez-le avec un enregistrement DNS : il pourra alors se renouveler tout seul.

Ensuite, ajoutez le nom d’hôte à la distribution comme nom de domaine alternatif, puis pointez le DNS vers la distribution avec un enregistrement alias Route 53. Route 53 est le service DNS d’AWS, et un enregistrement alias fonctionne comme un CNAME qu’AWS résout lui-même. Dans cet ordre, la mise en place prend une vingtaine de minutes, plus le délai de validation.

Ce qui se passe

CloudFront termine le TLS en périphérie : le certificat présenté aux navigateurs appartient à la distribution, pas à votre origine. Les distributions sont des objets mondiaux gérés depuis us-east-1, et c’est pourquoi le menu déroulant de certificats de la console ne liste que ceux de cette région — un certificat soigneusement émis dans ca-central-1 à côté du reste de votre pile est invisible pour CloudFront. Ce seul fait explique la majorité de la confusion : le certificat n’est pas « disparu », il est dans la mauvaise région, et les certificats ACM ne se copient pas entre régions. Vous en demandez un nouveau là où il doit être.

Deux autres mécaniques encadrent le montage. Un, le nom de domaine alternatif (la console appelle encore le champ CNAME pour des raisons historiques) doit être listé sur la distribution et couvert par le certificat attaché — CloudFront refuse l’association sinon. AWS impose aussi l’unicité mondiale : un nom d’hôte donné ne peut être attaché qu’à une seule distribution à travers tous les comptes AWS, d’où l’erreur CNAMEAlreadyExists pendant les migrations. Deux, la validation : les certificats validés par DNS se renouvellent automatiquement tant que le CNAME de validation reste dans la zone. Supprimez ce drôle d’enregistrement _a1b2c3.example.com pendant un ménage de zone et le renouvellement échoue silencieusement des semaines plus tard, avec une expiration dans un an.

Le service des certificats utilise SNI par défaut, supporté par tous les navigateurs de la dernière décennie et sans frais. L’option héritée à IP dédiée existe pour des clients très anciens et porte des frais mensuels fixes très difficiles à justifier en 2026 — ne l’activez pas par accident.

Quoi vérifier en premier

  • Dans quelle région est le certificat? aws acm list-certificates --region us-east-1 — s’il n’est pas dans cette liste, c’est tout le problème.
  • Le certificat couvre-t-il le nom exact? www.example.com n’est pas couvert par un certificat pour example.com seul; un joker *.example.com couvre www mais ni l’apex ni a.b.example.com.
  • Le statut du certificat est-il ISSUED? PENDING_VALIDATION signifie que l’enregistrement de validation est manquant ou erroné.
  • Le nom de domaine alternatif est-il réglé sur la distribution? Un DNS pointant vers une distribution qui ne liste pas le nom retourne un 403 avec une page d’erreur CloudFront.

Comment vérifier

# Demander le certificat là où CloudFront peut le voir
aws acm request-certificate \
  --domain-name www.example.com \
  --subject-alternative-names example.com \
  --validation-method DNS \
  --region us-east-1

# Obtenir les enregistrements de validation DNS à créer
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abcd-1234 \
  --region us-east-1 \
  --query 'Certificate.DomainValidationOptions[].ResourceRecord'

# Après le passage à ISSUED, vérifier ce que la périphérie présente réellement
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName -enddate

Si la zone est chez Route 53, la console ACM offre un bouton Create records in Route 53 qui écrit les CNAME de validation pour vous — Certificate Manager (us-east-1) > Certificates > (certificat) > Create records in Route 53. Le côté distribution vit sous CloudFront > Distributions > (id) > General > Settings > Edit, où les noms alternatifs et le menu du certificat SSL personnalisé se trouvent ensemble.

Le runbook

  1. Demandez le certificat dans us-east-1 avec validation DNS. Mettez tous les noms que la distribution servira sur un seul certificat — example.com et www.example.com en noms alternatifs, c’est la paire courante. La validation par courriel existe encore et ne devrait pas être utilisée : elle ne se renouvelle pas sans intervention.
  2. Créez les CNAME de validation et attendez ISSUED. Quelques minutes quand la zone est chez Route 53 et que le bouton a fait le travail; plus long quand un hébergeur DNS externe lent est impliqué.
  3. Attachez le certificat et les noms alternatifs à la distribution. Les deux dans la même modification. Réglez la politique de protocole visiteur des comportements sur Redirect HTTP to HTTPS, et laissez la politique de sécurité à la version TLS moderne recommandée, sauf si une population de vieux clients dit le contraire.
  4. Pointez le DNS vers la distribution. Un alias Route 53 (A, plus AAAA — CloudFront parle IPv6) vers le nom d1234abcd.cloudfront.net. L’apex exige un alias plutôt qu’un CNAME, un sujet à part entière couvert dans les domaines apex sur AWS.
  5. Traitez CNAMEAlreadyExists délibérément. Le nom est attaché à une autre distribution quelque part — souvent un prédécesseur dans la même entreprise, parfois un tout autre compte. Retirez-le de l’ancienne distribution d’abord; pour un déménagement impossible à coordonner, le soutien AWS peut aider avec le processus de conflit, documenté sous les plans de soutien AWS.
  6. Vérifiez de bout en bout. curl -sv https://www.example.com/ -o /dev/null — chaîne de certificats, HTTP/2 et un en-tête x-cache prouvent que vous frappez CloudFront avec un TLS valide.

Quand c’est la mauvaise approche

Si l’application a besoin du certificat sur une ressource régionale — un ALB, un point de terminaison régional API Gateway —, le certificat appartient alors à la région de cette ressource, et us-east-1 y est une erreur. La règle us-east-1 est propre à CloudFront. De même, ne mettez pas un domaine personnalisé sur CloudFront pour régler un problème qui relève du routage d’origine : le TLS côté visiteur est séparé du TLS côté origine, et CloudFront valide le certificat de l’origine contre le nom de domaine d’origine — une discordance là produit des 502, pas des avertissements de certificat, un mode d’échec couvert dans la liste de contrôle des 502/504 CloudFront.

Erreurs fréquentes

  • Émettre le certificat dans la région du projet, puis le chercher dans le menu déroulant de CloudFront.
  • Supprimer l’enregistrement de validation DNS après l’émission, ce qui brise discrètement le renouvellement automatique.
  • Confusion de joker : croire que *.example.com couvre l’apex, ou couvre deux niveaux d’étiquettes — il ne fait ni l’un ni l’autre.
  • Mettre le DNS à jour avant que la distribution liste le nom alternatif, servant aux usagers un 403 CloudFront pendant l’intervalle.

Prévention

  • Documentez une convention « certificats de périphérie dans us-east-1 » pour que personne ne se raisonne un retour dans le piège régional.
  • Créez une alarme sur la métrique DaysToExpiry d’ACM pour chaque certificat de périphérie; un certificat validé par DNS qui ne se renouvelle pas y apparaît bien avant que les navigateurs se plaignent.
  • Traitez les CNAME de validation comme de l’infrastructure permanente — étiquetez-les dans l’IaC et commentez pourquoi ils existent.
  • Relancez la vérification openssl après chaque changement de certificat; la périphérie met brièvement la configuration TLS en cache, et vérifier bat supposer.

Les exigences complètes des certificats sont dans la documentation CloudFront, et une fois le TLS fonctionnel, le comportement de cache est la prochaine chose à soigner. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.