Certificats TLS : commandes OpenSSL 3 pratiques, validation et dépannage

Intro

Ce guide pratique montre comment inspecter, valider, dépanner et convertir en toute sécurité des certificats TLS avec OpenSSL 3.x. Il distingue quatre vérifications souvent confondues :

• L’analyse d’un fichier de certificat (structure et champs)
• La validation d’une chaîne de certificats (ancre de confiance, intermédiaires et usage)
• La vérification d’un nom d’hôte (contrôle d’identité basé sur le SAN)
• L’établissement d’une connexion TCP/TLS (réussite de la poignée de main)

Vous trouverez des commandes copiables, ce que chaque commande démontre, ce qu’elle ne prouve pas, ainsi que des notes de sécurité pour éviter de perdre des clés ou d’exposer des secrets.

1) Identifier votre OpenSSL et l’environnement

Les options et valeurs par défaut varient selon la compilation et la version. OpenSSL 1.1.1 est en fin de vie ; privilégiez OpenSSL 3.x. Notez votre environnement avant de lancer des diagnostics :

openssl version -a

Preuves attendues : version d’OpenSSL, indicateurs de compilation, OPENSSLDIR, fournisseurs (providers) et emplacements de confiance par défaut. Ces éléments influencent le comportement de vérification et la disponibilité d’options comme -verify_hostname.

Tableau : Inventaire de la version et de l’environnement

2) Inspecter un certificat local (PEM)

Analysez un certificat au format PEM (Privacy-Enhanced Mail — encodage Base64 avec en-têtes) et concentrez-vous sur l’identité et les périodes de validité. L’identité d’un nom d’hôte moderne repose sur le SAN (Subject Alternative Name — extension listant les identités, principalement DNS et IP), pas uniquement sur le Common Name.

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

• subject : Champs d’identité descriptifs
• issuer : Émetteur (qui a signé)
• serial : Numéro de série unique par émetteur
• dates : fenêtre de validité notBefore et notAfter
• fingerprint avec -sha256 : empreinte SHA-256 pour le suivi
• subjectAltName : liste des noms DNS et IP valides pour le certificat (source principale pour les contrôles de nom d’hôte)

Étape de vérification : confirmez que le nom d’hôte cible figure dans les entrées DNS du SAN.

3) Vérifier les fenêtres d’expiration sans supposer la politique de renouvellement

Testez si un certificat restera valide au moins N secondes. Exemple : 30 jours = 2 592 000 secondes.

openssl x509 -checkend 2592000 -noout -in <certificate.pem>
echo $?

• Code de sortie 0 : n’expirera PAS dans les 30 jours
• Code non nul : expirera dans les 30 jours ou une erreur est survenue

Étape de vérification : en cas de code non nul, confirmez la date notAfter réelle avec la commande de la section 2.

4) Inspecter un point de terminaison distant avec s_client (poignée de main et chaîne présentée)

Utilisez SNI (Server Name Indication — indication du nom de serveur) pour sélectionner l’hôte virtuel correct. Demandez la chaîne complète telle que servie et exigez un code de retour non nul en cas d’erreurs de vérification. La redirection de l’entrée ferme stdin pour une sortie propre.

openssl s_client -connect <host>:443 -servername <host> \
  -showcerts -verify_return_error </dev/null

À observer :

• Chaîne de certificats telle que présentée par le serveur (peut être incomplète)
• Réussite de la poignée de main vs statut de vérification
• Concordance du certificat feuille avec le nom d’hôte attendu (non vérifiée automatiquement sans -verify_hostname)

Notes :

• La sélection du magasin de confiance dépend de votre build OpenSSL et des valeurs par défaut de l’OS. Vous pouvez surcharger avec -CAfile ou -CApath pour reproduire un problème.
• Une poignée de main réussie ou l’affichage d’un certificat ne prouvent pas, à eux seuls, l’identité ou la confiance.

5) Vérification explicite du nom d’hôte (OpenSSL 3.x)

Commencez par vérifier si votre s_client prend en charge -verify_hostname.

openssl s_client -help 2>&1 | grep -i verify_hostname || echo "Option not supported"

Si pris en charge (OpenSSL 3.x recommandé) :

openssl s_client -connect <host>:443 -servername <host> \
  -verify_hostname <host> -verify_return_error </dev/null

Preuves attendues : « verification OK » lorsque le SAN contient le nom d’hôte et que la chaîne se valide jusqu’à une ancre de confiance. En cas d’échec, s_client renvoie un code non nul et imprime la raison du défaut.

6) Valider une chaîne locale (ancre de confiance vs intermédiaires)

Séparez l’ancre de confiance (CA, Certification Authority — autorité de certification) des intermédiaires non approuvés et validez la feuille.

openssl verify -CAfile <root-ca.pem> -untrusted <intermediate.pem> <leaf.pem>

Preuve attendue : <leaf.pem>: OK. En cas d’échec, les causes courantes incluent des intermédiaires expirés, un ordre incorrect, un intermédiaire manquant ou une racine non approuvée.

