La plupart des applications traitent un certificat comme un fichier opaque à remettre à OpenSSL. Tôt ou tard, l’une d’elles pose une question à laquelle l’extension ne répond pas, et vous vous retrouvez à l’intérieur d’ASN.1.
Trois couches, souvent confondues
- ASN.1 décrit la structure : ceci est une séquence, qui contient un entier, puis un ensemble de noms.
- DER est une façon d’écrire cette structure en octets, et il est distingué : exactement un encodage valable par valeur. Cette unicité est ce qui donne un sens à une signature portant dessus.
- PEM est du DER en base64 entre deux lignes de bannière, pour qu’il survive à un copier-coller.
Quand quelqu’un dit qu’un certificat est « en PEM », il décrit l’enveloppe, pas le contenu.
Pourquoi le caractère distingué compte
Un certificat est signé sur ses octets DER. Deux encodages de la même valeur logique produiraient deux signatures différentes, donc DER interdit le choix : longueurs sous leur forme la plus courte, membres d’ensemble dans un ordre défini, pas de zéros de tête.
La conséquence pour qui analyse : gardez les octets d’origine. Décodez pour lire, vérifiez contre ce que vous avez reçu. Réencoder une structure et vérifier contre le résultat est un bogue qui n’apparaît qu’avec certaines entrées, ce qui est le pire genre. Le même piège existe en CBOR, pour la même raison.
À quoi cela vous sert vraiment
- Lire correctement un Subject Alternative Name, avec ses différentes formes.
- Parcourir une chaîne et contrôler les contraintes de base plutôt que de faire confiance à l’ordre qu’on vous a donné.
- Vérifier une attestation WebAuthn, où le certificat porte des extensions propres à l’authentificateur.
- Produire une demande de signature de certificat sans passer par un binaire.
pki-framework traite ASN.1, X.509, PKCS#10 et les structures alentour en PHP, sans que l’extension OpenSSL ne s’interpose entre vous et les octets. C’est la plus récemment mise à jour des petites bibliothèques présentées ici.