Diviseur de paquet PEM

L'outil PEM Bundle Splitter sépare un fichier contenant plusieurs certificats PEM concaténés en certificats individuels, en identifiant les certificats d'entité finale, intermédiaires et racine dans la chaîne -- indispensable pour déboguer les problèmes de chaîne TLS et extraire des certificats spécifiques depuis des bundles. Collez un bundle PEM avec plusieurs blocs -----BEGIN CERTIFICATE----- et obtenez chaque certificat individuellement avec son sujet et son émetteur identifiés.

Comprendre les bundles et chaînes de certificats

Lorsque vous configurez TLS sur un serveur web, vous n'installez pas qu'un seul certificat. Vous avez besoin d'une chaîne de certificats qui relie le certificat feuille de votre serveur à une CA racine de confiance pour les clients. Le certificat feuille dit « Je suis example.com, et j'ai été signé par la CA intermédiaire R3. » Le certificat intermédiaire dit « Je suis R3, et j'ai été signé par ISRG Root X1. » Le certificat racine dit « Je suis ISRG Root X1, et je me suis signé moi-même. » Les clients vérifient cette chaîne de bas en haut, et si un maillon est manquant ou cassé, la connexion échoue.

Les autorités de certification livrent généralement ces certificats sous forme d'un fichier PEM unique avec plusieurs blocs de certificats concaténés -- un bundle. Parfois le bundle est dans le bon ordre, parfois non, et parfois il inclut des certificats dont vous n'avez pas besoin (comme la racine, que les clients possèdent déjà). Le problème est qu'un bundle PEM n'est qu'un mur de texte base64 avec des marqueurs BEGIN/END répétés, et il est pratiquement impossible de distinguer quel certificat est lequel en regardant le texte brut.

Ce splitter résout ce problème. Collez votre bundle et l'outil sépare chaque certificat, analyse ses champs Subject et Issuer, et l'identifie comme feuille, intermédiaire ou racine. Vous pouvez ensuite inspecter chaque certificat individuellement, les réordonner, supprimer ceux qui sont inutiles ou copier des certificats spécifiques pour différentes configurations. C'est un outil de débogage essentiel lorsque vous obtenez une erreur « certificate not trusted » ou « unable to verify the first certificate » et que vous devez comprendre ce qui se trouve réellement dans votre fichier de chaîne.

Comment séparer un bundle de certificats PEM

1. Collez votre bundle PEM contenant plusieurs blocs -----BEGIN CERTIFICATE-----
2. L'outil identifie et sépare chaque certificat du bundle
3. Examinez le Subject et l'Issuer analysés pour chaque certificat extrait
4. Copiez ou téléchargez les certificats individuels selon vos besoins

Exemple : séparation d'une chaîne de trois certificats

Entrée -- un bundle PEM concaténé :

