La rotation des certificats TLS exige deux preuves

Une autorité de certification peut émettre exactement le certificat demandé par un agent IA alors que le service continue de présenter l'ancien. J'ai vu des tâches de rotation fêter un fichier PEM téléchargé, un secret mis à jour ou une commande de rechargement au vert, puis découvrir au pire moment qu'un listener n'avait jamais changé. La réussite de l'émission et celle du déploiement sont deux affirmations distinctes, qui exigent deux preuves distinctes.

Une rotation fiable consigne ce que la CA a émis, déploie précisément cet artefact, puis ouvre une nouvelle connexion TLS pour observer ce que reçoivent les clients. La comparaison finale doit utiliser une identité stable du certificat, le hostname visé et le véritable chemin réseau. Si l'agent ne peut pas produire les deux côtés de cette comparaison, le changement reste en cours.

La clôture exige un contrat de preuve explicite

Une rotation n'est terminée que lorsque le relevé du certificat émis correspond aux observations de chaque endpoint inclus dans le périmètre de déploiement. Écrivez cette règle avant de donner des identifiants ou des commandes à un agent. Sinon, il optimisera pour ce que son outil déclare réussi, même s'il ne s'agit que d'une écriture de fichier sans changement visible par le client.

Le relevé d'émission doit contenir l'identifiant de commande ou de requête, les noms DNS demandés, le numéro de série, l'empreinte SHA-256, la période de validité, l'émetteur et un condensat de la clé publique. Il doit aussi indiquer où la chaîne complète et la clé privée sont stockées sans copier cette clé dans le journal. L'empreinte identifie tout le certificat feuille, tandis que le condensat de clé publique indique si une réémission a conservé ou remplacé la clé.

Le relevé de déploiement répond à d'autres questions : quelle cible a reçu l'artefact, quelle configuration le référence, quel processus a accepté un rechargement et à quel moment. Une réponse positive de l'API du plan de contrôle a sa place ici, mais elle ne prouve pas le service. Elle indique seulement qu'une tentative de transition a atteint le système de déploiement.

Le relevé d'observation vient d'une nouvelle connexion effectuée après le déploiement. Il lui faut le hostname demandé, l'adresse résolue ou imposée, le port, le numéro de série et l'empreinte observés, le résultat de vérification, l'heure et l'emplacement du vérificateur. Cet emplacement compte, car une sonde interne, une sonde externe et une sonde derrière un proxy d'entreprise peuvent atteindre des terminaisons différentes.

Gardez un prédicat de clôture mécanique :

complete = issuance.valid
        && deployment.accepted
        && every(expected_endpoint,
                 observation.chain_valid
                 && observation.name_valid
                 && observation.leaf_fingerprint == issuance.leaf_fingerprint)

Cela rend visible un état gênant : le certificat existe et le déploiement a été accepté, mais l'empreinte servie diffère encore. Appelez cet état deployed_unverified, pas complete. Des noms précis empêchent un tableau de bord ou un résumé de l'agent de fusionner discrètement deux affirmations.

L'émission ACME ne prouve pas le déploiement

ACME prouve qu'une CA a accepté une commande et émis un certificat après l'autorisation requise, mais le protocole ne prouve pas que votre application sert ce certificat. RFC 8555 décrit quatre grandes étapes côté client : soumettre une commande, prouver le contrôle des identifiants demandés, finaliser avec une demande de signature, puis attendre l'émission et télécharger le certificat. La frontière s'arrête à sa récupération.

Cette frontière se perd facilement, car beaucoup de clients ACME exécutent un hook de déploiement après le renouvellement. Ce hook se trouve hors de la transaction avec la CA. Il peut échouer à cause d'un chemin modifié, d'un conteneur qui monte l'ancien secret, d'un rechargement envoyé au mauvais processus, d'une API distante qui accepte une mise à jour asynchrone ou d'un nœud inaccessible. La commande peut rester parfaitement valide malgré tous ces échecs.

