Décodeur de certificat et de CSR

Un certificat ou une CSR ne s'écrit jamais comme du code source. Le contenu réel est du DER (Distinguished Encoding Rules), un encodage binaire compact de type TLV (tag-longueur-valeur) défini par l'ASN.1 : chaque champ est une séquence d'octets typée et préfixée par sa longueur, imbriquée dans des séquences plus larges. Le PEM (RFC 7468) n'est que ce même DER, encodé en base64 et entouré de lignes `-----BEGIN ...-----` et `-----END ...-----` pour survivre à un copier-coller dans un email, un fichier de configuration ou un terminal.

L'étiquette entre les balises BEGIN/END indique au décodeur ce qu'il contient avant même de lire le premier octet : `CERTIFICATE` enveloppe un certificat X.509 encodé en DER, `CERTIFICATE REQUEST` (ou l'ancien `NEW CERTIFICATE REQUEST`) enveloppe une `CertificationRequest` PKCS#10, et `PRIVATE KEY` / `RSA PRIVATE KEY` enveloppent du matériel de clé qu'un décodeur de certificat n'a jamais à traiter et ne devrait jamais accepter comme entrée.

Le DER étant strictement TLV, un décodeur peut le parcourir sans deviner : lire un tag, lire sa longueur, lire exactement ce nombre d'octets de contenu, puis passer au frère suivant. Une entrée malformée - une longueur qui annonce plus d'octets qu'il n'en reste, ou un niveau d'imbrication plus profond que n'importe quel certificat réel - est un défaut structurel qu'un décodeur peut rejeter directement, sans tenter de l'interpréter.

• PEM = base64(DER) + balises BEGIN/END nommant le type de contenu - l'encodage est cosmétique, pas cryptographique
• Un certificat et une CSR sont des objets structurellement différents : un certificat est émis et signé par une autorité de certification, une CSR n'est pas signée par une AC et n'est auto-signée que pour prouver la possession de la clé
• Plusieurs blocs PEM peuvent apparaître dans un même fichier (un certificat feuille suivi d'intermédiaires) - un décodeur qui ne lit que le premier bloc ignore silencieusement le reste
• En pratique, le DER des certificats et des CSR n'utilise que la forme à longueur définie ; la forme à longueur indéfinie existe dans le BER mais n'est jamais produite par les AC ni par les outils de génération de CSR

Une CSR (Certificate Signing Request, PKCS#10, RFC 2986) est ce qu'un demandeur génère et envoie à une autorité de certification : un nom de sujet, une clé publique, et une auto-signature portant sur les deux - la preuve que le demandeur détient la clé privée, rien de plus. Une CSR ne porte aucune date de validité, aucun émetteur, aucun numéro de série attribué par une AC, puisque rien de tout cela n'existe encore. Les extensions que le demandeur souhaite voir figurer sur le futur certificat (le plus souvent des Subject Alternative Names) voyagent dans la CSR sous forme d'attribut `extensionRequest` (OID 1.2.840.113549.1.9.14) - une demande, pas une garantie ; c'est l'AC émettrice qui décide de ce qui figure réellement dans le certificat final.

Un certificat (X.509v3, RFC 5280) est ce que l'AC renvoie : le même sujet et la même clé publique, désormais liés par la signature propre de l'AC, plus des champs que seule une AC peut ajouter - un nom d'émetteur, un numéro de série propre à cette AC, une fenêtre de validité (notBefore/notAfter), et les extensions que l'AC a effectivement approuvées et signées. L'auto-signature de la CSR et la signature émise par l'AC sur le certificat répondent à deux questions différentes : "le demandeur détient-il cette clé privée" contre "une AC a-t-elle validé ce couple sujet/clé".

C'est pourquoi un décodeur ne peut pas traiter les deux comme de simples variantes d'un même format. Une CSR n'a pas d'émetteur à afficher ni d'expiration à vérifier ; un certificat n'a pas de signature à "vérifier" contre sa propre clé, puisqu'il n'a jamais été auto-signé au départ (à l'exception des certificats d'AC racine, qui constituent un cas particulier).

Le sujet et l'émetteur sont tous deux des Distinguished Names au sens X.501 - une séquence ordonnée de relative distinguished names (RDN), chacun étant une paire type d'attribut/valeur telle que `CN` (Common Name), `O` (Organization), `OU` (Organizational Unit) ou `C` (Country). Le sujet identifie à qui le certificat est délivré ; l'émetteur identifie l'AC qui l'a signé. Pour une racine auto-signée, sujet et émetteur sont identiques.

validFrom et validTo marquent la fenêtre de validité du certificat (les champs notBefore/notAfter de la RFC 5280) - en dehors de cette fenêtre, le certificat est invalide quel que soit le reste de son contenu, sans aucune tolérance sur les bords. Le numéro de série est un entier attribué par l'AC émettrice, unique dans l'espace de noms de cette AC ; c'est ce que référence une vérification de révocation (CRL ou OCSP), pas un hachage du contenu du certificat.

L'empreinte SHA-256 est un hachage de l'intégralité du certificat encodé en DER - changer un seul bit n'importe où (une copie re-signée, un numéro de série différent, un téléchargement corrompu) modifie entièrement l'empreinte. C'est ainsi qu'on confirme que deux fichiers sont, octet pour octet, le même certificat sans comparer les octets bruts. Le Subject Alternative Name (SAN) est l'extension (OID 2.5.29.17) que les clients modernes comparent réellement à un nom d'hôte - noms DNS, adresses IP, adresses email et URI peuvent tous y figurer, et un certificat peut en lister plusieurs de chaque type.

La section clé publique indique l'algorithme (RSA ou EC) et la taille - longueur du module en bits pour RSA, force de la courbe nommée pour EC (P-256 fait 256 bits, P-384 fait 384 bits). Le Key Usage restreint ce que la clé est cryptographiquement autorisée à faire (digitalSignature, keyEncipherment, keyCertSign, etc.) ; l'indicateur CA des basic constraints indique si le certificat est lui-même autorisé à signer d'autres certificats. L'Authority Information Access porte l'URL du répondeur OCSP (pour le statut de révocation en direct) et l'URL CA Issuers (pour récupérer le certificat de l'AC émettrice, utile quand une chaîne est incomplète).

Une CSR décodée montre la même décomposition du nom de sujet qu'un certificat (CN, O, OU, C, etc., extraits de la même structure RDN) et le même rapport d'algorithme/taille de clé publique - mais s'arrête là pour tout ce qui relève de l'AC. Il n'y a ni émetteur, ni fenêtre de validité, ni numéro de série attribué par une AC, puisqu'une CSR est une demande, pas un titre.

Les Subject Alternative Names demandés proviennent de l'attribut `extensionRequest` de la CSR, et non d'une extension signée - une AC peut les honorer, en ajouter d'autres, ou les abandonner entièrement au moment d'émettre le certificat. Il faut traiter la liste SAN d'une CSR comme "ce qui a été demandé", jamais comme "ce que contiendra le certificat final".

La validité de la signature sur une CSR ne signifie qu'une chose précise et limitée : l'auto-signature portant sur le `CertificationRequestInfo` de la CSR (sujet + clé publique + attributs) se vérifie correctement contre la clé publique intégrée à cette même CSR. Cela confirme que le demandeur qui a généré la CSR détient bien la clé privée correspondante. Cela ne dit rien sur la légitimité du nom de sujet, sur le fait que le demandeur possède réellement les domaines listés, ni sur l'accord d'une AC pour émettre quoi que ce soit - ces vérifications se font entièrement du côté de l'AC, après soumission.

Le décodage se limite entièrement aux octets collés - aucun nom d'hôte à résoudre, aucun port auquel se connecter, aucun serveur en direct impliqué à quelque étape que ce soit. C'est l'outil adapté pour une CSR avant même son envoi, pour un certificat récupéré d'un fichier de configuration ou reçu par email, ou pour une chaîne en cours d'assemblage pour un serveur - autant de cas où aucun point de terminaison actif n'existe encore pour comparer quoi que ce soit.

Cela répond à une question différente de la vérification d'un certificat tel que servi par un hôte en direct via TLS : le décodage indique ce qu'un fichier précis contient ; une vérification en direct indique en plus ce qu'un serveur présente réellement sur le réseau à l'instant, si la chaîne qu'il envoie est complète, et comment se comporte la session TLS négociée - rien de tout cela n'existe indépendamment d'une connexion active.