page officielle des limites Let’s Encrypt<\/a> pour les valeurs \u00e0 jour, notamment si vous g\u00e9rez des environnements multi-tenant ou des d\u00e9ploiements automatis\u00e9s \u00e0 grande \u00e9chelle.<\/p>\n\n\n\nPi\u00e8ge 1 : DNS pas encore propag\u00e9.<\/strong> Lancer Certbot avant que le DNS de votre domaine pointe vers le serveur est l’erreur num\u00e9ro un. La validation HTTP-01 de Let’s Encrypt doit pouvoir atteindre votre serveur depuis Internet. V\u00e9rifiez la propagation avec dig monsite.com +short<\/code> avant de lancer Certbot. Si l’IP affich\u00e9e n’est pas celle de votre serveur, attendez que le TTL expire.<\/p>\n\n\n\nPi\u00e8ge 2 : Coexistence de l’ancienne installation apt et du nouveau snap.<\/strong> Ubuntu installe parfois python3-certbot-nginx<\/code> via des d\u00e9pendances. La coexistence des deux versions provoque des comportements impr\u00e9visibles. V\u00e9rifiez avec which certbot<\/code> que le binaire pointe vers \/snap\/bin\/certbot<\/code>. Si ce n’est pas le cas, supprimez le paquet apt et reliez le symlink.<\/p>\n\n\n\nPi\u00e8ge 3 : Activer HSTS avec includeSubDomains pr\u00e9matur\u00e9ment.<\/strong> Si un sous-domaine ne dispose pas d’un certificat HTTPS valide, les navigateurs qui ont m\u00e9moris\u00e9 la r\u00e8gle HSTS rendront ce sous-domaine totalement inaccessible jusqu’\u00e0 l’expiration du max-age. Testez d’abord sans includeSubDomains<\/code>, et ajoutez cette directive uniquement quand tous vos sous-domaines sont couverts.<\/p>\n\n\n\nPi\u00e8ge 4 : Oublier le hook de rechargement Nginx.<\/strong> Apr\u00e8s un renouvellement, Nginx continue de servir l’ancien certificat jusqu’au prochain red\u00e9marrage. Sans le hook dans \/etc\/letsencrypt\/renewal-hooks\/deploy\/<\/code>, votre site affichera un certificat expir\u00e9 \u00e0 90 jours pr\u00e9cis, en pleine nuit, sans que vous l’ayez anticip\u00e9.<\/p>\n\n\n\nPi\u00e8ge 5 : Tester avec le domaine de production sans passer par le staging.<\/strong> Cinq demandes de certificat identiques \u00e9chou\u00e9es en 7 jours d\u00e9clenchent un blocage de 7 jours. Utilisez toujours le flag --staging<\/code> pour les premi\u00e8res tentatives, puis supprimez le certificat de staging (sudo certbot delete --cert-name monsite.com<\/code>) avant d’\u00e9mettre le certificat de production.<\/p>\n\n\n\nPi\u00e8ge 6 : add_header sans le mot-cl\u00e9 always.<\/strong> En Nginx, la directive add_header<\/code> sans always<\/code> n’envoie l’en-t\u00eate que sur les r\u00e9ponses de code 200, 201, 204, 206, 301, 302, 303, 304, 307 et 308. Mais si vous avez un bloc location<\/code> enfant qui d\u00e9finit ses propres add_header<\/code>, les en-t\u00eates du bloc parent sont compl\u00e8tement \u00e9cras\u00e9s pour ce contexte. La solution : regroupez tous vos en-t\u00eates de s\u00e9curit\u00e9 dans un fichier s\u00e9par\u00e9 (\/etc\/nginx\/security-headers.conf<\/code>) et incluez-le dans chaque bloc location<\/code> qui en a besoin.<\/p>\n\n\n\nPi\u00e8ge 7 : Chemin de challenge ACME inaccessible derri\u00e8re un reverse proxy.<\/strong> Si Nginx proxifie vers une application backend, le bloc location \/<\/code> intercepte les requ\u00eates ACME de validation HTTP-01 avant qu’elles n’atteignent le r\u00e9pertoire de challenge. Ajoutez toujours une exception explicite avant le bloc de proxy :<\/p>\n\n\n\n location \/.well-known\/acme-challenge\/ {\n root \/var\/www\/html;\n allow all;\n }\n\n location \/ {\n proxy_pass http:\/\/localhost:3000;\n }<\/code><\/pre>\n\n\n\nD\u00e9pannage : 8 erreurs fr\u00e9quentes et leurs solutions<\/h2>\n\n\n\nErreur “Connection refused” lors de la validation HTTP-01<\/h3>\n\n\n\n
Let’s Encrypt ne peut pas joindre votre serveur sur le port 80. V\u00e9rifiez dans cet ordre : UFW autorise le port 80 (sudo ufw status<\/code>), Nginx est lanc\u00e9 (sudo systemctl status nginx<\/code>), aucune r\u00e8gle de pare-feu externe ne bloque le port 80. Testez depuis une machine externe avec curl -v http:\/\/monsite.com\/.well-known\/acme-challenge\/test<\/code>.<\/p>\n\n\n\nErreur “too many certificates already issued”<\/h3>\n\n\n\n
Vous avez atteint la limite de 5 certificats identiques en 7 jours. La seule solution est d’attendre la fin de la fen\u00eatre glissante. Pour d\u00e9bloquer la situation, vous pouvez ajouter ou supprimer un domaine du jeu de SANs pour cr\u00e9er un nouveau jeu unique. Pour l’avenir, utilisez syst\u00e9matiquement --staging<\/code> pour tester.<\/p>\n\n\n\nErreur “nginx: [emerg] unknown directive ssl_stapling”<\/h3>\n\n\n\n
Nginx a \u00e9t\u00e9 compil\u00e9 sans le module SSL. V\u00e9rifiez avec nginx -V 2>&1 | grep with-http_ssl_module<\/code>. Le paquet Nginx standard d’Ubuntu inclut ce module. Si vous avez compil\u00e9 Nginx manuellement depuis les sources, recompilez avec les flags --with-http_ssl_module --with-http_v2_module --with-http_stub_status_module<\/code>.<\/p>\n\n\n\nOCSP Stapling retourne “no response sent”<\/h3>\n\n\n\n
Deux causes fr\u00e9quentes. Premi\u00e8re : Nginx n’a pas encore r\u00e9cup\u00e9r\u00e9 la r\u00e9ponse OCSP (attendez 5 minutes apr\u00e8s le rechargement). Deuxi\u00e8me : la directive ssl_trusted_certificate<\/code> pointe vers fullchain.pem<\/code> au lieu de chain.pem<\/code>. La v\u00e9rification de la cha\u00eene OCSP n\u00e9cessite la cha\u00eene interm\u00e9diaire seule, sans le certificat du serveur.<\/p>\n\n\n\nSSL Labs retourne “B” \u00e0 cause de TLS 1.0 ou 1.1<\/h3>\n\n\n\n
Votre configuration inclut encore des protocoles obsol\u00e8tes. V\u00e9rifiez le contenu de \/etc\/letsencrypt\/options-ssl-nginx.conf<\/code> pour d\u00e9tecter une ancienne version. Mettez \u00e0 jour Certbot (sudo snap refresh certbot<\/code>) et rechargez Nginx. Si le probl\u00e8me persiste, votre directive ssl_protocols<\/code> personnalis\u00e9e \u00e9crase peut-\u00eatre celle du fichier include.<\/p>\n\n\n\nLe renouvellement automatique \u00e9choue silencieusement<\/h3>\n\n\n\n
Consultez les journaux du service de renouvellement :<\/p>\n\n\n\n
sudo journalctl -u snap.certbot.renew.service --since \"30 days ago\" --no-pager\nsudo journalctl -u snap.certbot.renew.timer<\/code><\/pre>\n\n\n\nUne erreur de permission indique souvent que le hook de rechargement Nginx n’est pas ex\u00e9cutable (chmod +x<\/code> manquant). Une erreur de connexion indique un probl\u00e8me r\u00e9seau intermittent ou un pare-feu bloquant l’acc\u00e8s Let’s Encrypt.<\/p>\n\n\n\nErreur “Snap store cannot be reached” lors de l’installation<\/h3>\n\n\n\n
Certains VPS ou environnements r\u00e9seau restreignent l’acc\u00e8s au snap store. Diagnostiquez avec curl -v https:\/\/api.snapcraft.io\/api\/v1\/<\/code>. Si votre serveur est derri\u00e8re un proxy, configurez les variables d’environnement dans \/etc\/environment<\/code> : https_proxy=http:\/\/proxy.exemple.com:3128<\/code>. Alternative si le snap reste inaccessible : pip (pip3 install certbot certbot-nginx<\/code>).<\/p>\n\n\n\nErreur “certificate verify failed” lors du renouvellement<\/h3>\n\n\n\n
Erreur fr\u00e9quente lors de la mise \u00e0 jour de la cha\u00eene de certification interm\u00e9diaire de Let’s Encrypt. Let’s Encrypt a modifi\u00e9 sa cha\u00eene interm\u00e9diaire en 2021 (fin du cross-sign avec IdenTrust). Si votre serveur utilise encore l’ancien certificat racine, mettez \u00e0 jour les certificats CA du syst\u00e8me : sudo update-ca-certificates<\/code>. V\u00e9rifiez \u00e9galement que ssl_trusted_certificate<\/code> pointe vers le bon fichier chain.pem<\/code>.<\/p>\n\n\n\n