Outils de développement · Encodeur et décodeur Base64
PEM expliqué : pourquoi les certificats et les clés sont en Base64 entre BEGIN et END
· Contexte
base64 codage
Un fichier PEM est un binaire DER enveloppé en Base64 avec des lignes d'armure étiquetées. Cet article explique les origines du format, ses règles de ligne et ce que vous pouvez et ne pouvez pas apprendre en en décodant un.
Le certificat qui « ressemble à du texte » mais ne parvient pas à être analysé : une faute de frappe dans l'en-tête, un retour chariot parasite et le format en dessous
Un fichier PEM est un binaire codé en Base64 enveloppé dans des étiquettes de texte. Le nom vient de Privacy-Enhanced Mail (RFC 1421, 1992), qui utilisait ce format pour les messages cryptés. Le format survit aujourd'hui dans les certificats TLS, les clés SSH et les clés GPG. La structure est simple : une ligne disant -----BEGIN CERTIFICATE----- (ou BEGIN PRIVATE KEY, BEGIN PUBLIC KEY, etc.), suivie de lignes de caractères 64 de texte base64, suivies de -----END CERTIFICATE-----.
Le corps base64 décode dans un format binaire appelé DER (Distinguished Encoding Rules), qui est un moyen de sérialiser les données structurées (en particulier les structures ASN.1). Le décodage du base64 vous donne du binaire ; la lecture du binaire nécessite de comprendre ASN.1, ce qui est complexe. L'armure PEM existe parce que les fichiers binaires sont difficiles à envoyer par courrier électronique et à modifier. Un fichier de certificat sous forme binaire pure serait corrompu s'il était transmis via d'anciens systèmes de messagerie, USENET ou des formulaires Web.
L'armure de texte visible dans un bloc PEM — étiquettes autour d'un corps Base64
En codant le binaire en base64 et en l'enveloppant dans des étiquettes de texte, l'intégralité du certificat devient un texte ASCII 7 bits qui survit à tout transport. Un éditeur de texte peut l'ouvrir ; un système de messagerie ne le corrompra pas. Les lignes -----BEGIN et -----END sont des étiquettes pour les humains et les outils automatisés ; ils indiquent clairement le type de données qui se trouvent à l'intérieur. Un certificat est étiqueté CERTIFICAT ; une clé privée est étiquetée PRIVATE KEY.
L'étiquette n'est pas vérifiée par un logiciel cryptographique ; c'est juste un indice pour les humains et les outils. La limite de lignes de caractères 64 dans PEM provient de la RFC 1421 et du même raisonnement MIME que la base de courrier électronique 64 : les anciens systèmes de messagerie avaient des limites de longueur de ligne et les caractères 64 tenaient sur un terminal des années 1980. PEM encapsule la sortie base64 en 64 caractères avec une fin de ligne (CR LF sous Windows, LF sous Unix).
Du texte étiqueté aux octets décodés — ce référentiel n'établit pas l'historique du format
Lors du décodage d'un certificat PEM, l'analyseur doit supprimer les lignes d'armure (-----BEGIN..., -----END...) et les sauts de ligne, puis décoder en base64 le reste. Un retour chariot parasite ou une étiquette incompatible peut interrompre l'analyse. Le retour à la ligne ne fait pas partie de la norme base64 (la RFC 4648 base64 est déballée) ; c'est spécifique à PEM. À l’intérieur de la base64 se trouve un binaire codé en DER. DER est ASN.1 (Abstract Syntax Notation), une spécification complexe pour représenter les structures de données.
Un certificat est un enregistrement structuré contenant un nom de sujet, une clé publique, une signature et des métadonnées. ASN.1 ne décrit pas directement les octets ; il décrit comment la structure doit être codée.
Anatomie du bloc comme entrée de cet outil - supprimez les étiquettes et transmettez uniquement le corps Base64
L'encodage commence par des triplets tag-longueur-valeur. Par exemple, une SÉQUENCE dans ASN.1 est codée sous la forme d'une balise 0x30, suivie de la longueur du contenu, suivie du contenu lui-même. Un certificat commence toujours par les octets 0x30 0x82 (séquence, longueur codée sur deux octets), qui apparaissent comme MII en base64.
Vérifier un certificat sans l'analyser : les trois premiers caractères d'un corps de certificat PEM sont presque toujours MII (qui est 0x30 0x82 en base64, le début d'une SEQUENCE). Si un bloc PEM ne décode pas en 0x30, la base64 est corrompue ou l'étiquette est erronée. L'outil d'encodeur et de décodage Base64 peut décoder le corps et vous montrer l'hexagone : collez les lignes base64 (sans les armures -----BEGIN et END), supprimez les sauts de ligne et décodez.
Ce que le décodage expose : octets binaires, champs de certificat non analysés
Si la sortie est binaire commençant par 30 82, il s'agit probablement d'une structure de certificat valide. S'il s'agit de charabia ou de texte, le décodage a échoué ou la base64 est erronée. Erreurs PEM courantes : une incompatibilité d'étiquette (par exemple, un corps de certificat avec une étiquette PRIVATE KEY), un problème de fin de ligne Windows (certains analyseurs s'étouffent avec CRLF), une faute de frappe dans la ligne d'armure (espaces ou caractères supplémentaires) ou des sauts de ligne manquants.
Les outils attendent -----BEGIN CERTIFICATE----- et non -----BEGIN CERT----- ou BEGIN CERTIFICATE. Copier-coller un PEM à partir d'un navigateur Web ou d'un PDF peut introduire des guillemets Unicode ou des guillemets intelligents au lieu de guillemets ASCII, brisant ainsi l'étiquette. Coller une clé privée dans un champ de certificat est une erreur courante ; l'analyseur le rejettera car l'étiquette ne correspond pas. PEM prend en charge plusieurs blocs dans un seul fichier.
Exemple pratique : décoder un corps court et inspecter les octets sans affirmer de signature de certificat
Un fichier de clé SSH peut contenir à la fois une clé privée (étiquetée PRIVATE KEY) et une clé publique (étiquetée PUBLIC KEY), ou plusieurs blocs de certificat. Un analyseur lit le fichier par le haut, recherchant les lignes commençant par -----BEGIN. Lorsqu'il en trouve un, il lit jusqu'à -----END avec l'étiquette correspondante, extrait et décode en base64 le corps et le traite. Ensuite, il continue à chercher le bloc suivant.
Une chaîne de certificats concaténée accidentellement (plusieurs blocs PEM pour un certificat et ses intermédiaires) dans un fichier est valide si toutes les étiquettes sont correctes. Le format PEM a été normalisé pour le courrier à confidentialité améliorée (RFC 1421) au début des années 1990.
Ce que cela ne couvre pas : analyse des structures ASN.1, cryptage par clé privée et bundles PKCS#12
RFC 7468 (2015) a modernisé la définition, clarifiant les règles de longueur de ligne, le format de ligne de blindage et les cas extrêmes. La plupart des outils et des normes font désormais référence à la RFC 7468. D'autres formats binaire-texte existent (comme DER-to-hex pour certains protocoles), mais PEM avec les étiquettes base64 et ASCII est la norme de facto pour la cryptographie et TLS car il est lisible par l'homme, en texte brut et facile à copier ou à envoyer.
Construire un bloc PEM : prenez le binaire DER (par exemple, un certificat d'une bibliothèque cryptographique), encodez-le en base64, enveloppez le résultat à 64 caractères avec des sauts de ligne et entourez-le de lignes -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----. Analyse d'un bloc PEM : recherchez les lignes -----BEGIN et -----END, extrayez le corps en base64 (en supprimant l'armure et les sauts de ligne), décodez en base64 pour obtenir le binaire, puis analysez le binaire DER et ASN.1.
À retenir : PEM est Base64 avec des étiquettes - comment l'encodeur et le décodeur Base64 vous donnent un endroit local pour essayer le corps Base64 d'un bloc, entièrement dans le navigateur
La plupart des outils automatisent cela ; vous construisez rarement un PEM à la main. Mais comprendre la structure est utile lors du débogage d’une erreur d’analyse ou lors de la vérification manuelle d’un certificat. Un certificat PEM ressemble à du texte, mais le contenu est constitué de données binaires. La lecture des étiquettes de début et de fin ne vous indique pas ce que contient le certificat ; vous devez décoder le base64 et analyser l'ASN.1 pour voir le nom du sujet, la clé publique, l'émetteur et l'expiration.
L'outil d'encodage et de décodage Base64 peut décoder le corps afin que vous puissiez inspecter les premiers octets. Pour une analyse complète, vous avez besoin d'un analyseur ASN.1 (la plupart des langages de programmation ont des bibliothèques pour cela). L’idée clé est que PEM est un format conteneur : il contient toutes les données codées en DER, pas seulement les certificats. L'étiquette vous indique l'utilisation prévue, mais l'analyseur doit gérer correctement le type de données.