Consignez l'objet final de la commande ACME ou la réponse équivalente de la CA. Pour ACME, status: valid et une URL de certificat renseignée prouvent l'émission. Capturez les identifiants et l'empreinte de la feuille renvoyée après analyse du certificat téléchargé. La simple présence d'un nouveau fichier ne doit pas identifier l'artefact : fichiers temporaires, liens symboliques et noms réutilisés font de mauvais éléments de preuve.

Certificate Transparency ne boucle pas davantage la preuve. Une entrée de journal peut montrer qu'un certificat public a été émis pour un nom. Elle ne dit pas si votre load balancer, ingress, serveur web ou CDN le présente maintenant. CT offre une preuve indépendante d'émission, pas une surveillance du déploiement.

Cette distinction change la gestion des erreurs. Un échec d'émission signifie que l'agent n'a jamais obtenu l'identifiant prévu. Un échec de déploiement signifie qu'il a obtenu un identifiant sensible, peut-être déjà stocké, mais non servi. Ce second cas demande souvent nettoyage, nouvelle tentative ou rollback, et mérite une alerte distincte.

Validez l'artefact avant le listener

Avant le déploiement, confirmez que le certificat feuille porte les noms demandés, la validité et l'émetteur attendus, ainsi que la clé publique correspondant à la clé privée. Cette barrière détecte les bundles mal formés et les mauvais fichiers sans toucher à la production. Elle ne remplace pas la sonde active.

RFC 9525 formule clairement la règle d'identité : les clients construisent indépendamment des identifiants de référence acceptables, puis les comparent à ceux du certificat. Pour les services DNS ordinaires, les noms pertinents résident dans l'extension subjectAltName. Le RFC exclut explicitement le repli sur un Common Name ressemblant à un domaine. Un agent qui ne vérifie que subject=CN=... peut approuver un certificat que les clients modernes doivent refuser.

Inspectez l'artefact feuille avec de vrais champs de sortie :

openssl x509 -in leaf.pem -noout \
  -serial -fingerprint -sha256 -dates -issuer -subject \
  -ext subjectAltName

Une sortie type prend cette forme :

serial=03A17C...
sha256 Fingerprint=6B:19:8A:...
notBefore=Jul 24 08:15:00 2026 GMT
notAfter=Oct 22 08:14:59 2026 GMT
issuer=C=US, O=Example CA, CN=Example Issuing CA
subject=CN=api.example.net
X509v3 Subject Alternative Name:
    DNS:api.example.net, DNS:www.example.net

Utilisez openssl x509 -checkhost api.example.net -noout comme barrière automatique si votre version d'OpenSSL le permet. OpenSSL documente précisément -checkhost pour faire correspondre un certificat à un hôte. Analysez le code de sortie, pas un texte convivial qui peut changer d'une version à l'autre.

Comparez les clés publiques sans exposer de matière privée. Les commandes suivantes hachent la clé publique encodée en DER de chaque côté. Des lignes identiques montrent que certificat et clé privée vont ensemble :

openssl x509 -in leaf.pem -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

openssl pkey -in private-key.pem -pubout -outform DER \
  | openssl dgst -sha256

Ne placez jamais le contenu de private-key.pem, la trace des commandes ou une variable d'environnement contenant la clé dans le contexte de l'agent. Laissez un exécuteur contraint comparer et renvoyer le condensat avec le code de sortie. L'agent a besoin du résultat de l'action, pas du secret employé.

Une écriture réussie doit encore être activée

Le déploiement compte deux opérations : placer le nouveau matériel de manière atomique, puis demander au terminateur TLS de le charger. Les agents font souvent la première et déduisent la seconde. Les serveurs persistants gardent généralement les certificats analysés en mémoire, si bien que remplacer un fichier sur disque ne modifie pas forcément les nouveaux handshakes.

Préparez les fichiers à côté de leur destination, appliquez propriétaire et droits restrictifs, validez la configuration, puis renommez-les en place. Un renommage sur le même système de fichiers évite d'exposer un PEM partiellement écrit. Gardez les anciens fichiers fonctionnels ou une référence de secret versionnée jusqu'à la réussite de la vérification active. Un nettoyage immédiat détruit le rollback le plus rapide.