-----BEGIN CERTIFICATE-----
MIIFjTCCBHWgAwIBAgIS...  (leaf certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIR...  (intermediate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQ...  (root)
-----END CERTIFICATE-----

Sortie -- trois certificats identifiés individuellement :

Quand utiliser cet outil

• Débogage d'échecs de handshake TLS -- séparez une chaîne pour identifier les intermédiaires manquants, un mauvais ordonnancement ou des certificats en doublon causant des erreurs SSL
• Extraction de certificats spécifiques -- extrayez un intermédiaire unique depuis un bundle fourni par une autorité de certification
• Réordonnancement de chaîne de certificats -- certains serveurs web exigent un ordre précis (leaf en premier, puis les intermédiaires) ; séparez la chaîne pour la reconstruire correctement
• Audit de bundles de certificats -- identifiez rapidement le contenu d'un fichier bundle sans exécuter manuellement openssl x509 sur chaque certificat
• Préparation multi-plateformes -- extrayez les certificats individuellement pour les systèmes nécessitant des fichiers séparés (par ex. imports Java KeyStore)
• Réponse aux incidents -- décomposez rapidement une chaîne d'un serveur en panne pour identifier quel certificat cause le problème

Fonctionnement des chaînes de certificats PEM

Un bundle PEM est simplement plusieurs certificats PEM concaténés dans un seul fichier. Chaque certificat commence par -----BEGIN CERTIFICATE----- et se termine par -----END CERTIFICATE-----, avec les données DER encodées en base64 entre les marqueurs.

Ordre correct de la chaîne

L'ordre standard de la chaîne pour les serveurs TLS est :

1. Certificat leaf -- le certificat de votre serveur (celui de votre domaine)
2. Certificat(s) intermédiaire(s) -- une ou plusieurs CA entre le leaf et la racine
3. Certificat racine (optionnel) -- l'ancre de confiance ; la plupart des configurations l'omettent car les clients disposent des certificats racine dans leur magasin de confiance

Problèmes de chaîne courants détectés par le splitter

Exigences de chaîne selon les logiciels serveur

Les différents serveurs gèrent les fichiers de chaîne différemment :

• nginx -- ssl_certificate attend le leaf plus les intermédiaires dans un seul fichier, leaf en premier
• Apache -- SSLCertificateFile pour le leaf, SSLCertificateChainFile pour les intermédiaires
• HAProxy -- fichier unique avec leaf + intermédiaires + clé privée concaténés
• IIS -- importe les bundles PKCS#12 (.pfx) via l'interface graphique ; la chaîne est installée séparément

Débogage des chaînes de certificats en pratique

Le problème de chaîne le plus courant est un certificat intermédiaire manquant. C'est difficile à diagnostiquer car les navigateurs de bureau fonctionnent souvent correctement -- ils mettent en cache les intermédiaires des connexions précédentes et peuvent récupérer ceux manquants via l'extension Authority Information Access (AIA). Mais les clients non-navigateurs comme curl, la bibliothèque requests de Python, les applications mobiles et les appareils IoT n'effectuent pas de récupération AIA. Ils dépendent entièrement du serveur pour envoyer une chaîne complète. Si votre site web fonctionne dans Chrome mais échoue avec curl, un intermédiaire manquant est presque certainement la cause.

Pour diagnostiquer cela, récupérez la chaîne de votre serveur avec openssl s_client -connect votreserveur.com:443 -showcerts, collez la sortie dans ce splitter et vérifiez si tous les intermédiaires sont présents. Comparez l'Issuer de chaque certificat avec le Subject du suivant. S'il y a un écart -- l'Issuer d'un certificat ne correspond au Subject d'aucun autre certificat du bundle -- il vous manque un intermédiaire qui doit être ajouté.

Un autre problème fréquent est l'inclusion du certificat racine dans la chaîne. Bien que ce ne soit pas techniquement une erreur, cela gaspille de la bande passante car les clients possèdent déjà les certificats racine dans leurs magasins de confiance. Chaque handshake TLS envoie la chaîne complète, donc un certificat racine inutile de 1 à 2 Ko s'accumule sur des millions de connexions. Utilisez le splitter pour identifier la racine (son Subject et son Issuer sont identiques) et retirez-la de votre bundle, sauf si vous déployez dans des environnements avec des magasins de confiance non standards.

Questions fréquentes

Comment savoir quel certificat est le leaf et lesquels sont les intermédiaires ? Le certificat leaf (entité finale) a un Subject qui correspond à votre nom de domaine et son Issuer est une CA, pas lui-même. Les certificats intermédiaires ont un Subject qui correspond à l'Issuer du certificat situé en dessous d'eux dans la chaîne. Un certificat racine est auto-signé -- son Subject et son Issuer sont identiques.

Pourquoi mon navigateur fonctionne mais d'autres clients échouent ? Les navigateurs mettent souvent en cache les certificats intermédiaires des connexions précédentes ou récupèrent les intermédiaires manquants via l'extension Authority Information Access (AIA). Les clients non-navigateurs (curl, applications mobiles, clients API) n'effectuent généralement pas de récupération AIA, et échouent donc si votre serveur n'envoie pas la chaîne complète. Utilisez le splitter pour vérifier que votre bundle inclut tous les intermédiaires nécessaires.

Dois-je inclure le certificat racine dans mon bundle ? En règle générale, non. Les certificats racine sont préinstallés dans les magasins de confiance des clients, et les envoyer gaspille de la bande passante (généralement 1 à 2 Ko par handshake). Cependant, certains environnements spécialisés (équipements embarqués, CA internes) peuvent nécessiter la racine dans la chaîne. Le splitter identifie les certificats racine afin que vous puissiez décider de les inclure ou non.

Que faire si mon bundle contient des certificats dans le mauvais ordre ? Séparez le bundle, identifiez le rôle de chaque certificat, puis réassemblez-le avec le PEM Bundle Merger qui détermine automatiquement l'ordre correct. La plupart des serveurs web modernes tolèrent les chaînes dans le désordre, mais certains clients plus anciens peuvent échouer si le leaf n'est pas en premier.

Comment obtenir la chaîne de certificats d'un serveur en fonctionnement ? Exécutez openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null pour récupérer la chaîne complète au format PEM. Copiez la sortie incluant tous les blocs BEGIN/END CERTIFICATE et collez-la dans le splitter.

Outils associés

• PEM Bundle Merger - Réassembler des certificats individuels en une chaîne correctement ordonnée
• X.509 Certificate Viewer - Inspecter les détails complets de chaque certificat extrait
• Certificate Expiry Checker - Vérifier les dates d'expiration de chaque certificat de la chaîne
• SAN Extractor - Extraire les Subject Alternative Names du certificat leaf
• Convert DER to PEM - Convertir des certificats DER binaires au format PEM avant bundling