Vous avez sans doute déjà lu des articles sur la faille de l'AC eMudhra (sinon, vous avez des liens à la fin). Une des conséquences de cette faille est que tout le monde peut générer des vrais/faux certificats. Exemple.

La faille (depuis éclipsée par deux grosses failles PHP) venait d'un générateur de nombres aléatoire trop faibles. Un certificat est une clé cryptographique publique signée par une AC. La clé privée correspondant à cette clé publique doit être choisie de manière à être imprévisible pour l'attaquant. (On dit souvent qu'elle doit être choisie aléatoirement ce qui, en pratique, est juste un peu plus fort que de dire « imprévisible ».) Mais un générateur imprévisible est difficile à faire sur une machine déterministe comme un ordinateur. Et les logiciels ont des bogues. Une bogue frappait apparemment l'AC eMudhra : les clés générées ne faisaient qu'un octet (le reste étant toujours nul), ce qui ne faisait que 256 clés possibles, rendant triviale une énumération de toutes les clés possibles. L'une d'elles était juste le chiffre 4, que vous trouverez souvent dans les articles sur cette faille.

Le fonctionnement du système X.509 étant ce qu'il est, si on peut générer les clés d'une AC qui est largement présente dans les magasins d'AC de plusieurs systèmes d'exploitation / logiciels / langages, on peut se faire passer pour n'importe qui.

Démonstration avec le service emudhra.insecureoldshit.com:443. Il n'a pas de lien avec l'AC eMudhra mais, comme n'importe qui peut générer les clés « privées » d'eMudhra, il peut se faire passer pour elle. Ne cherchez pas forcément à vous connecter en HTTPS, c'est déjà intéressant avec juste du TLS nu. Essayons avec GnuTLS : % gnutls-cli emudhra.insecureoldshit.com:443 Processed 152 CA certificate(s). Resolving 'emudhra.insecureoldshit.com:443'... Connecting to '2.29.115.248:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `CN=192.134.4.66:6621,OU=You,O=Penguin Association,C=AQ', issuer `CN=EM OV TLS CA - G3C,O=eMudhra Inc,C=US', serial 0x00, EC/ECDSA key 256 bits, signed using ECDSA-SHA384, activated `2026-10-22 12:35:47 UTC', expires `2026-10-22 12:36:17 UTC', pin-sha256="Ma4OU2jrnyfraVMqehw9AlMFRBOGdaRziAjvPGDwKKc=" Public Key ID: sha1:779bc70e16304e65523397a5e1ccdc14cb673c39 sha256:31ae0e5368eb9f27eb69532a7a1c3d02530544138675a4738808ef3c60f028a7 Public Key PIN: pin-sha256:Ma4OU2jrnyfraVMqehw9AlMFRBOGdaRziAjvPGDwKKc= - Certificate[1] info: - subject `CN=EM OV TLS CA - G3C,O=eMudhra Inc,C=US', issuer `CN=emSign Root TLS CA - G3,O=eMudhra Technologies Limited,C=IN', serial 0x296926c227a3a1526392b19482a504, EC/ECDSA key 384 bits, signed using ECDSA-SHA384, activated `2025-04-30 15:37:41 UTC', expires `2040-04-28 18:30:00 UTC', pin-sha256="Y+zv7kMdSVI7wRNsTnLQIGpHcIbK9gbNXPAlaGwQnPg=" - Certificate[2] info: - subject `CN=emSign Root TLS CA - G3,O=eMudhra Technologies Limited,C=IN', issuer `CN=emSign ECC Root CA - G3,O=eMudhra Technologies Limited,OU=emSign PKI,C=IN', serial 0x00961a3efb1359576ed04005b4684a5b, EC/ECDSA key 384 bits, signed using ECDSA-SHA384, activated `2024-07-11 15:43:36 UTC', expires `2039-07-09 18:30:00 UTC', pin-sha256="xhnkeA7Y4KvtokrXMlZ95Dg6fqlBM49tGn0bSax5L+k=" - Status: The certificate is trusted. - Description: (TLS1.3-X.509)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-128-GCM) - Session ID: 8A:5F:E1:E3:6A:6D:00:01:5E:09:1E:78:5B:79:A8:BB:09:31:29:7F:9F:6B:C4:F3:6E:E0:72:F4:8E:45:7C:D2 - Options: - Handshake was completed Notons plusieurs choses : Le certificat du client (celui de numéro 0) a comme titulaire (« subject ») CN=192.134.4.66:6621,OU=You,O=Penguin Association,C=AQ. À la syntaxe du (qui normalise la forme texte du modèle de données de X.500), cela veut dire que le nom est 192.134.4.66 (l'adresse IP du client du service, ici moi), l'organisation est la fictive « Penguin Association » et le pays est l'Antarctique. (Rappelez-vous que c'est un vrai/faux certificat, généré lors de ma connexion.) Le certificat final est signé par l'AC eMudhra (CN=EM OV TLS CA - G3C,O=eMudhra Inc,C=US)… En fait, c'est une vraie/fausse signature, faite en récupérant une des clés privées de eMudhra, grâce à l'énumération des clés possibles. Le certificat a été accepté sur cette machine (une Debian, où le certificat d'eMudhra était dans le magasin du système) : « The certificate is trusted. ». Si maintenant je mets à jour mon système (les certificats des AC sont dans le paquetage Debian ca-certificates) : % gnutls-cli emudhra.insecureoldshit.com:443 Processed 150 CA certificate(s). Resolving 'emudhra.insecureoldshit.com:443'... Connecting to '2.29.115.248:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `CN=192.134.4.66:8801,OU=You,O=Penguin Association,C=AQ', issuer `CN=EM OV TLS CA - G3C,O=eMudhra Inc,C=US', serial 0x00, EC/ECDSA key 256 bits, signed using ECDSA-SHA384, activated `2026-10-22 12:37:50 UTC', expires `2026-10-22 12:38:20 UTC', pin-sha256="Ma4OU2jrnyfraVMqehw9AlMFRBOGdaRziAjvPGDwKKc=" Public Key ID: sha1:779bc70e16304e65523397a5e1ccdc14cb673c39 sha256:31ae0e5368eb9f27eb69532a7a1c3d02530544138675a4738808ef3c60f028a7 Public Key PIN: pin-sha256:Ma4OU2jrnyfraVMqehw9AlMFRBOGdaRziAjvPGDwKKc= - Certificate[1] info: - subject `CN=EM OV TLS CA - G3C,O=eMudhra Inc,C=US', issuer `CN=emSign Root TLS CA - G3,O=eMudhra Technologies Limited,C=IN', serial 0x296926c227a3a1526392b19482a504, EC/ECDSA key 384 bits, signed using ECDSA-SHA384, activated `2025-04-30 15:37:41 UTC', expires `2040-04-28 18:30:00 UTC', pin-sha256="Y+zv7kMdSVI7wRNsTnLQIGpHcIbK9gbNXPAlaGwQnPg=" - Certificate[2] info: - subject `CN=emSign Root TLS CA - G3,O=eMudhra Technologies Limited,C=IN', issuer `CN=emSign ECC Root CA - G3,O=eMudhra Technologies Limited,OU=emSign PKI,C=IN', serial 0x00961a3efb1359576ed04005b4684a5b, EC/ECDSA key 384 bits, signed using ECDSA-SHA384, activated `2024-07-11 15:43:36 UTC', expires `2039-07-09 18:30:00 UTC', pin-sha256="xhnkeA7Y4KvtokrXMlZ95Dg6fqlBM49tGn0bSax5L+k=" - Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. Vous noterez : Deux certificats de moins. Cette fois, le vrai/faux certificat est refusé, car le certificat d'eMudhra n'est plus dans le magasin.