L'activation dépend du terminateur. La documentation nginx indique qu'un HUP fait valider la nouvelle configuration par le maître, démarre de nouveaux workers et retire progressivement les anciens. Si l'application échoue, nginx continue avec l'ancienne configuration. Cela protège la disponibilité, mais crée un faux positif parfait si l'agent note uniquement l'envoi de HUP. Le redémarrage graceful d'Apache vérifie aussi la syntaxe et lance une nouvelle génération pendant que les anciennes connexions finissent. Les load balancers et CDN gérés peuvent accepter une mise à jour et la terminer plus tard.

Capturez la commande d'activation ou l'identifiant d'opération API, son code de sortie et l'identité du processus ciblé. Consultez ensuite l'état ou les journaux propres au service. Ne transformez pas une attente fixe en preuve. Une pause de 30 secondes masque parfois une cohérence à terme et en gaspille parfois 29; interroger un état documenté jusqu'à une échéance est plus clair.

Un échec d'activation doit arrêter le workflow avant que les sondes publiques répétées ne chargent le service. Si la validation syntaxique échoue, si l'identité du processus change de manière inattendue ou si le plan de contrôle signale une erreur terminale, conservez l'ancien certificat et marquez le déploiement en échec. Si l'activation réussit mais que l'endpoint reste ancien, continuez les sondes dans une fenêtre bornée, car le remplacement progressif et la propagation prennent du temps.

Vérifiez ce que reçoit le client, nom compris

Le contrôle décisif ouvre une nouvelle connexion TLS, envoie la valeur Server Name Indication prévue, valide la chaîne et le hostname, puis consigne la feuille. Un fichier local ne répond pas à la question de ce que reçoit un client. Une connexion keep-alive réutilisée non plus, car son handshake a déjà choisi un certificat.

Utilisez OpenSSL avec SNI et vérification du hostname :

openssl s_client \
  -connect api.example.net:443 \
  -servername api.example.net \
  -verify_hostname api.example.net \
  -verify_return_error \
  </dev/null 2>/dev/null \
| openssl x509 -noout -serial -fingerprint -sha256 -dates -issuer

L'option -servername contrôle SNI, qui sélectionne le virtual host sur de nombreux listeners partagés. -verify_hostname contrôle l'identité et -verify_return_error arrête la commande lors d'une erreur au lieu d'afficher un diagnostic et de continuer. -showcerts affiche la chaîne envoyée par le serveur, mais la documentation OpenSSL précise que cette liste n'est pas en elle-même une chaîne validée.

N'ajoutez pas -k, --insecure ou un équivalent pour faire passer l'automatisation. Le manuel curl indique qu'une requête TLS normale vérifie à la fois la confiance de la CA et la correspondance avec le hostname. Une sonde non sécurisée peut confirmer l'empreinte tout en ratant la chaîne cassée ou le nom erroné que rencontreront les utilisateurs.

La seule empreinte ne suffit pas. Un serveur peut présenter la bonne feuille avec une chaîne intermédiaire incomplète et faire échouer certains clients. La barrière de clôture doit exiger une chaîne de confiance et un nom valides en plus de la bonne feuille. Si la révocation ou une politique CT fait partie du profil client réel, exécutez aussi ce profil; la sonde OpenSSL de base ne le couvre pas.

Lancez chaque observation dans un processus neuf ou désactivez explicitement la réutilisation. Consignez stderr en cas d'échec, puis nettoyez-le avant de le transmettre à l'agent. Gardez une catégorie nette : connexion, handshake, chaîne de confiance, identité ou empreinte différente.

Chaque terminaison TLS est une cible distincte

Un hostname n'est pas un périmètre de déploiement. Ce périmètre regroupe tous les endroits capables de terminer TLS pour ce nom : adresses de load balancer, points de présence CDN, réplicas ingress, portes régionales, chemins IPv4 et IPv6 et listeners d'origine accessibles. Une connexion réussie prouve une route à un instant donné.

