Certificats TLS : détecter les expirations avant une panne

Un certificat renouvelé peut quand même provoquer une panne

Le portail fonctionne, le renouvellement est annoncé comme réussi, puis les utilisateurs reçoivent une erreur TLS. Le nouveau certificat peut être dans le magasin du serveur alors que le service présente encore l’ancien. Un autre nœud peut avoir été oublié, ou un intermédiaire peut manquer dans la chaîne.

Une surveillance utile combine inventaire, sondes réseau et preuve de déploiement. Les commandes ci-dessous consultent les métadonnées et ouvrent des connexions de diagnostic; elles ne changent aucune liaison ni configuration. Les domaines example.com sont fictifs. Ce guide aide à organiser la maintenance; il ne remplace pas une analyse complète de la PKI.

1. Inventorier les points de terminaison, pas seulement les fichiers

Créez une ligne par nom DNS, port, protocole et point de terminaison TLS. Un certificat partagé peut couvrir plusieurs services avec des propriétaires différents. Documentez aussi les certificats internes, les équipements réseau et les services rarement utilisés.

Distinguez le certificat public présenté par le proxy ou CDN du certificat à l’origine. Un contrôle Internet ne voit pas nécessairement celui du serveur derrière Cloudflare. Testez les deux chemins depuis les réseaux autorisés, sans contourner les contrôles d’accès.

2. Vérifier le certificat présenté avec OpenSSL et SNI

Ces exemples ciblent OpenSSL 3.x et Bash. GNU timeout est un utilitaire distinct; il n’est pas installé par défaut partout. Le poste doit résoudre le DNS, joindre le port et disposer des autorités approuvées. Une sonde TLS publique ne nécessite pas de compte administrateur; un service à authentification mutuelle exige une méthode autorisée adaptée.

L’option -servername envoie le nom SNI; -verify_hostname valide l’identité attendue. La documentation s_client explique que -verify_return_error arrête la négociation sur erreur de validation. Sans cette option, afficher une chaîne ne prouve pas que le certificat est accepté.

Pour tester un nœud particulier, remplacez uniquement la destination de -connect par son IP autorisée et gardez le nom DNS dans SNI et la validation. Répétez par nœud et par famille IPv4/IPv6. Une seule résolution DNS ne couvre pas automatiquement toutes les instances.

# Bash, OpenSSL 3.x; GNU timeout limits the complete operation.
timeout 15 openssl s_client -connect portal.example.com:443 \
  -servername portal.example.com -verify_hostname portal.example.com \
  -verify_return_error -showcerts </dev/null
# Read the exit status immediately; nonzero is a failed probe.
echo $?

• OpenSSL : options de s_client et vérification ↗

3. Lire l’expiration sans confondre date et confiance

Le premier certificat extrait par x509 est normalement le certificat du serveur. Les autres certificats affichés par -showcerts sont ceux envoyés par le serveur, pas nécessairement une chaîne complète ou validée. Une racine peut être fournie par le magasin de confiance du client.

-checkend reçoit un délai en secondes. Un code non nul nécessite de distinguer une échéance proche d’une erreur de lecture; surveillez stderr et l’état de la commande. Dans une chaîne de commandes, préservez aussi l’échec de la connexion. La lecture de NotAfter seule ne vérifie ni le nom, ni la chaîne, ni la révocation.

# Metadata only: this pipeline is NOT a trust-validation result.
set -o pipefail
timeout 15 openssl s_client -connect portal.example.com:443 \
  -servername portal.example.com -showcerts </dev/null |
  openssl x509 -noout -subject -issuer -dates -serial \
    -fingerprint -sha256 -ext subjectAltName
# For an existing PUBLIC certificate file (no private key):
openssl x509 -in leaf.pem -noout -checkend 2592000
# 0 = does not expire within 30 days; nonzero = expiry or command error.

• OpenSSL x509 : dates, empreinte et checkend ↗

4. Inventorier les certificats Windows avec PowerShell

