Assurez le bon fonctionnement de HTTPS sur tout le cycle de vie du certificat
Un navigateur affichant une connexion sécurisée aujourd'hui marque le début des opérations de certificat, pas la fin. Un domaine peut changer, un chemin de validation peut évoluer, ou un renouvellement peut réussir sans que le service public charge le nouveau certificat. Traitez l'émission, le déploiement et la vérification continue comme des étapes distinctes avec un responsable clairement identifié.
L'essentiel à retenir
Identifiez chaque point de terminaison TLS, automatisez le renouvellement avec la méthode de validation appropriée, testez ce processus et vérifiez le certificat réellement servi aux utilisateurs après le déploiement.
Cartographiez l'emplacement où se termine la connexion sécurisée
Listez les noms d'hôte réellement visités par les utilisateurs, y compris le domaine principal, un éventuel nom www, les sous-domaines applicatifs et les points de terminaison API importants. Identifiez ensuite où TLS se termine pour chacun : un serveur web, un proxy inverse, un répartiteur de charge ou un autre service géré. Un certificat installé sur l'origine ne prouve pas qu'un proxy public distinct sert le même. Conservez cet inventaire avec les personnes responsables des domaines et des accès à l'hébergement.
Un certificat doit couvrir le nom d'hôte demandé par le client et s'enchaîner à une ancre de confiance que ce client accepte. Le service doit également présenter correctement le certificat concerné et la chaîne intermédiaire. Vérifiez plus d'une URL pratique lorsque les applications utilisent plusieurs noms. Une connexion réussie au domaine nu ne dit presque rien d'un sous-domaine d'API ou d'un service de messagerie distinct, qui peuvent avoir leur propre processus de certificat.
HTTPS protège la connexion selon le protocole et la configuration applicables ; ce n'est pas la preuve que l'application n'a aucune vulnérabilité ni qu'un marchand est digne de confiance. Conservez le contrôle d'accès, les mises à jour et les sauvegardes dans leur propre plan d'exploitation. La liste des fonctionnalités d'hébergement web de HM Bastion inclut le renouvellement SSL automatisé, tandis qu'un administrateur de VPS doit confirmer et gérer les outils de certificat utilisés dans sa propre pile. Ne supposez pas que ces responsabilités sont identiques.
Choisissez la validation adaptée à votre environnement
ACME automatise les interactions liées à l'obtention de certificats, notamment la preuve de contrôle des noms de domaine demandés. Différentes méthodes de défi conviennent à différents environnements. La validation basée sur HTTP dépend de l'accessibilité du chemin de validation requis, tel que spécifié par l'autorité de certification. La validation basée sur DNS dépend du contrôle des enregistrements DNS concernés. Lisez la documentation de l'autorité et du client avant de choisir une méthode, en particulier lorsqu'un proxy ou plusieurs instances d'application se trouvent devant l'origine.
| Question opérationnelle | Ce qu'il faut établir |
|---|---|
| Qui contrôle DNS ? | Un propriétaire identifié et l'accès de validation requis |
| Où les demandes de validation peuvent-elles arriver ? | Le routage public et la gestion des défis pour chaque nom concerné |
| Comment les identifiants sont-ils stockés ? | Un stockage privé et les permissions les plus restreintes disponibles |
| Que se passe-t-il après l'émission ? | Le déploiement vers le bon service et un rechargement vérifié |
L'automatisation DNS peut nécessiter des identifiants disposant de pouvoirs importants sur un domaine. Stockez-les hors des répertoires publics et ne leur accordez que les permissions requises par l'intégration choisie, lorsque cela est pris en charge. Séparez la documentation du processus des valeurs secrètes réelles. La validation manuelle peut convenir à une configuration particulière, mais elle crée une dépendance humaine récurrente ; notez qui l'exécutera et comment un renouvellement imminent sera remarqué.
Utilisez l'environnement de préproduction de l'autorité de certification lors du test d'une intégration, lorsqu'il est disponible. Il permet d'exercer le processus sans traiter des émissions de production répétées comme une méthode de débogage. Un certificat de préproduction n'est pas approuvé pour un service public normal ; gardez donc l'objectif du test clair. Évitez de coder en dur des hypothèses sur la durée de vie des certificats ou les calendriers de renouvellement lorsque l'autorité et le client fournissent des indications ou des informations de renouvellement susceptibles de changer.
Renouvellement, déploiement et rechargement sont des résultats distincts
Vérifiez que le mécanisme de renouvellement planifié s'exécute réellement sous le compte et dans l'environnement prévus. Une commande qui fonctionne dans un terminal interactif peut dépendre d'un chemin, d'une permission ou d'un identifiant absents lors de son exécution planifiée. Consultez les journaux concernés et utilisez la procédure de test de renouvellement prise en charge par le client. Pour Certbot, la documentation décrit les tests à blanc et les hooks de renouvellement ; suivez les instructions adaptées à la version installée et à l'authentificateur choisi.
Un fichier de certificat nouvellement écrit ne modifie pas automatiquement ce que présente un service en cours d'exécution. Le service peut nécessiter un rechargement, un hook de déploiement ou une distribution vers plusieurs points de terminaison. Validez la configuration avant de recharger, conservez un chemin de retour arrière et vérifiez la connexion publique ensuite. Dans une configuration multi-nœuds, une seule requête réussie ne peut atteindre qu'un seul nœud. Prévoyez une vérification qui couvre le déploiement réel plutôt que de supposer que chaque instance a changé en même temps.
Surveillez le certificat servi en externe, les noms qu'il couvre et le temps restant avant expiration. Cela détecte une défaillance différente de la surveillance du succès de la tâche de renouvellement. Maintenez à jour le responsable des notifications, y compris en cas de changement d'agence ou d'administrateur. Une alerte envoyée à une boîte aux lettres abandonnée offre peu de protection. Revoyez l'inventaire après avoir modifié DNS, ajouté un proxy inverse, déplacé un nom d'hôte ou changé la configuration du serveur web.
Analysez un renouvellement échoué à partir de l'étape en échec
- Notez le nom d'hôte concerné, la version du client, l'heure et l'erreur exacte non secrète.
- Déterminez si la défaillance relève de la validation, de l'émission, du déploiement ou de la diffusion publique.
- Vérifiez les DNS concernés, le routage, l'accès aux fichiers et l'environnement des tâches planifiées.
- Corrigez et testez la cause précise avant de relancer une émission en production.
- Vérifiez le certificat public et les parcours applicatifs normaux après le rétablissement.
Par exemple, si la validation échoue après un changement de DNS, comparez les enregistrements publics actuels avec la route de challenge prévue avant de remplacer les outils de certificat. Si l'émission réussit mais que le navigateur voit encore un ancien certificat, inspectez le point de terminaison public et le processus de déploiement. Demander des certificats à répétition ne corrigera pas un proxy qui lit un autre fichier. Consignez l'erreur d'origine et les actions suivantes dans une chronologie afin que la personne suivante puisse suivre le diagnostic.
Si une clé privée a pu être exposée, traitez cela comme un incident de sécurité plutôt que comme un simple rappel d'expiration. La réponse peut inclure le remplacement des clés, la révocation des certificats concernés via le processus approprié et l'investigation de l'exposition. Ne placez jamais une clé privée ni un identifiant DNS dans un ticket d'assistance. Partagez le nom d'hôte, les identifiants de certificat le cas échéant et les sorties de diagnostic sûres afin que l'équipe puisse enquêter sans recevoir le contrôle du domaine.
