Dans beaucoup de équipes IT, l’outil OpenSSL reste associé à des copier-coller depuis un ancien ticket Jira ou un vieux wiki. Pourtant, pour qui manipule des certificats TLS en production, quelques commandes bien maîtrisées transforment un diagnostic qui traîne en intervention pliée en quelques minutes. Lecture détaillée d’un certificat, vérification d’une chaîne PKI, contrôle d’une date qui expire trop tôt, comparaison d’une clé publique et d’une CSR, test d’un service distant en TLS 1.2 ou 1.3 : tout passe par les mêmes briques.
Cet article prend le parti de remettre à plat ces briques, de les classer et de les illustrer dans un contexte concret, celui d’une PME qui expose APIs, applications internes et équipements IoT industriels derrière un proxy HTTPS.
Le fil conducteur est simple : partir des problèmes réels qui tombent un lundi matin (un certificat qui ne charge plus sur nginx, un routeur LTE qui refuse un nouveau bundle, un audit de cybersécurité qui pointe une chaîne incomplète) et remonter méthodiquement à la commande OpenSSL adaptée. Pas de liste exhaustive ni de promenade théorique sur la cryptographie, mais des séquences reproductibles, avec un minimum de syntaxe à retenir et des réflexes à automatiser.
Le tout sans perdre de vue l’écosystème autour : configuration TLS côté reverse proxy, tests de surface avec des outils HTTP, et bonnes pratiques PKI adaptées à des équipes qui n’ont pas un PKI engineer à temps plein. Les exemples sont donnés avec OpenSSL récent, mais l’article montre aussi comment détecter une version trop ancienne qui ne supporte pas correctement TLS 1.3.
En bref
- Lire un certificat avec openssl x509 -text -noout reste la base pour vérifier sujet, émetteur, extensions et date qui expire.
- Comparer une CSR, une clé privée et un certificat se fait en calculant l’empreinte du modulus, afin de valider qu’ils correspondent bien.
- Tester la compatibilité TLS d’un service distant passe par openssl s_client, utile avant d’ajuster une configuration nginx ou un load balancer.
- Contrôler la chaîne PKI implique de suivre l’enchaînement Subject/Issuer et de reconstituer un fichier fullchain.pem propre.
- Automatiser ces vérifications dans vos scripts ou pipelines CI épargne des soirées perdues à trier des logs HTTPS peu bavards.
Lecture détaillée d’un certificat X.509 avec OpenSSL : ce qu’il faut vraiment regarder
Un certificat X.509 ressemble à un pavé illisible tant qu’aucune grille de lecture n’est posée. La commande centrale pour s’y retrouver reste la suivante, appliquée à un fichier PEM :
openssl x509 -in moncertificat.pem -text -noout
Le résultat déborde vite d’informations. Pour éviter de passer à côté de l’essentiel, autant se concentrer sur quelques blocs stables : le sujet, l’émetteur, la période de validité, les extensions, l’algorithme de signature et l’empreinte. Chaque élément porte une information exploitable pour un diagnostic concret.
Comprendre sujet, émetteur et usage attendu du certificat
Premier réflexe lors de la lecture : identifier pour qui le certificat a été émis et par qui. Les champs Subject et Issuer donnent respectivement l’entité destinataire et l’autorité de certification qui signe.
Un contrôle rapide de cohérence permet déjà de repérer un certificat autosigné utilisé par erreur sur une application exposée au public.
Dans un contexte IoT industriel, les champs CN (Common Name) et subjectAltName méritent une attention particulière. Le navigateur moderne, tout comme un agent embarqué proprement configuré, se base surtout sur les entrées de l’extension subjectAltName pour valider le nom. Un certificat limité à un CN historique peut fonctionner en labo, puis provoquer des erreurs en production sur un client plus strict.
D’ailleurs, beaucoup de pannes HTTP 400/SSL observées derrière des reverse proxies viennent d’un malentendu entre nom de DNS interne, CN et subjectAltName. La lecture complète du certificat avec OpenSSL évite alors de tout de suite incriminer nginx ou le load balancer. Couplé à un article comme cette ressource sur la sécurité HTTPS et TLS 1.3 avec nginx, le diagnostic devient beaucoup plus rationnel.
Dates de validité, champ expire et empreinte du certificat
Les champs Not Before et Not After fixent la fenêtre d’usage autorisée. Trop souvent, on ne regarde que la date de fin, alors que la date de début peut piéger un déploiement anticipé. Un certificat installé la veille de sa date d’activation conduira à des erreurs de vérification côté client, sans que la moindre alerte côté serveur n’évoque cette subtilité.
Vient ensuite la notion d’empreinte (fingerprint), généralement fournie en SHA1 ou SHA256. Cette empreinte permet de vérifier qu’un certificat reçu par e-mail, par API ACME ou depuis un portail d’autorité n’a pas été altéré. Dans un plan de secours, on peut ainsi comparer l’empreinte affichée dans une interface de gestion de certificats et celle calculée par openssl x509 -fingerprint.
Sur un parc distribué, cette empreinte sert aussi d’identifiant stable pour suivre l’évolution des certificats dans le temps. Un responsable sécurité peut conserver un tableau listant services, empreintes et dates de bascule, et repérer de suite la machine qui tourne encore avec un ancien certificat.
Algorithmes, clé publique et extensions critiques
Au-delà du sujet et des dates, l’algorithme de signature et la taille de la clé publique méritent d’être vérifiés. OpenSSL affiche la longueur (par exemple 2048 ou 4096 bits pour RSA) et le type de clé (RSA, EC). Pour une PME industrielle, rester sur RSA 2048 bits reste un compromis raisonnable entre performance et sécurité, surtout sur des gateways IoT ou des automates dont la puissance CPU n’est pas celle d’un serveur x86.
Les extensions comme Key Usage et Extended Key Usage indiquent les usages autorisés : authentification de serveur, de client, signature de code, etc. Un certificat limité à l’authentification de client ne fonctionnera pas comme certificat serveur TLS même si tous les autres champs paraissent corrects. Sans cette lecture attentive, on peut passer des heures dans une configuration nginx ou dans un audit TLS complexe sans jamais résoudre la cause réelle.
Pour des environnements soumis à des exigences de conformité fortes, la lecture de ces extensions avec OpenSSL constitue d’ailleurs un élément du contrôle PKI lors d’un audit de sécurité informatique. Elle permet de vérifier que les certificats déployés respectent bien la politique de certification interne et les contraintes imposées par les donneurs d’ordre.
Un premier réflexe à automatiser
Sur le terrain, la capacité à lire un certificat directement dans un shell, sans s’en remettre à une interface graphique, fait gagner un temps très concret. Reporter systématiquement cette tâche à un outil web ou à une calculette en ligne revient à dépendre d’un service extérieur pour un diagnostic de base. Or OpenSSL est déjà installé sur une large majorité de serveurs Linux, et même sur nombre de postes de travail techniques.
L’insight à garder en tête est simple : tant que la commande x509 n’a pas été lancée et lue, tout le reste du diagnostic TLS repose sur des suppositions.
Lecture et vérification d’une CSR avec OpenSSL : éviter les erreurs dès la demande de certificat
Avant d’obtenir un certificat signé, il y a la CSR (Certificate Signing Request). Beaucoup de problèmes TLS se fabriquent à ce stade sans que l’on s’en rende compte : mauvais CN, absence de subjectAltName, taille de clé inadaptée ou clef générée sur la mauvaise machine. OpenSSL fournit tout ce qu’il faut pour générer, relire et valider cette CSR avant de l’envoyer à la PKI interne ou à une AC publique.
Générer une CSR propre, reproductible et scriptable
La commande de base pour générer en une fois clé privée et CSR ressemble à ceci :
openssl req -sha256 -nodes -newkey rsa:2048 -keyout www.monsite.com.key -out www.monsite.com.csr
Cette séquence génère une clé RSA 2048 bits non protégée par passphrase, ce qui convient à un usage serveur web automatisé, mais moins à un stockage plus sensible. Pour garder le contrôle sur les champs de la CSR, l’usage d’un fichier de configuration reste plus fiable que les questions interactives.
Un exemple de fichier de détails CSR peut regrouper les sections [req], [dn] et [req_ext] avec la définition de subjectAltName. OpenSSL permet alors d’utiliser ce fichier directement :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout monsite.key -out monsite.csr -config <(cat csr_details.txt)
Ce mode de génération convient bien aux pipelines CI/CD qui préparent en amont les demandes de certificats pour des environnements de préproduction et de production, avec des DN cohérents et des DNS alternatifs correctement alignés.
Lecture et vérification de la CSR : sujet, clé publique, extensions
Une fois générée, la CSR se lit avec la commande suivante :
openssl req -noout -text -verify -in mon.domaine.com.csr
L’option -verify ajoute une vérification interne de la signature de la CSR, ce qui permet de s’assurer qu’elle n’est pas corrompue. La sortie reprend les mêmes éléments qu’un certificat : sujet, clé publique, extensions. C’est là que se vérifient les champs DNS dans subjectAltName, la longueur de la clé publique et le type d’algorithme.
Un cas courant chez les intégrateurs : générer une CSR sur une machine de recette, la copier sur un autre serveur, et installer le certificat signé sur un troisième hôte, avec au passage une confusion entre clé privée et CSR initiale. Lire la CSR avec OpenSSL permet de vérifier le nom de domaine, l’adresse IP éventuelle et le mail de contact avant envoi à une autorité.
Comparer CSR, clé privée et futur certificat via le modulus
Pour s’assurer qu’une CSR correspond bien à sa clé privée, OpenSSL propose une méthode simple : calculer l’empreinte MD5 du modulus de chaque objet cryptographique. Les commandes suivantes affichent cette empreinte pour un certificat, une clé privée et une CSR :
openssl x509 -in cert.pem -noout -modulus | openssl md5
openssl rsa -in privkey.pem -noout -modulus | openssl md5
openssl req -in request.csr -noout -modulus | openssl md5
Si les trois empreintes sont identiques, la triade CSR/clé privée/certificat correspond bien. Dans le cas contraire, il y a un mélange de fichiers, parfois créé par des scripts de déploiement un peu trop génériques ou par une gestion manuelle des répertoires /etc/ssl.
Pour une équipe qui gère plusieurs dizaines de certificats dans un contexte multi-environnements (LAB, PREPROD, PROD), cette vérification systématique devient un garde-fou quasi obligatoire. C’est d’autant plus vrai lorsqu’on combine ces certificats avec des automatismes d’outil web ou des déploiements conteneurisés, comme expliqués dans certains guides sur les certificats SSL et OpenSSL.
Gérer le sujet dans une PKI interne ou hybride
Dans une architecture PKI interne, la structure du DN (Distinguished Name) de la CSR importe autant que les DNS couverts. Les champs O, OU, L et C servent souvent à filtrer les demandes ou à appliquer des politiques de validation spécifiques. OpenSSL étant très souple, il est tentant de les remplir de manière fantaisiste lors d’un test. Sauf que ces tests finissent parfois en production.
Une pratique cohérente consiste à documenter un modèle de DN par type d’application (front web externe, API interne, équipement OT, etc.) et à intégrer ce modèle dans le fichier CSR de configuration. La lecture régulière des CSR avec OpenSSL permet de s’assurer que cette convention ne dérive pas au fil des ans.
Une CSR maîtrisée réduit la probabilité de se retrouver, quelques semaines plus tard, avec un certificat inutilisable en bordure de système ou sur un objet connecté difficile d’accès.
Vérifier un certificat et sa chaîne PKI avec OpenSSL : de la clé publique à fullchain.pem
Lire un certificat isolé ne suffit pas toujours. Pour que la vérification TLS aboutisse, la chaîne complète de certificats doit être cohérente : du certificat serveur jusqu’à la racine de confiance. OpenSSL offre les commandes nécessaires pour analyser cette chaîne, vérifier l’ordonnancement des certificats et détecter un élément manquant ou mal placé.
Identifier correctement chaque certificat de la chaîne
La première étape consiste à extraire ou isoler chaque certificat dans un fichier séparé, généralement au format PEM. Pour chacun, la commande suivante permet de repérer l’émetteur (Issuer) et le sujet (Subject) :
openssl x509 -in cert_intermediate.pem -text -noout | grep Issuer
openssl x509 -in cert_intermediate.pem -text -noout | grep Subject
L’objectif est de vérifier que le Subject de l’autorité intermédiaire correspond bien à l’Issuer du certificat placé au niveau inférieur. On remonte ainsi la chaîne jusqu’au certificat racine, dont l’issuer et le subject coïncident dans le cas d’une racine autosignée. Cette vérification évite un bug courant : l’inversion de deux intermédiaires ou l’oubli d’un maillon dans la chaîne.
Une fois la hiérarchie clarifiée, il convient de reconstituer un fichier fullchain.pem dans le bon ordre :
cat cert_serveur.pem > fullchain.pem
cat cert_ac1.pem >> fullchain.pem
cat cert_ac2.pem >> fullchain.pem
cat cert_root.pem >> fullchain.pem
Un contrôle visuel évitera les mélanges de lignes BEGIN CERTIFICATE et END CERTIFICATE, sources d’erreurs discrètes mais bloquantes.
Tableau de contrôle rapide des éléments PKI à vérifier
Pour garder les idées claires, un tableau de synthèse aide bien lors d’une opération de maintenance ou d’un audit ponctuel :
| Élément PKI | Commande OpenSSL | Objectif principal |
|---|---|---|
| Certificat serveur | openssl x509 -in cert.pem -text -noout | Lecture du sujet, de la date qui expire, de la clé publique et des extensions. |
| Autorité intermédiaire | openssl x509 -in ac.pem -text -noout | grep « Subject|Issuer » | Vérification de la cohérence Subject/Issuer pour la chaîne. |
| Chaîne complète | cat cert.pem ac.pem > fullchain.pem | Construction du fichier de chaîne pour serveur web ou broker MQTT. |
| Correspondance clé/cert | openssl rsa/x509/req … | openssl md5 | Validation entre clé privée, CSR et certificat via l’empreinte du modulus. |
| Racine autosignée | openssl x509 -in root.pem -noout -issuer -subject | Contrôle d’une racine dont l’issuer et le subject sont identiques. |
Ce type de tableau gagne à être copié dans une documentation interne et mis à jour lors de chaque évolution de la PKI. Il permet aux nouveaux arrivants de comprendre rapidement le paysage des certificats en circulation.
Contrôle de la chaîne avec s_client et vérification côté client
Une fois la chaîne assemblée côté serveur, la commande openssl s_client permet de vérifier comment elle est envoyée aux clients. Par exemple :
openssl s_client -connect monserveur.exemple.com:443 -showcerts
La sortie affiche tous les certificats fournis par le serveur. Il devient alors possible de comparer cette liste à ce qui était prévu dans fullchain.pem. Si un maillon manque, un client standard indiquera souvent une erreur de chaîne incomplète, que ce soit via un navigateur ou via un agent applicatif.
Dans un environnement industriel qui combine API web et flux MQTT, vérifier cette cohérence avec s_client avant de toucher à la configuration applicative fait gagner du temps et évite de culpabiliser à tort le code métier ou la passerelle IoT.
Repérer les chaînes faibles ou périmées
Une chaîne PKI n’est pas seulement un assemblage de fichiers. C’est aussi l’expression d’une politique de sécurité. En lisant chaque certificat avec OpenSSL, il devient possible de repérer un intermédiaire signé en SHA1 encore toléré par un vieux client, mais désormais rejeté par les stacks TLS modernes. Ou de constater que l’autorité intermédiaire expire avant même la fin du certificat serveur, ce qui entraînera une panne inattendue.
Pour les organisations qui entament une mise à niveau de leurs infrastructures TLS vers des versions récentes, cette étape de lecture de la chaîne avec OpenSSL constitue un passage obligé. Elle permet de planifier les remplacements de certificats intermédiaires, plutôt que d’attendre l’alerte d’un client final mécontent.
Le point à retenir ici : une chaîne PKI bien lue et validée avec OpenSSL vaut mieux que des heures de logs TLS incomplets.
Pour qui préfère voir les commandes dérouler en temps réel, une recherche vidéo comme celle ci-dessus donne un complément visuel utile, à croiser avec les exemples issus de vos propres serveurs.
Tester un service TLS distant avec OpenSSL s_client : vérifier, observer, comparer
La commande openssl s_client joue pour TLS le rôle que telnet jouait autrefois pour les ports TCP ouverts. Elle permet de se connecter à un service HTTPS, SMTP STARTTLS ou autre protocole chiffré, et d’observer en détail la négociation TLS, le certificat présenté et les paramètres choisis. Utilisée correctement, elle remplace avantageusement beaucoup de tâtonnements.
Tester la compatibilité TLS d’un service web ou SMTP
La forme la plus simple de s_client consiste à tester un port TLS donné :
openssl s_client -connect monsite.exemple.com:443
Cette commande affiche la négociation TLS, le certificat serveur et un résumé des algorithmes choisis. Pour un service SMTP avec STARTTLS, on utilisera plutôt :
openssl s_client -host srv_smtp -port 587 -starttls smtp
Dans les deux cas, la sortie permet de voir la version TLS, la ciphersuite retenue, le CN et la signature du certificat. Sur un incident où seul un type de client échoue, répéter ce test depuis une machine représentative du client incriminé permet d’écarter un problème de réseau pur.
Forcer une version TLS pour diagnostiquer une incompatibilité
Pour tester une version précise du protocole, s_client accepte des options comme -tls1_2 ou -tls1_3. Un script simple comme celui-ci illustre bien la démarche :
echo « Q » | openssl s_client -connect google.com:443 -brief -tls1_3
echo « Q » | openssl s_client -connect google.com:443 -brief -tls1_2
La sortie indique, entre autres, la version du protocole (Protocol version: TLSv1.3 ou TLSv1.2) et la ciphersuite sélectionnée. Ce test est précieux lorsque l’on doit décider de couper TLS 1.0 et 1.1 sur un reverse proxy, ou de refuser SSLv3 sur un équipement historique. Beaucoup de vieux clients embarqués ne supportent pas TLS 1.2, et un test ciblé avec s_client met ce fait en lumière sans passer par des logs d’application.
Pour anticiper ces effets de bord, certains administrateurs complètent ces tests par une vérification de la configuration TLS du frontend HTTP, par exemple via des ressources sur la configuration d’un load balancer nginx. La combinaison des deux approches, shell et configuration, réduit les surprises en production.
Inventorier les versions TLS supportées par un binaire OpenSSL
Avant même de tester un service distant, il peut être utile de savoir ce que son propre binaire OpenSSL sait faire. Une astuce consiste à examiner les suites cryptographiques disponibles et les versions TLS associées :
openssl ciphers -v | awk ‘{ print $2 }’ | sort | uniq
Sur un OpenSSL ancien, on verra parfois uniquement SSLv3. Sur une version plus récente, la sortie listera SSLv3, TLSv1, TLSv1.2 et TLSv1.3. Combinée avec openssl version, cette commande permet de repérer un système qui tourne encore avec un OpenSSL trop daté pour des politiques de sécurité actuelles.
Pour une entreprise qui déploie des sondes ou des gateways dans des sites distants, ce simple contrôle évite de découvrir trop tard qu’un firmware embarque encore une bibliothèque limitée à TLS 1.0.
Approche systématique lors d’un incident TLS
Lorsqu’un service HTTPS ne répond plus correctement, une séquence de tests s’articulant autour de s_client simplifie le raisonnement :
- Test brut de port avec openssl s_client -connect hote:port pour valider réponse et certificat.
- Tests forcés par version TLS pour repérer une incompatibilité spécifique.
- Lecture du certificat obtenu avec -showcerts et relecture via openssl x509.
- Éventuel test STARTTLS si le protocole le permet (SMTP, IMAP, etc.).
En combinant ces vérifications, il devient beaucoup plus simple de distinguer un problème de certificat qui expire, une ciphersuite devenue obsolète ou une simple erreur de configuration réseau. Ce type de check-list finit souvent noté dans un wiki interne à côté des commandes Linux de base, voire dans un mémo similaire à ceux qu’on trouve sur les commandes Linux essentielles.
Une dernière remarque : s_client ne remplace pas un scanner de sécurité complet, mais il reste l’outil de premier niveau pour poser un diagnostic technique précis juste après une alerte.
Une recherche vidéo sur s_client complète utilement cet usage, surtout pour les équipes pluridisciplinaires où tout le monde n’est pas à l’aise avec les négociations TLS en ligne de commande.
Manipuler les formats, gérer la passphrase et préparer l’automatisation autour d’OpenSSL
Une fois les certificats et la chaîne validés, restent des aspects très opérationnels : conversion entre formats, gestion de la passphrase sur la clé privée, intégration dans des scripts de déploiement. Ces sujets paraissent secondaires jusqu’au jour où un service critique refuse de redémarrer après une mise à jour de clé ou où une automatisation Ansible s’effondre à cause d’un prompt interactif inattendu.
Conversion entre PEM et DER : anticiper les contraintes des équipements
Beaucoup d’équipements réseau, d’appliances de sécurité ou de solutions de messagerie demandent des certificats au format DER, alors que les autorités de certification livrent souvent du PEM. OpenSSL rend la conversion triviale :
openssl x509 -inform der -in certificate.der -out certificate.pem
openssl x509 -outform der -in certificate.cer -out certificate.der
Maîtriser cette conversion évite les tests hasardeux et les copier-coller de sections BEGIN/END CERTIFICATE. Pour des flottes d’objets connectés, cette conversion se place souvent dans un script qui prépare les firmwares avant flashage, avec un contrôle préalable de l’empreinte du certificat.
Gérer ou supprimer la passphrase d’une clé privée
Protéger une clé privée par une passphrase reste une bonne pratique quand la clé n’est pas utilisée automatiquement. En revanche, sur un serveur web qui doit redémarrer sans intervention humaine, cette passphrase devient un handicap. OpenSSL permet de retirer cette protection :
openssl rsa -in withPassPhrase.key -out withoutPassPhrase.key
La commande demande la passphrase actuelle, puis recrée la clé privée en clair. Cette opération ne doit pas se faire à la légère. Elle implique de renforcer la protection d’accès au fichier (permissions Unix, chiffrement du volume, sauvegardes maîtrisées). Sur certains environnements, une alternative consiste à utiliser un coffre-fort de secrets ou un module matériel pour stocker la clé tout en gardant un niveau de sécurité élevé.
Pour des équipes qui automatisent tout via conteneurs et orchestrateurs, la question de la passphrase se discute autant en termes de sécurité que de disponibilité. Retirer systématiquement les passphrases sans réflexion crée une fausse impression de simplicité qui ne résiste pas à un audit sérieux.
Intégrer la vérification des certificats dans les scripts et pipelines
Les commandes décrites plus haut s’intègrent très bien dans des scripts Bash ou des jobs CI/CD. Par exemple, un pipeline peut :
1) Générer une CSR à partir d’un template.
2) Envoyer la CSR à une API de PKI et récupérer le certificat signé.
3) Vérifier la correspondance entre certificat et clé privée via l’empreinte du modulus.
4) Contrôler la date qui expire pour s’assurer de la durée souhaitée.
5) Déployer certificat, clé privée et fullchain.pem sur les serveurs concernés.
Une fois cette séquence automatisée, l’équipe gagne en traçabilité et réduit les erreurs manuelles de copie de fichiers, particulièrement fréquentes sur des fermes de serveurs ou des clusters IoT déployés à grande échelle.
Relier OpenSSL, configuration HTTP et supervision sécurité
OpenSSL n’est qu’une pièce du puzzle. Les certificats qu’il manipule alimentent aussi bien des serveurs web, des brokers MQTT, des reverse proxies que des applications industrielles spécifiques. L’intérêt de maîtriser ces commandes se voit clairement quand on croise ces informations avec la configuration HTTP, la supervision et les outils d’audit.
Sur un serveur nginx, par exemple, la bonne compréhension de la chaîne PKI et des formats facilite la mise en place de configurations TLS modernes, que ce soit en frontal d’applications web ou en rôle de répartiteur de charge. Les retours d’expérience publiés sur les infrastructures HTTP de nouvelle génération montrent d’ailleurs à quel point la compréhension d’OpenSSL simplifie les chantiers de migration TLS ou de durcissement de configuration.
En parallèle, les équipes sécurité peuvent s’appuyer sur ces mêmes commandes pour vérifier l’alignement entre ce qui est déployé sur le terrain et ce qui a été validé en phase de conception. La boucle se referme quand ces contrôles deviennent routiniers, au même titre que les commandes réseau ou système standard.
Comment vérifier rapidement le contenu d’un certificat avec OpenSSL ?
Utiliser la commande openssl x509 -in moncertificat.pem -text -noout permet d’afficher en clair le sujet, l’émetteur, la période de validité, la clé publique, l’algorithme de signature et les extensions. En se concentrant sur le Subject, l’Issuer, les dates Not Before/Not After et les champs subjectAltName, on obtient l’essentiel pour un diagnostic TLS de premier niveau.
Comment savoir si un certificat correspond bien à une clé privée et à une CSR ?
La méthode la plus robuste consiste à comparer l’empreinte MD5 du modulus pour chaque objet. Il faut exécuter successivement openssl rsa -in privkey.pem -noout -modulus | openssl md5, openssl req -in request.csr -noout -modulus | openssl md5 puis openssl x509 -in cert.pem -noout -modulus | openssl md5. Si les trois empreintes sont identiques, la clé privée, la CSR et le certificat correspondent bien.
Comment tester la compatibilité TLS d’un service HTTPS avec OpenSSL ?
La commande openssl s_client -connect hote:443 affiche la négociation TLS, le certificat présenté et la ciphersuite choisie. Pour forcer une version spécifique, il suffit d’ajouter -tls1_2 ou -tls1_3. En répétant ces tests depuis différents environnements, on identifie rapidement une incompatibilité de version TLS ou de ciphersuite entre client et serveur.
Que faire si la chaîne de certificats semble incomplète ?
Il faut d’abord lire chaque certificat intermédiaire avec openssl x509 -in fichier.pem -text -noout puis vérifier la cohérence entre Subject et Issuer. Ensuite, reconstituer un fichier fullchain.pem en plaçant d’abord le certificat serveur, puis les intermédiaires dans l’ordre, et éventuellement la racine si le logiciel la demande. Enfin, un test avec openssl s_client -connect hote:443 -showcerts permet de vérifier que la chaîne envoyée au client est complète.
Comment retirer la passphrase d’une clé privée pour un serveur web ?
Pour supprimer la passphrase d’une clé privée, il faut exécuter openssl rsa -in withPassPhrase.key -out withoutPassPhrase.key, puis saisir la passphrase lorsque la commande la demande. La nouvelle clé withoutPassPhrase.key n’est plus protégée et peut être utilisée par un serveur web qui doit redémarrer sans intervention humaine. Il reste indispensable de renforcer la protection des fichiers et de limiter les droits d’accès sur cette clé.