Le fournisseur Cert: est propre à Windows. Microsoft documente les magasins et le filtre ExpiringInDays. Commencez avec les droits de lecture autorisés; un accès refusé doit rester une erreur visible. N’accordez pas de droits sur les clés privées pour une simple collecte.

My n’est pas un inventaire universel : IIS peut utiliser WebHosting, des applications un fichier PEM ou PFX, et des appliances leur propre magasin. HasPrivateKey indique seulement la présence d’une clé associée; cette collecte n’en révèle pas le contenu. Un certificat expiré inutilisé n’est pas nécessairement une panne imminente. Reliez-le à une liaison avant de décider de le supprimer.

# Windows only; reads metadata, never exports private keys.
Get-ChildItem Cert:\LocalMachine\My |
  Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey,
    @{Name='DaysRemaining';Expression={
      [math]::Floor(($_.NotAfter.ToUniversalTime() -
        [datetime]::UtcNow).TotalDays)
    }} | Sort-Object DaysRemaining

# Other stores may also be relevant, including WebHosting on IIS.
Get-ChildItem Cert:\LocalMachine\My -ExpiringInDays 30

• Microsoft : fournisseur de certificats PowerShell ↗

5. Vérifier les liaisons IIS et HTTP.sys

Sur un serveur IIS autorisé, utilisez Windows PowerShell 5.1 et les outils de gestion IIS pour lire les liaisons. Une session élevée peut être nécessaire selon la configuration; ne modifiez pas les permissions du serveur pour faciliter une sonde.

Comparez nom, port, magasin et empreinte à l’inventaire. Les modes SNI et magasin centralisé exigent une interprétation adaptée; un champ certificateHash vide n’autorise pas à conclure qu’aucun certificat n’est utilisé. Confirmez toujours par une connexion au service. Le renouvellement dans le magasin ne prouve pas que la liaison a changé.

# Windows PowerShell 5.1, IIS management tools installed.
Import-Module WebAdministration
Get-WebBinding -Protocol https |
  Select-Object protocol, bindingInformation, sslFlags,
    certificateHash, certificateStoreName
# Read HTTP.sys certificate bindings; do not run "delete sslcert".
netsh http show sslcert

• Microsoft : Get-WebBinding ↗

6. Adapter la sonde au protocole et à la confiance

HTTPS, LDAPS et SMTP avec STARTTLS ne se testent pas tous de la même façon. Le fichier approved-enterprise-ca.pem doit provenir de votre PKI approuvée : ne faites pas confiance à un certificat simplement parce que le serveur l’envoie. Ces commandes ne testent ni une ouverture de session LDAP ni la livraison d’un courriel.

NPS/RADIUS sur UDP 1812 n’est pas un port TLS direct à sonder avec s_client. Pour un certificat EAP, vérifiez le certificat sélectionné dans NPS et effectuez un test d’authentification avec un client représentatif. Même principe pour les VPN : suivez le protocole et la configuration du produit.

# SMTP submission: negotiate STARTTLS, not implicit TLS.
timeout 15 openssl s_client -connect mail.example.com:587 \
  -starttls smtp -servername mail.example.com \
  -verify_hostname mail.example.com -verify_return_error </dev/null
# LDAPS uses implicit TLS on 636.
timeout 15 openssl s_client -connect dc01.example.com:636 \
  -servername dc01.example.com -verify_hostname dc01.example.com \
  -verify_return_error -CAfile approved-enterprise-ca.pem </dev/null

7. Séparer expiration, chaîne, identité et disponibilité

Un certificat encore valide peut être inutilisable : SAN incorrect, intermédiaire absent, autorité non approuvée, heure du client erronée ou protocole incompatible. La validation de base des exemples OpenSSL ne constitue pas une vérification complète CRL/OCSP. Testez la révocation selon la politique et les mécanismes de vos applications.

Comparez depuis un client touché et depuis la supervision. Une interception TLS peut présenter un certificat différent; consignez le chemin. Ne désactivez jamais la validation TLS pour faire passer une alerte au vert.