Construisez l'inventaire attendu depuis l'état de l'infrastructure, pas depuis la réponse DNS reçue par hasard. Le DNS dynamique et l'anycast compliquent l'échantillonnage public exhaustif; définissez donc un ensemble défendable : chaque listener configuré ou association de certificat du plan de contrôle, plus des sondes depuis les régions clientes importantes. Si un fournisseur gère le parc edge, vérifiez son état de déploiement et échantillonnez depuis plusieurs emplacements externes.

Pour tester une adresse précise, --resolve de curl est plus sûr que remplacer l'URL par une IP, car il conserve le hostname d'origine pour SNI et la vérification :

curl --fail --silent --show-error \
  --resolve api.example.net:443:192.0.2.18 \
  --output /dev/null \
  https://api.example.net/health

Répétez pour chaque adresse connue, y compris les IPv6 entre crochets quand elles sont prises en charge. Enchaînez avec la sonde d'empreinte OpenSSL vers la même adresse tout en gardant -servername api.example.net. Un statut HTTP correct contrôle plus que TLS; choisissez donc un endpoint léger et sans mutation. L'observation du certificat reste la preuve de clôture de cette rotation.

Soyez précis au sujet des proxys. Une sonde sur un portable peut voir le certificat d'inspection TLS de l'entreprise. Une sonde du cluster peut contourner le CDN public. Consignez l'emplacement et le chemin réseau du vérificateur, puis refusez une observation dont l'émetteur ou l'empreinte montre qu'elle n'a pas atteint la terminaison voulue.

Pendant un déploiement progressif, attendez-vous à un mélange d'anciennes et de nouvelles empreintes. C'est un état transitoire valable, pas une raison de déclarer la réussite à la majorité. Chaque endpoint doit converger, ou l'endpoint défaillant doit être explicitement retiré du service.

Faites produire des relevés comparables à l'agent

Un agent IA doit produire des preuves structurées qu'un autre programme compare sans interpréter de prose. Des résumés comme «le renouvellement a réussi et le site semble bon» effacent la cible, l'heure et les écarts. Gardez l'explication destinée aux humains, mais faites dépendre les transitions de champs typés.

Une paire d'événements compacte peut ressembler à ceci :

{"type":"certificate.issued","rotation_id":"rot_7f2","order_id":"ord_91c","dns_names":["api.example.net"],"serial_hex":"03A17C","leaf_sha256":"6B:19:8A:...","spki_sha256":"9f4c...","not_before":"2026-07-24T08:15:00Z","not_after":"2026-10-22T08:14:59Z"}
{"type":"certificate.observed","rotation_id":"rot_7f2","host":"api.example.net","address":"192.0.2.18","port":443,"leaf_sha256":"6B:19:8A:...","chain_valid":true,"name_valid":true,"observed_at":"2026-07-24T08:19:22Z","vantage":"external-us-east"}

Utilisez le même rotation_id pour émission, tentatives, observations, retries, rollback et clôture. Gardez l'identifiant de commande CA et celui d'opération d'infrastructure dans des champs séparés. Les fondre dans un ID générique complique inutilement la reconstitution d'un incident.

Les nouvelles tentatives ont besoin de leur propre sémantique. L'agent peut perdre la réponse après l'acceptation d'une commande ou d'une association. Répéter aveuglément peut créer des certificats supplémentaires, déclencher des limites ou lancer des déploiements concurrents. Donnez à chaque mutation un jeton d'idempotence dérivé de la rotation et de la phase, puis interrogez l'opération distante avant de la remplacer. Consignez si la réponse décrit une nouvelle action ou la répétition d'une action existante.

La fraîcheur exige aussi une règle. Une sonde passée une heure avant le déploiement ne prouve rien sur son résultat, même si elle avait vu la même empreinte lors d'une autre tentative. Exigez que observed_at suive l'activation acceptée et fixez un âge maximal à la clôture. Employez l'horloge fiable du workflow ou du vérificateur, pas une heure produite dans le texte du modèle.