Distinctions importantes :

• La validation de chaîne ne vérifie pas les noms d’hôte ; elle vérifie les signatures, l’heure et la confiance jusqu’à une ancre.
• Les contrôles de finalité (purpose), par exemple sslserver vs sslclient, sont distincts ; utilisez -purpose sslserver si vous avez besoin de cette vérification explicite.

7) Inspecter une CSR en toute sécurité

CSR (Certificate Signing Request — demande de signature de certificat).

openssl req -in <request.csr> -noout -text -verify

• L’option -verify confirme que la CSR est auto-signée par la clé publique intégrée, prouvant la possession de la clé privée correspondante au moment de la création.
• Elle ne prouve pas l’identité du demandeur ni qu’une CA l’approuvera.

Étape de vérification : confirmez que les valeurs SAN demandées et les extensions d’usage de clé correspondent à votre politique d’émission.

8) Reconnaître et convertir les formats de certificats sans écrasement

Créez toujours un nouveau fichier et vérifiez avant de remplacer l’original.

• Reconnaitre un certificat : openssl x509 -in <file> -noout -subject
• Reconnaitre une clé privée sans l’exposer : openssl pkey -in <key.pem> -noout

Tableau : Formats et matrice de conversion (non destructif)

9) Inspection et export PKCS#12, en sécurité

Évitez de mettre les mots de passe directement sur la ligne de commande ; ils peuvent fuiter via l’historique du shell ou la liste des processus. Préférez les invites interactives, ou utilisez des mécanismes protégés fournis par votre environnement.

• Inspecter les certificats à l’intérieur d’un PKCS#12 sans afficher les clés privées :

openssl pkcs12 -in <bundle.p12> -info -nokeys

• Exporter uniquement le certificat feuille (sans clés) :

openssl pkcs12 -in <bundle.p12> -clcerts -nokeys -out <leaf-cert.pem>

• Exporter une clé privée chiffrée (une phrase secrète de sortie vous sera demandée) :

openssl pkcs12 -in <bundle.p12> -nocerts -out <key.pem>

Étape de vérification : analysez les sorties avec openssl x509 ou openssl pkey comme montré, et confirmez que les permissions de fichiers restreignent l’accès à la clé privée.

10) Apparier un certificat à sa clé privée sans exposer la clé

Dérivez des empreintes de clés publiques des deux côtés et comparez. Elles doivent être identiques.

• Depuis le certificat :

openssl x509 -in <certificate.pem> -noout -pubkey | openssl sha256

• Depuis la clé privée :

openssl pkey -in <key.pem> -pubout | openssl sha256

Preuve attendue : les deux digests SHA-256 (Secure Hash Algorithm 256-bit — empreinte à 256 bits) correspondent. Mises en garde :

• L’ancienne méthode -modulus ne s’applique qu’à RSA, pas à ECDSA ou Ed25519.
• N’affichez pas de matériau de clé privée ; extraire la clé publique suffit pour l’appariement.

11) Ce que chaque commande prouve (et ne prouve pas)

Tableau : Commandes d’inspection courantes et leurs limites

12) Dépanner les pannes TLS courantes

Commencez par des inspections en lecture seule. Ne modifiez pas les fichiers avant d’avoir identifié la cause.

Tableau : Symptôme TLS, cause probable, premier diagnostic sûr

13) Bonnes pratiques opérationnelles

• Commencez par l’analyse et la vérification en lecture seule ; préservez les originaux et leurs permissions.
• Ne remplacez jamais un certificat ou une clé fonctionnels sans créer un nouveau fichier et le vérifier d’abord.
• Restreignez l’accès aux clés via les permissions du système de fichiers ; auditez qui peut lire les clés privées.
• Ne collez pas de clés privées ni de PKCS#12 complets dans des tickets ou des journaux.
• Confirmez séparément le comportement de rechargement de l’application : certains serveurs exigent un redémarrage pour utiliser un nouveau certificat ou une nouvelle clé.
• Documentez explicitement l’ancre de confiance et la chaîne d’intermédiaires dans l’automatisation de déploiement.
• Rappelez-vous que openssl s_client est un outil de diagnostic ; il ne reproduit pas exactement la pile TLS, le magasin de confiance ou la politique de chaque application.

14) Liste de contrôle avant et après déploiement

Tableau : Contrôles de déploiement vérifiables rapidement

Conclusion

Pour diagnostiquer TLS, traitez l’analyse, la validation de chaîne, la vérification de nom d’hôte et la poignée de main réseau comme des étapes distinctes. Commencez par l’inventaire de version, inspectez les fichiers locaux en sécurité, puis testez le point de terminaison en direct avec SNI et des contrôles explicites du nom d’hôte. Gardez les conversions non destructives, n’exposez jamais de clés privées et vérifiez indépendamment le rechargement applicatif. Avec ces commandes OpenSSL 3.x et ces listes de contrôle, vous pouvez passer des symptômes aux correctifs étayés par des preuves rapidement et en toute sécurité.