Fusionneur de paquet PEM

L'outil PEM Bundle Merger combine plusieurs certificats PEM individuels en un fichier de chaîne de certificats correctement ordonné, en déterminant automatiquement la séquence correcte de l'entité finale à la racine -- une étape essentielle pour configurer le TLS sur des serveurs web comme nginx, Apache et HAProxy. Collez vos certificats dans n'importe quel ordre et obtenez une chaîne correctement assemblée, prête pour le déploiement.

Comprendre l'assemblage des chaînes de certificats

Chaque connexion TLS exige que le serveur présente une chaîne de certificats permettant au client de construire un chemin de confiance du certificat feuille du serveur à une CA racine de confiance. Si la chaîne est incomplète ou dans le mauvais ordre, les clients rejetteront la connexion avec des erreurs comme « unable to verify the first certificate » ou « certificate chain too long ». Construire correctement cette chaîne est l'une des tâches les plus courantes de l'administration de serveurs TLS, et il est étonnamment facile de se tromper.

La difficulté vient du fait que les autorités de certification livrent souvent les certificats en plusieurs morceaux. Vous pourriez recevoir votre certificat feuille dans un e-mail, l'intermédiaire dans un autre, et la racine depuis une page de téléchargement séparée. Ou bien votre outil d'automatisation génère une CSR et ne reçoit en retour que le feuille, vous laissant trouver le bon intermédiaire par vous-même. Le résultat est une collection de fichiers PEM individuels qui doivent être assemblés dans le bon ordre avant que votre serveur web ne les accepte.

Cet outil de fusion automatise cet assemblage. Collez tous vos certificats dans n'importe quel ordre, et l'outil analyse les champs Subject et Issuer de chacun pour déterminer lequel est le feuille, lesquels sont les intermédiaires et lequel est la racine. Il les affiche ensuite dans la séquence correcte : feuille en premier, suivi des intermédiaires, avec la racine optionnellement en dernier. La sortie est un fichier PEM unique que vous pouvez intégrer directement dans votre configuration nginx ou Apache.

Comment fusionner des certificats PEM en une chaîne