Séparez l'identité du certificat de celle du service. L'empreinte répond «est-ce la feuille émise?», le hostname «est-elle valable pour le service demandé?» et la chaîne «le vérificateur construit-il une confiance acceptable?». Tout fondre dans tls_ok oblige à relancer le test après disparition de la preuve.

L'inventaire des endpoints doit aussi porter une révision. Si l'infrastructure ajoute un listener en cours de rotation, la clôture doit adopter la nouvelle révision et exiger son observation, ou rester liée à l'ancienne révision approuvée et créer un suivi. Lire silencieusement une liste mouvante crée une course. Stockez la révision pour reconstruire le sens de «chaque endpoint».

La collecte doit pouvoir être répétée sans danger. Utilisez des routes en lecture seule, des timeouts courts et une concurrence bornée. Une URL de santé qui chauffe un cache ou modifie une session est un mauvais choix; le handshake TLS précède HTTP, donc une requête minimale ou un handshake direct suffit. Avec des milliers d'adresses, planifiez par cible et ne réessayez que les échecs.

Enfin, séparez observation et interprétation. La sonde rapporte les octets et le résultat du vérificateur; le comparateur décide s'ils satisfont la rotation. Vous pourrez corriger le comparateur et rejouer la preuve sans toucher à la production, et l'agent ne pourra pas transformer un écart gênant en résumé rassurant.

Le comparateur doit rejeter les observations antérieures au déploiement accepté, celles d'un hostname ou d'une adresse inattendus et les preuves d'une autre rotation. Il compare des empreintes binaires normalisées, pas leur affichage, car les deux-points et la casse varient. Conservez l'affichage original pour l'opérateur.

Ne laissez pas l'agent choisir les champs à omettre. Définissez le schéma dans le workflow et échouez fermé en cas d'absence. Des événements signés renforcent la provenance, mais une signature ne corrige pas une affirmation faible. Même signé, «la commande a quitté avec zéro» ne dit pas quel certificat a reçu le client.

Conservez aussi les observations en échec. Une empreinte différente, un certificat expiré ou un nom incompatible expliquent pourquoi la tâche est restée ouverte et distinguent propagation lente et mauvaise association. Remplacer l'échec par le succès final laisse un audit incapable d'expliquer la fenêtre d'incident.

L'échec familier est un déploiement partagé

Il commence discrètement. Un agent obtient un certificat pour api.example.net, consigne la commande ACME comme valide, met à jour un secret api-tls et reçoit une réponse positive de l'API d'orchestration. Il voit une nouvelle version du secret et clôt le ticket.

Le hostname public résout vers deux load balancers. Un contrôleur surveille api-tls dans le namespace de production et charge le nouveau certificat. L'autre listener référence un secret du même nom dans un ancien namespace. Aucun appel API n'a échoué : l'agent a mis à jour un véritable objet, mais pas tous ceux qui contrôlent le hostname.

La plupart des utilisateurs atteignent la première adresse et voient le nouveau certificat. Un chemin plus rare sert encore l'ancienne feuille. À l'approche de l'expiration, les échecs semblent intermittents et une nouvelle tentative paraît les guérir parce que DNS ou le load balancer choisit ailleurs. Les opérateurs accusent les caches alors que TLS choisit un certificat à chaque nouveau handshake.

La double preuve révèle immédiatement cette séparation. L'émission indique 6B:19:8A:...; les deux adresses renvoient cette valeur et 41:D0:72:.... La rotation reste deployed_unverified et l'observation différente nomme l'adresse à réparer.

Le conseil populaire «regardez le certificat dans un navigateur» convient mal à l'automatisation. Un navigateur peut réutiliser des connexions, masquer l'adresse, employer un autre magasin de confiance ou se trouver derrière une inspection. C'est un contrôle indépendant utile en incident, pas un moteur de clôture. Des sondes fixées sur l'adresse et validant le hostname fournissent une preuve répétable.

