## 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

Élément à consigner	Exemple de preuve	Pourquoi c’est important
Version d’OpenSSL	OpenSSL 3.0.13	Détermine les options de commande et le comportement de vérification
Configuration de build	Options avec fournisseur FIPS (Federal Information Processing Standards)	Explique la disponibilité des providers et les algorithmes autorisés
OPENSSLDIR	OPENSSLDIR: /etc/ssl	Emplacement des CAfile et CApath par défaut
Confiance par défaut	Valeurs CAfile et CApath	Influence les décisions de confiance de s_client et verify
OS et shell	Linux x86_64, bash	Reproductibilité des commandes et des chemins

## 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 -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 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 :443 -servername \ -showcerts -verify_return_error &1 | grep -i verify_hostname || echo "Option not supported" Si pris en charge (OpenSSL 3.x recommandé) : openssl s_client -connect :443 -servername \ -verify_hostname -verify_return_error -untrusted Preuve attendue : : 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 -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 -noout -subject - Reconnaitre une clé privée sans l’exposer : openssl pkey -in -noout Tableau : Formats et matrice de conversion (non destructif)

De	Vers	Commande	Étape de vérification
Certificat PEM	Certificat DER (Distinguished Encoding Rules — binaire ASN.1)	openssl x509 -in <certificate.pem> -outform DER -out <certificate.der>	openssl x509 -in <certificate.der> -inform DER -noout -subject
Certificat DER	Certificat PEM	openssl x509 -in <certificate.der> -inform DER -out <certificate.pem.new>	openssl x509 -in <certificate.pem.new> -noout -subject
Paquet PKCS#12 (Public-Key Cryptography Standards #12)	Certificat feuille PEM	openssl pkcs12 -in <bundle.p12> -clcerts -nokeys -out <leaf-cert.pem>	openssl x509 -in <leaf-cert.pem> -noout -subject
Paquet PKCS#12	Clé PEM chiffrée	openssl pkcs12 -in <bundle.p12> -nocerts -out <key.pem>	openssl pkey -in <key.pem> -noout
Certificat et clé PEM	Paquet PKCS#12	openssl pkcs12 -export -inkey <key.pem> -in <certificate.pem> -out <bundle.p12>	openssl pkcs12 -in <bundle.p12> -info -nokeys

## 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 -info -nokeys - Exporter uniquement le certificat feuille (sans clés) : openssl pkcs12 -in -clcerts -nokeys -out - Exporter une clé privée chiffrée (une phrase secrète de sortie vous sera demandée) : openssl pkcs12 -in -nocerts -out É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 -noout -pubkey | openssl sha256 - Depuis la clé privée : openssl pkey -in -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

Commande	Prouve	Ne prouve pas
openssl x509 -in <certificate.pem> -noout -text	Champs du certificat, SAN, fenêtre de validité	Confiance jusqu’à une racine, propriété du nom d’hôte, connectivité en direct
openssl x509 -checkend N -in <certificate.pem>	Si l’expiration franchit N	Si une AC renouvellera, comportement de rechargement de l’application
openssl s_client -connect -servername -showcerts	Réussite de la poignée de main TLS, chaîne présentée	Vérification du nom d’hôte sans -verify_hostname, politique spécifique à l’application
openssl s_client -verify_hostname <host>	Contrôle d’identité du nom d’hôte via SAN et chaîne	Que votre OS ou appli utilise le même magasin de confiance ou la même politique de chiffrement
openssl verify -CAfile -untrusted <leaf.pem>	Chaîne de signatures jusqu’à l’ancre, l’heure, et la finalité si spécifiée	Concordance du nom d’hôte, configuration serveur en direct
openssl req -in <request.csr> -verify	Intégrité de la CSR et possession de clé à la création	Identité du demandeur ou approbation par une CA

## 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

Symptôme	Cause probable	Premier diagnostic sûr
Poignée de main OK, le navigateur affiche un nom non concordant	SAN erroné ou mauvais hôte virtuel	openssl s_client -connect <host>:443 -servername <host> -verify_hostname <host> </dev/null
Échec de la poignée de main avec certificat expiré	Certificat expiré ou pas encore valide	openssl x509 -in <certificate.pem> -noout -dates et -checkend N
Erreur CA inconnue ou auto-signé	Racine non approuvée ou ancre de confiance manquante	openssl verify -CAfile <root-ca.pem> <leaf.pem>
Fonctionne sur certains clients, pas d’autres	Intermédiaire manquant ou erroné côté serveur	openssl s_client -connect <host>:443 -showcerts </dev/null
Certificat correct, mauvais site quand même	Oubli de -servername (SNI) côté client ou routage serveur	openssl s_client -connect <host>:443 -servername <host> </dev/null
Pannes sporadiques selon l’heure	Horloge système décalée	date côté client et serveur ; vérifiez notBefore et notAfter

## 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

Phase	Élément de la liste	Preuve
Avant déploiement	OpenSSL 3.x disponible et consigné	openssl version -a archivé dans les journaux
Avant déploiement	Le SAN du certificat feuille inclut les hôtes cibles	openssl x509 -in <certificate.pem> -noout -ext subjectAltName
Avant déploiement	La chaîne se valide jusqu’à l’ancre de confiance voulue	openssl verify -CAfile <root-ca.pem> -untrusted <intermediate.pem> <leaf.pem>
Avant déploiement	La clé correspond au certificat	Empreintes SHA-256 identiques des clés publiques dérivées
Après déploiement	Le serveur présente la chaîne complète	openssl s_client -connect <host>:443 -servername <host> -showcerts </dev/null
Après déploiement	La vérification de nom d’hôte réussit	openssl s_client -connect <host>:443 -servername <host> -verify_hostname <host> </dev/null
Après déploiement	Rechargement ou redémarrage de l’appli confirmé	Journaux applicatifs et audit de configuration versionné

## 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é.