1. Collez vos certificats PEM individuels (dans n'importe quel ordre)
2. L'outil analyse les champs Subject et Issuer pour déterminer l'ordre correct de la chaîne
3. Vérifiez la chaîne ordonnée automatiquement ainsi que les éventuels avertissements de validation
4. Copiez ou téléchargez le bundle PEM fusionné

Exemple : construction d'une chaîne de certificats

Entrée -- trois certificats collés dans le mauvais ordre :

Certificate 1: CN=R3, O=Let's Encrypt  (intermediate)
Certificate 2: CN=ISRG Root X1         (root)
Certificate 3: CN=www.example.com      (leaf)

Sortie -- chaîne correctement ordonnée :

La sortie fusionnée est un fichier PEM unique avec les certificats concaténés dans le bon ordre, prêt pour le déploiement sur le serveur.

Quand utiliser cet outil

• Assemblage de certificats fournis par la CA -- de nombreuses autorités de certification livrent le certificat leaf et les intermédiaires sous forme de fichiers séparés que vous devez concaténer dans le bon ordre
• Correction de chaînes cassées -- reconstruisez une chaîne de certificats qui provoque des erreurs « unable to verify the first certificate » ou « incomplete chain »
• Préparation au déploiement serveur -- créez un fichier de chaîne correctement formaté pour le ssl_certificate de nginx, le SSLCertificateChainFile d'Apache ou les bundles PEM de HAProxy
• Construction de chaîne multi-sources -- combinez des certificats de différentes origines (racine téléchargée, intermédiaire émis, leaf généré) en une chaîne unifiée
• Renouvellement de certificat -- fusionnez un nouveau certificat leaf avec les certificats intermédiaires existants après renouvellement
• Chaînes multi-intermédiaires -- assemblez des chaînes avec deux intermédiaires ou plus (courant chez certaines CA commerciales) dans le bon ordre

Fonctionnement de l'ordre des chaînes de certificats

Le protocole TLS exige que les certificats soient présentés dans un ordre précis lors du handshake. Le serveur envoie sa chaîne au client, et le client doit pouvoir construire un chemin de confiance du leaf jusqu'à une CA racine de confiance.

Logique de validation de la chaîne

L'outil de fusion vérifie la chaîne en faisant correspondre le champ Issuer de chaque certificat au champ Subject du certificat suivant :

Leaf:         Subject=CN=www.example.com
              Issuer=CN=R3, O=Let's Encrypt
                 | (Issuer matches next Subject)
Intermediate: Subject=CN=R3, O=Let's Encrypt
              Issuer=CN=ISRG Root X1
                 | (Issuer matches next Subject)
Root:         Subject=CN=ISRG Root X1
              Issuer=CN=ISRG Root X1  (self-signed)

Erreurs de chaîne courantes détectées

L'outil signale les problèmes détectés lors de l'assemblage :

• Intermédiaire manquant -- une lacune existe lorsque le Subject d'aucun certificat ne correspond à l'Issuer du certificat précédent
• Certificats en doublon -- le même certificat apparaît plusieurs fois dans l'entrée
• Cycle détecté -- les certificats forment une boucle au lieu d'une chaîne linéaire
• Plusieurs certificats leaf -- plus d'un certificat n'est l'Issuer d'aucun autre certificat dans l'entrée
• Racine superflue -- le certificat racine auto-signé est inclus ; la plupart des configurations serveur devraient l'omettre

Configuration serveur pour les chaînes fusionnées

Après fusion, utilisez le fichier de chaîne dans votre configuration serveur :

nginx :

ssl_certificate     /etc/ssl/certs/example.com-chain.pem;
ssl_certificate_key /etc/ssl/private/example.com.key;

Apache :

SSLCertificateFile    /etc/ssl/certs/example.com.crt
SSLCertificateChainFile /etc/ssl/certs/example.com-chain.pem

HAProxy s'attend à ce que la clé privée soit ajoutée à la suite de la chaîne dans un fichier unique.

Assemblage de chaînes en pratique

L'erreur la plus courante lors de la construction de chaînes est de confondre quel certificat intermédiaire utiliser. Les grandes CA comme DigiCert et Sectigo maintiennent plusieurs intermédiaires, et utiliser le mauvais produit une chaîne qui semble complète mais échoue à la validation car le chaînage Subject/Issuer est cassé à une étape. Lorsque vous recevez votre certificat de la CA, téléchargez toujours les intermédiaires depuis la même commande ou la même page -- ne réutilisez pas les intermédiaires d'une commande de certificat précédente, car la CA a pu effectuer une rotation de ses intermédiaires depuis.

Un autre piège fréquent est d'inclure la CA racine dans la chaîne pour les serveurs publics. Bien que techniquement inoffensif, cela gaspille de la bande passante et ne sert à rien car les clients possèdent déjà les certificats racine dans leurs magasins de confiance. L'exception concerne les déploiements internes avec une CA privée, où la racine n'est pas préinstallée dans les magasins de confiance des clients et doit être incluse dans la chaîne ou installée sur les clients séparément. Si vous n'êtes pas sûr d'inclure la racine ou non, laissez-la de côté pour les serveurs publics et incluez-la pour les services internes.

Après avoir assemblé votre chaîne, testez-la toujours avant de la déployer en production. La vérification la plus rapide est openssl verify -untrusted chain.pem leaf.pem, qui parcourt la chaîne et signale toute erreur de validation. Vous pouvez également tester le déploiement complet avec openssl s_client -connect votreserveur.com:443 et vérifier que la sortie montre une chaîne valide avec des entrées de profondeur 0, 1 et 2. Si openssl s_client affiche « Verify return code: 0 (ok) », votre chaîne est correcte.

Questions fréquentes

Dois-je inclure le certificat racine dans la chaîne fusionnée ? Pour les serveurs exposés publiquement, non. Les certificats racine sont préinstallés dans les magasins de confiance des clients (navigateurs, systèmes d'exploitation). Inclure la racine ajoute des octets inutiles à chaque handshake TLS. Omettez-la sauf si vous déployez dans un environnement où les clients pourraient ne pas avoir la racine préinstallée, comme les systèmes embarqués ou les déploiements de CA privée.

Dans quel ordre doivent être les certificats ? L'ordre correct est : le certificat leaf en premier, suivi des intermédiaires dans l'ordre du plus proche du leaf au plus proche de la racine, avec la racine optionnellement en dernier. Cet outil gère l'ordonnancement automatiquement. Si votre CA fournit un fichier « CA bundle » séparé, il contient les intermédiaires dans le bon ordre -- il suffit d'y ajouter votre certificat leaf au début.

Pourquoi ai-je l'erreur "unable to get local issuer certificate" après déploiement de ma chaîne ? Cette erreur signifie généralement qu'un certificat intermédiaire requis est absent de votre chaîne. Utilisez le PEM Bundle Splitter pour examiner les certificats réellement présents dans votre fichier, puis ajoutez les intermédiaires manquants. Vérifiez également que la chaîne est dans le bon ordre -- certains serveurs sont sensibles à l'ordonnancement.

Puis-je fusionner des certificats de différentes CA ? Pas en une seule chaîne valide. Une chaîne de certificats doit suivre un unique chemin de confiance où l'Issuer de chaque certificat correspond au Subject du suivant. Des certificats de CA différentes ont des chemins de confiance différents et ne peuvent pas être combinés en une seule chaîne. Si vous devez servir plusieurs certificats (par ex. RSA et ECDSA), configurez votre serveur pour utiliser des chaînes séparées pour chacun.

Comment vérifier que ma chaîne fusionnée est correcte ? Utilisez OpenSSL pour valider : openssl verify -untrusted chain.pem leaf.pem. Un résultat réussi affiche « leaf.pem: OK ». Vous pouvez également vérifier une chaîne déployée avec openssl s_client -connect votreserveur.com:443 et rechercher « Verify return code: 0 (ok) » dans la sortie.

Que faire si ma CA fournit un seul fichier "full chain" ? Certaines CA fournissent un fichier unique contenant déjà le leaf et les intermédiaires dans le bon ordre. Dans ce cas, vous pouvez l'utiliser directement sans fusion. Si vous n'êtes pas sûr du contenu, collez-le d'abord dans le PEM Bundle Splitter pour inspecter chaque certificat, puis refusionnez si nécessaire.

Outils associés

• PEM Bundle Splitter - Séparer une chaîne existante pour inspecter les certificats individuels avant de les refusionner
• X.509 Certificate Viewer - Inspecter les détails de chaque certificat pour vérifier le bon assemblage de la chaîne
• Certificate Expiry Checker - Vérifier que tous les certificats de la chaîne fusionnée ont des dates valides
• TLS Config Snippet Builder - Générer une configuration serveur à utiliser avec votre chaîne fusionnée
• Convert DER to PEM - Convertir des certificats DER au format PEM avant fusion