Après correction de l'ancienne association, sondez de nouveau les deux adresses avec des connexions fraîches. Gardez le premier écart, le déploiement correctif et les observations réussies. Cet historique prouve ce qui a changé et pourquoi le workflow a fini par se fermer.

Les actions privilégiées demandent une autorité étroite

La rotation donne accès aux API de CA, aux secrets et aux rechargements de production; l'exécuteur doit donc exposer des actions étroites plutôt que des identifiants bruts. «Soumettre ce CSR», «associer l'artefact X au listener Y» ou «sonder H via A» sont de bonnes frontières. Donner un jeton réutilisable au modèle augmente le risque sans améliorer son raisonnement.

Chaque résultat doit contenir l'identifiant de l'opération distante et les champs de preuve, sans identifiants ni octets de clé privée. Séparez les droits d'émission, de déploiement, de vérification et de rollback. Un agent capable de demander un certificat ne doit pas obtenir automatiquement le droit de l'associer partout.

Sallyport garde les identifiants API et SSH dans son coffre chiffré tandis que l'agent exécute les actions HTTP et SSH au travers de l'application, sans recevoir ces identifiants. Ses journaux Activity et Sessions dérivent d'un journal d'audit chiffré, chaîné par hachage et aveugle en écriture, adapté à l'attribution des appels d'émission, de déploiement et de vérification sans prétendre remplacer les observations.

Placez l'approbation humaine là où l'impact augmente. Un renouvellement courant pour un hostname et un listener prédéclarés peut relever de l'autorisation de session; ajouter un nom, changer la clé, toucher un wildcard ou revenir en arrière justifie une approbation par appel. L'approbation doit lier cible et empreinte affichées. «Autoriser la mise à jour» est trop vague pour repérer un mauvais listener.

Auditez le vérificateur aussi strictement que le déployeur. Si le même agent sans contrainte peut modifier l'inventaire, déployer et juger son échantillon incomplet suffisant, le contrat est décoratif. Calculez les cibles depuis une source contrôlée et refusez toute observation manquante.

Ne clôturez qu'après convergence et gardez le rollback

La clôture doit exécuter une comparaison déterministe des événements immuables d'émission, de déploiement et d'observation. Elle ne doit pas demander à l'agent si la rotation «semble terminée». Quand tous les endpoints attendus présentent la feuille émise avec une chaîne valide et un nom correspondant, consignez le résultat exact et clôturez.

Fixez des délais de propagation au lieu de la masquer. Dans la fenêtre permise, ne réessayez que les cibles qui n'ont pas convergé, avec un recul borné. À l'échéance, faites échouer la rotation en joignant les cibles différentes. Le rollback dépend de la validité et de la santé : un ancien certificat encore largement valide peut être temporairement plus sûr, tandis qu'un certificat expiré ou révoqué impose une réparation en avant.

Le rollback porte la même charge de preuve. Rattacher l'ancien artefact reste une tentative de déploiement; le workflow doit observer son ancienne empreinte avant d'annoncer la reprise. Si la clé privée est compromise, revenir au certificat compromis ne rétablit rien. Émettez avec une nouvelle clé et révoquez selon le plan d'incident.

Conservez les deux certificats jusqu'à ce que le drainage des connexions et la politique autorisent le nettoyage. Un rechargement progressif peut laisser les anciens workers servir des connexions établies, mais les nouvelles sondes doivent atteindre la nouvelle génération. Supprimez l'ancien matériel privé par le chemin contrôlé du système de secrets, puis consignez ce nettoyage après la clôture plutôt que d'en faire une condition du nouveau service.

Le premier changement est petit mais strict : retirez «certificat téléchargé» et «secret mis à jour» des états de réussite finale. Exigez une empreinte émise d'un côté et, de l'autre, des empreintes fraîches avec hostname validé pour tout l'inventaire. L'agent peut accomplir chaque étape, mais seules des preuves concordantes peuvent déclarer la rotation terminée.