Le certificat généré est disponible ici et voici son analyse par OpenSSL. Notez les dates de validité : % openssl x509 -text -in ../files/emudhra-false-cert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: ecdsa-with-SHA384 Issuer: C=US, O=eMudhra Inc, CN=EM OV TLS CA - G3C Validity Not Before: Oct 22 13:21:32 2026 GMT Not After : Oct 22 13:22:02 2026 GMT Subject: C=AQ, O=Penguin Association, OU=You, CN=192.134.4.66:63823 Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:95:61:11:86:61:1c:97:dd:0f:b5:e3:75:9b:07: … ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Authority Key Identifier: 34:EA:EA:0C:EB:C9:0A:DA:F9:D0:C5:E2:ED:9B:78:C9:87:9E:1B:6C X509v3 Subject Alternative Name: DNS:eXample.com, DNS:emudhra.insecureoldshit.com, DNS:*.emudhra.insecureoldshit.com, IP Address:192.134.4.66 Signature Algorithm: ecdsa-with-SHA384 Signature Value: 30:66:02:31:00:bd:8a:fa:91:fc:cd:c0:af:9f:85:0b:13:16: … -----BEGIN CERTIFICATE----- MIICIzCCAaigAwIBAgIBADAKBggqhkjOPQQDAzBAMQswCQYDVQQGEwJVUzEUMBIG …

Si vous tenez à faire du HTTP avec ce service, allez-y, il y a un gag.

D'autres ont utilisé cette possibilité pour permettre de générer de vrais/faux certificats, par exemple mitmproxy avec ce code.

Quelques lectures, si vous voulez apprendre ou approfondir : En français, un bon article de Next. Et en anglais, le bon article d'Ars Technica. L'article original (en anglais), qui n'indiquait pas encore la raison (la défaillance du générateur de nombres aléatoires). L'article technique de Scott Helme. Le rapport de bogue chez Mozilla (très détaillé, en anglais). Le communiqué officiel de l'AC.

Plusieurs mathématiciens en ont profité pour faire remarquer que, contrairement à une simplification courante, 4 n'est pas « moins aléatoire » que, par exemple, 1012818637039180068205. Les deux ont la même probabilité d'être sélectionnés. Le problème vient du fait que les clés ne faisaient qu'un octet, pas spécialement du fait qu'elle avait la valeur 4.