8. Construire des alertes qui aboutissent à une action

Pour un certificat à durée relativement longue, 60, 30, 14 et 7 jours peuvent servir de points de départ. Pour une durée courte, adaptez les seuils à la fenêtre de renouvellement et à votre délai réel d’intervention. Une alerte permanente dès l’émission ne rend pas le suivi plus utile.

Planifiez une collecte quotidienne, une sonde après renouvellement et des contrôles plus fréquents pour les services critiques. Conservez DNS, port, expiration UTC, empreinte, dernière réussite, erreur et propriétaire. Un résultat trop ancien ou une sonde échouée doit alerter séparément.

Dédupliquez par point de terminaison, ouvrez un billet assigné et faites escalader les échéances sans prise en charge. Un tableau de bord ne doit contenir ni PFX, ni clé privée, ni jeton DNS. Les licences et coûts de supervision dépendent du produit retenu; OpenSSL et les commandes locales n’impliquent pas un abonnement de surveillance.

9. Automatiser le renouvellement et surveiller le déploiement

ACME automatise la validation de contrôle du domaine et l’émission. HTTP-01 et DNS-01 ont des prérequis différents : la documentation Let’s Encrypt décrit le port 80 pour HTTP-01 et les enregistrements TXT pour DNS-01. DNS-01 peut servir aux certificats wildcard; les droits DNS doivent être limités à la portée nécessaire.

Choisissez un client maintenu compatible avec la plateforme, protégez ses secrets et testez avec l’environnement de staging de l’autorité. Respectez ses limites et sa méthode de planification du renouvellement, notamment ARI lorsque le client et l’autorité le prennent en charge. Ne codez pas une durée de validité supposée dans votre supervision.

Let’s Encrypt recommande un renouvellement automatisé avec une marge contre les pannes. Ajoutez une preuve indépendante : après émission et déploiement, une sonde doit voir le nouveau certificat sur chaque nœud. L’émission réussie et le rechargement réussi sont deux événements distincts.

• Let’s Encrypt : types de défis ACME ↗
• Let’s Encrypt : intégration et renouvellement ↗

10. Renouveler par pilote avec un retour arrière concret

Cette étape constitue un changement. Relevez la liaison actuelle et les dépendances, préparez le nouveau certificat et sa chaîne par la procédure du produit, puis vérifiez les SAN, l’usage attendu et l’accès du service à sa clé. Gardez la clé privée dans son emplacement sécurisé; les rapports de maintenance ne doivent pas l’inclure.

Testez un nœud ou un service pilote. Appliquez la nouvelle liaison et le rechargement documenté, puis vérifiez SNI, chaîne, expiration et transaction applicative depuis les réseaux pertinents. Ne prescrivez pas un redémarrage global comme étape automatique.

Prévoyez de rétablir la liaison et la configuration précédentes si le pilote échoue, seulement si l’ancien certificat est encore valide et acceptable. Un certificat expiré ou compromis n’est pas une solution de retour arrière. Conservez l’ancienne configuration pendant la période validée, puis retirez les éléments devenus inutiles selon la politique.

Checklist : ce qui doit être vrai avant de fermer le billet

Si les renouvellements reposent sur des souvenirs ou des interventions manuelles répétées, un accompagnement en infrastructure peut formaliser l’inventaire, la supervision et les procédures de déploiement. La sécurité des modèles et permissions de votre autorité interne demeure un travail distinct, à relier au guide AD CS présenté ci-dessous.

• Chaque point de terminaison a un propriétaire, une criticité et une méthode de renouvellement.
• Les magasins et les certificats réellement présentés ont été comparés.
• Chaque nœud et chemin TLS concerné présente le certificat attendu.
• Les clients représentatifs valident le nom, la chaîne et la transaction.
• La prochaine échéance et les échecs de supervision déclenchent une alerte assignée.
• Le retour arrière est documenté et les secrets restent protégés.