En bref. Un client TLS n’identifie un serveur que par le Subject Alternative Name : les entrées dNSName et iPAddress, jamais le nom commun (Common Name) du sujet. L’extension Key Usage indique ce que la clé peut faire mathématiquement (signer, chiffrer, signer des certificats), l’extension Extended Key Usage, pour quelle application (serverAuth, clientAuth, signature de code). C’est Basic Constraints CA:TRUE qui autorise un certificat à en émettre d’autres ; un certificat feuille porte CA:FALSE. Les extensions Authority Key Identifier et Subject Key Identifier sont des indices qui aident un client à trouver l’émetteur, pas des contrôles de sécurité. Les extensions CRL Distribution Points et Authority Information Access indiquent à un client où vérifier la révocation et où récupérer un certificat intermédiaire manquant ; les certificats Let’s Encrypt ne portent plus d’URL OCSP. Les SCT prouvent que le certificat a été journalisé dans Certificate Transparency, ce qu’exigent Chrome et Safari.
Obtenir un vrai certificat à examiner
openssl s_client -showcerts affiche chaque certificat que le serveur envoie ; openssl x509 -text en décode un. Les tests ont été effectués dans debian:forky-20261005-slim avec OpenSSL 3.6.5 et pyca/cryptography 49.0.0 :
openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org -showcerts </dev/null 2>/dev/null \
| awk '/-----BEGIN CERTIFICATE-----/{n++; f=sprintf("letsencrypt.org-%d.pem", n); p=1} p{print >> f} /-----END CERTIFICATE-----/{p=0; close(f)}'
openssl x509 -in letsencrypt.org-1.pem -noout -text
-servername envoie le SNI, sans lequel de nombreux serveurs renvoient un certificat par défaut établi pour un autre nom. Voici le certificat feuille de letsencrypt.org tel qu’il était servi ce jour-là (la clé publique est affichée en entier ; les deux signatures des SCT sont abrégées) :
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
05:43:93:3b:e3:86:b3:a2:b3:ad:d5:34:f2:10:3b:c8:b6:5f
Signature Algorithm: ecdsa-with-SHA384
Issuer: C=US, O=Let's Encrypt, CN=YE2
Validity
Not Before: Sep 4 14:34:32 2026 GMT
Not After : Dec 3 14:34:31 2026 GMT
Subject: CN=letsencrypt.org
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:e9:e5:40:7b:43:1e:46:b9:8e:45:e4:aa:cb:40:
ab:e6:3f:99:27:b8:b7:81:e3:32:56:e7:14:74:5f:
fa:43:5b:52:c6:a6:b5:66:c5:56:0e:07:21:56:e3:
4c:fe:35:55:4f:f0:92:2f:eb:22:4a:f1:7a:39:51:
39:04:c2:b3:0d
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
16:68:8D:1E:2A:32:48:8C:B5:F1:10:0A:16:08:37:08:3B:9D:30:23
X509v3 Authority Key Identifier:
B9:59:F2:8E:CF:22:F0:86:D3:37:48:FF:76:14:18:BA:82:D8:55:87
Authority Information Access:
CA Issuers - URI:http://ye2.i.lencr.org/
X509v3 Subject Alternative Name:
DNS:cp.letsencrypt.org, DNS:cp.root-x1.letsencrypt.org, DNS:cps.letsencrypt.org, DNS:cps.root-x1.letsencrypt.org, DNS:lencr.org, DNS:letsencrypt.com, DNS:letsencrypt.org, DNS:www.lencr.org, DNS:www.letsencrypt.com, DNS:www.letsencrypt.org
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://ye2.c.lencr.org/96.crl
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : D8:09:55:3B:94:4F:7A:FF:C8:16:19:6F:94:4F:85:AB:
B0:F8:FC:5E:87:55:26:0F:15:D1:2E:72:BB:45:4B:14
Timestamp : Sep 4 15:33:02.377 2026 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:D0:2E:25:A4:9D:7F:C8:18:D6:7B:5E:...
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 46:AF:86:3D:3B:3E:E5:9F:A5:77:DE:A8:24:5D:36:B0:
D9:ED:22:A2:23:F4:61:77:41:22:94:52:EE:95:50:5F
Timestamp : Sep 4 15:33:02.552 2026 GMT
Extensions: 00:00:05:00:24:DF:DB:0C
Signature : ecdsa-with-SHA256
30:44:02:20:31:2F:83:D6:42:65:26:0D:58:D7:DD:C3:...
Signature Algorithm: ecdsa-with-SHA384
Signature Value:
30:65:02:31:00:ee:1d:b0:7c:35:88:98:15:57:b8:88:73:23:
92:a9:bf:40:bf:e8:ae:02:48:e6:f4:7a:2d:18:fc:43:52:d3:
80:9a:ff:ce:e0:2a:0d:4a:29:e6:80:a2:94:f5:4f:14:d9:02:
30:35:08:99:3b:bc:89:5b:23:a0:ef:64:24:e2:b2:b3:b8:c2:
d8:d5:95:45:de:f3:03:e8:e7:82:78:a5:9e:c2:1f:ad:eb:14:
fc:39:51:c7:e1:18:e9:16:b4:a5:48:de:09
La suite de cette page le parcourt de haut en bas. La structure elle-même est définie dans la RFC 5280 (§4.1 pour les champs, §4.2 pour les extensions) ; ce qu’un certificat TLS de confiance publique peut contenir figure dans les Baseline Requirements (BR) du CA/Browser Forum, version 2.3.1 du 4 octobre 2026, §7.1.
Version, numéro de série, algorithme de signature, validité
- Version 3 est la seule version qui comporte des extensions ; les BR l’exigent.
- Numéro de série. Unique pour un émetteur donné et, pour les AC publiques, « un nombre non séquentiel supérieur à zéro (0) et inférieur à 2¹⁵⁹, contenant au moins 64 bits de sortie d’un CSPRNG » (BR §7.1.2.7). L’aléa sert ici de défense contre les attaques par collision à préfixe choisi visant le hachage de la signature ; c’est pourquoi les numéros de série ressemblent à du bruit. C’est le numéro de série que répertorient les CRL.
- L’algorithme de signature apparaît deux fois, dans la partie signée et à côté de la signature, et les deux valeurs doivent être identiques à l’octet près. Ici,
ecdsa-with-SHA384renseigne sur la clé de l’émetteur (YE2 est une clé P-384), pas sur celle du sujet. La valeur de signature, à la fin, est une signature ECDSA en DER, le format expliqué dans Formats de signature ECDSA. - Validité.
notBeforeetnotAftersont des bornes incluses. Ce certificat a une durée de vie de 90 jours ; le maximum fixé par les BR est de 200 jours pour les certificats émis depuis le 15 mars 2026, de 100 jours à partir du 15 mars 2027 et de 47 jours à partir du 15 mars 2029 (BR §6.3.2). Let’s Encrypt émet déjà des certificats de 45 jours avec son profil optionneltlsserveret prévoit de passer sa durée par défaut à 64 jours le 10 février 2027, puis à 45 jours le 16 février 2028.
Sujet et Subject Alternative Name
Le sujet est un nom distinctif : ici, uniquement CN=letsencrypt.org. Les certificats à validation de domaine ne contiennent rien d’autre, car l’AC n’a rien validé d’autre. Les noms que vérifie un client se trouvent dans le Subject Alternative Name (SAN) : dix entrées DNS: pour ce certificat.
Le nom commun ne compte plus depuis longtemps. La RFC 9525 (2023), qui a remplacé la RFC 6125, dispose que « le RDN Common Name ne doit pas (MUST NOT) être utilisé pour identifier un service ». Chrome a cessé d’en tenir compte à partir de la version 58 (2017), et Go refuse les certificats qui n’ont qu’un CN avec x509: certificate relies on legacy Common Name field. Les BR ne conservent le CN que comme copie : s’il est présent, il « doit (MUST) contenir exactement une entrée correspondant à l’une des valeurs de l’extension subjectAltName du certificat » (§7.1.4.3).
Un SAN peut aussi contenir des adresses IP. Voici le certificat du résolveur de Cloudflare :
subject=C=US, ST=California, L=San Francisco, O=Cloudflare, Inc., CN=cloudflare-dns.com
X509v3 Subject Alternative Name:
DNS:cloudflare-dns.com, DNS:*.cloudflare-dns.com, IP Address:1.0.0.1, IP Address:1.1.1.1, IP Address:162.159.36.1, IP Address:162.159.46.1, IP Address:2606:4700:4700:0:0:0:0:1001, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:64, IP Address:2606:4700:4700:0:0:0:0:6400, DNS:one.one.one.one
https://1.1.1.1 fonctionne parce que 1.1.1.1 est une entrée iPAddress ; une entrée DNS:1.1.1.1 ne correspondrait pas à une adresse IP, et c’est précisément l’objet de l’erreur Go cannot validate certificate for … because it doesn't contain any IP SANs. Le sujet comporte ici aussi l’organisation et la localité, et le certificat déclare la politique OV 2.23.140.1.2.2 (voir DV vs OV vs EV) ; le navigateur n’en affiche rien. Il a été émis le 31 décembre 2025 pour 355 jours, avant l’entrée en vigueur de la limite de 200 jours.
Un wildcard tel que *.cloudflare-dns.com couvre exactement un label : a.cloudflare-dns.com, mais ni cloudflare-dns.com lui-même ni a.b.cloudflare-dns.com (RFC 9525 §6.3). OpenSSL vérifie les noms de la même façon :
Hostname www.lencr.org does match certificate
Hostname lencr.org.evil.test does NOT match certificate
Hostname mail.letsencrypt.org does NOT match certificate
Clé publique du sujet (SPKI)
Le champ subjectPublicKeyInfo (SPKI) contient l’algorithme et la clé : un point non compressé de la courbe P-256 (04 suivi de x et y sur 32 octets chacun). C’est la seule partie du certificat à laquelle se rapporte la clé privée du sujet, et c’est pourquoi l’épinglage de clé publique hache le SPKI plutôt que le certificat entier : un renouvellement avec la même clé ne casse pas l’épinglage (voir l’épinglage de certificats en 2026).
Key Usage et Extended Key Usage
Deux questions différentes :
- Key Usage (RFC 5280 §4.2.1.3) restreint les opérations cryptographiques de la clé :
digitalSignature,keyEncipherment,keyAgreement,keyCertSign,cRLSignet quelques bits plus rares. Pour un certificat feuille ECDSA, les BR exigentdigitalSignatureet interdisentkeyEncipherment(une clé EC ne peut pas chiffrer). Un certificat feuille RSA peut ajouterkeyEnciphermentpour l’ancien échange de clés RSA de TLS 1.2, ce que les BR décrivent comme la prise en charge de « suites de chiffrement non sécurisées ». Les BR indiquent aussi que l’extension devrait (SHOULD) être présente et marquée critique, comme ici. - Extended Key Usage (§4.2.1.12) désigne des applications :
serverAuth(1.3.6.1.5.5.7.3.1),clientAuth(…3.2),codeSigning(…3.3),emailProtection(…3.4),timeStamping(…3.8). Un certificat de serveur TLS doit (MUST) contenirserverAuthet ne doit pas (MUST NOT) contenir les usages signature de code, protection des e-mails, horodatage, signature OCSP nianyExtendedKeyUsage(BR §7.1.2.7.10).
C’est clientAuth qui a changé. Les BR l’autorisent toujours (MAY), mais la politique du Chrome Root Program, version 1.8, exige des hiérarchies « dédiées à l’authentification de serveur TLS » : les AC subordonnées déclarées à partir du 15 juin 2026 ne peuvent indiquer que serverAuth, et les certificats d’abonné émis à partir du 15 mars 2027 doivent s’y limiter aussi. Let’s Encrypt a retiré clientAuth de son profil par défaut le 11 février 2026 et a complètement cessé de l’émettre le 8 juillet 2026 ; le certificat feuille de letsencrypt.org ci-dessus ne porte que serverAuth. Si votre service authentifiait des clients avec des certificats TLS publics, il lui faut une AC privée (voir le mTLS expliqué).
L’EKU est appliquée par les vérificateurs. Avec une AC jetable, un certificat dont l’EKU se limite à clientAuth :
CN=worker-7
error 26 at 0 depth lookup: unsuitable certificate purpose
error worker-7.pem: verification failed
worker-7.pem: OK
C’est l’erreur 26 d’OpenSSL ; Go signale la même situation par x509: certificate specifies an incompatible key usage.
Basic Constraints : qui peut émettre des certificats
L’extension Basic Constraints porte un booléen et un nombre. CA:TRUE autorise la clé du certificat à signer d’autres certificats ; pathlen limite le nombre d’AC intermédiaires qui peuvent suivre sous ce certificat. La RFC 5280 §4.2.1.9 est explicite : sans cA positionné, « la clé publique certifiée ne doit pas (MUST NOT) être utilisée pour vérifier des signatures de certificats ». En remontant la chaîne de letsencrypt.org :
| Certificat | Basic Constraints | Key Usage |
|---|---|---|
CN=letsencrypt.org | critique, CA:FALSE | Signature numérique |
CN=YE2 (intermédiaire) | critique, CA:TRUE, pathlen:0 | Signature numérique, signature de certificats, signature de CRL |
CN=Root YE (avec signature croisée d’ISRG Root X2) | critique, CA:TRUE | Signature de certificats, signature de CRL |
pathlen:0 sur YE2 signifie qu’elle ne peut émettre que des certificats feuilles. Pour observer l’application de la règle, le test a utilisé la clé d’un certificat de serveur ordinaire (CA:FALSE, Key Usage digitalSignature) pour signer un autre certificat :
CN=api.example.test
error 79 at 1 depth lookup: invalid CA certificate
CN=api.example.test
error 32 at 1 depth lookup: key usage does not include certificate signing
error forged.example.test.pem: verification failed
Les deux règles se déclenchent : l’erreur 79 pour l’absence de CA:TRUE et l’erreur 32 pour l’absence de keyCertSign. C’est faute de ce contrôle qu’Internet Explorer acceptait en 2002 n’importe quel certificat feuille comme AC. Python 3.13 et versions ultérieures activent en outre le mode strict d’OpenSSL, qui rejette aussi les certificats d’AC dont l’extension Basic Constraints n’est pas marquée critique.
Identifiants de clé de l’autorité et du sujet
Le Subject Key Identifier désigne la clé propre du certificat ; l’Authority Key Identifier, la clé qui l’a signé. Chaque AKI est égal au SKI du certificat situé juste au-dessus :
subject=CN=letsencrypt.org
16:68:8D:1E:2A:32:48:8C:B5:F1:10:0A:16:08:37:08:3B:9D:30:23
B9:59:F2:8E:CF:22:F0:86:D3:37:48:FF:76:14:18:BA:82:D8:55:87
subject=C=US, O=Let's Encrypt, CN=YE2
B9:59:F2:8E:CF:22:F0:86:D3:37:48:FF:76:14:18:BA:82:D8:55:87
A3:C8:26:5A:8E:A1:4C:D0:35:63:FC:9B:23:C8:3A:AE:56:F3:4F:56
subject=C=US, O=ISRG, CN=Root YE
A3:C8:26:5A:8E:A1:4C:D0:35:63:FC:9B:23:C8:3A:AE:56:F3:4F:56
7C:42:96:AE:DE:4B:48:3B:FA:92:F8:9E:8C:CF:6D:8B:A9:72:37:95
subject=C=US, O=Internet Security Research Group, CN=ISRG Root X2
7C:42:96:AE:DE:4B:48:3B:FA:92:F8:9E:8C:CF:6D:8B:A9:72:37:95
79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E
Les identifiants de clé aident un vérificateur à choisir le bon émetteur lorsque plusieurs certificats d’AC portent le même nom (AC à clé renouvelée ou à signature croisée, comme les deux certificats ISRG Root X2 qui existent). Ils ne prouvent rien : c’est la vérification de la signature qui fait foi. La RFC 5280 exige l’AKI dans tout certificat, sauf les racines auto-signées, et le SKI dans tout certificat d’AC ; elle suggère un condensat SHA-1 de la clé comme une façon de calculer le SKI, mais les émetteurs peuvent utiliser n’importe quelle valeur unique. Les BR qualifient le SKI des certificats feuilles de « non recommandé » (NOT RECOMMENDED) ; Let’s Encrypt comme Sectigo en incluent pourtant toujours un. Les vérificateurs stricts échouent sur un certificat d’AC sans AKI, comme le montre l’erreur Python Missing Authority Key Identifier.
La chaîne montre aussi que le chemin que vous validez n’est pas toujours celui qu’envoie le serveur. letsencrypt.org envoie quatre certificats, le dernier étant ISRG Root X2 avec signature croisée d’ISRG Root X1 ; OpenSSL, avec le magasin de confiance de Debian, s’arrête à la racine X2 à laquelle il fait déjà confiance :
letsencrypt.org-1.pem: OK
Chain:
depth=0: CN=letsencrypt.org (untrusted)
depth=1: C=US, O=Let's Encrypt, CN=YE2 (untrusted)
depth=2: C=US, O=ISRG, CN=Root YE (untrusted)
depth=3: C=US, O=Internet Security Research Group, CN=ISRG Root X2
CRL Distribution Points, AIA et OCSP
Deux extensions pointent vers des URL :
- CRL Distribution Points (RFC 5280 §4.2.1.13) : l’endroit où l’émetteur publie sa CRL. Les BR l’exigent, sauf si le certificat est de courte durée (7 jours ou moins depuis le 15 mars 2026) ou s’il porte une URL OCSP, et l’URL doit être en
httpsimple : la CRL est signée, TLS n’apporterait donc rien et créerait une boucle. - Authority Information Access (§4.2.2.1) :
CA Issuersindique où télécharger le certificat de l’AC émettrice, etOCSPdésigne le répondeur OCSP de l’émetteur.
Le certificat feuille de Let’s Encrypt comporte une URL de CRL et aucune URL OCSP : Let’s Encrypt a retiré les URL OCSP de ses certificats en mai 2025 et a arrêté ses répondeurs le 6 août 2025, après que les BR ont rendu OCSP facultatif. Sectigo exploite toujours OCSP ; le certificat feuille de github.com comporte les deux méthodes d’accès et deux politiques :
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.2.7
CPS: https://sectigo.com/CPS
Policy: 2.23.140.1.2.1
Authority Information Access:
CA Issuers - URI:http://crt.sectigo.com/SectigoPublicServerAuthenticationCADVE36.crt
OCSP - URI:http://ocsp.sectigo.com
La CRL associée au certificat feuille de letsencrypt.org, téléchargée et vérifiée avec le certificat de YE2 :
crl=$(openssl x509 -in letsencrypt.org-1.pem -noout -ext crlDistributionPoints | grep -o 'http://[^ ]*')
curl -sS -o leaf.crl "$crl"
openssl crl -inform DER -in leaf.crl -noout -issuer -lastupdate -nextupdate
openssl crl -inform DER -in leaf.crl -noout -text | grep -c 'Serial Number:'
openssl crl -inform DER -in leaf.crl -noout -CAfile letsencrypt.org-2.pem
issuer=C=US, O=Let's Encrypt, CN=YE2
lastUpdate=Oct 20 15:03:57 2026 GMT
nextUpdate=Oct 29 15:03:56 2026 GMT
1590
verify OK
Le 96.crl de l’URL est une partition (shard) : l’AC répartit ses révocations sur de nombreuses petites CRL et indique la bonne dans chaque certificat, si bien qu’un client télécharge 1590 entrées au lieu de toutes les révocations. Les navigateurs récupèrent rarement les CRL en direct ; Chrome et Firefox transmettent eux-mêmes les données de révocation aux clients. Les compromis sont détaillés dans CRL vs OCSP.
CA Issuers compte lorsqu’un serveur oublie d’envoyer son certificat intermédiaire. Les navigateurs et les vérificateurs des plateformes Windows et macOS le suivent (la « récupération AIA », ou AIA chasing) ; OpenSSL (et avec lui curl, Python et PHP sous Linux), Go sous Linux et Java avec les paramètres par défaut ne le font pas, si bien que le même serveur mal configuré fonctionne dans un navigateur et échoue dans le code avec « unable to get local issuer certificate ».
Politiques de certificat
Tout certificat TLS public déclare exactement un identifiant de politique du CA/Browser Forum, qui indique comment le sujet a été validé : 2.23.140.1.2.1 validation de domaine, 2.23.140.1.2.2 validation de l’organisation, 2.23.140.1.2.3 validation individuelle, 2.23.140.1.1 validation étendue (BR §7.1.6.1). Les AC ajoutent leurs propres OID de politique et un lien vers leur déclaration des pratiques de certification (CPS), comme Sectigo ci-dessus. Les clients qui affichent des niveaux de validation lisent cette extension, pas le sujet.
Signed Certificate Timestamps
Avant l’émission, l’AC soumet un précertificat (le même contenu, avec une extension poison) à des journaux Certificate Transparency, et chaque journal répond par une promesse signée de le publier, le SCT. L’AC intègre ces SCT dans le certificat final (OID 1.3.6.1.4.1.11129.2.4.2, RFC 6962 §3.3). L’identifiant du journal (log ID) est un condensat de la clé du journal ; la liste des journaux CT de Chrome lui associe un nom :
"""List the SCTs embedded in a certificate and name their logs from Chrome's CT log list."""
import base64
import json
import sys
from cryptography import x509
log_list = json.load(open(sys.argv[1]))
logs = {}
for operator in log_list["operators"]:
for log in operator["logs"] + operator.get("tiled_logs", []):
logs[base64.b64decode(log["log_id"])] = (operator["name"], log["description"])
cert = x509.load_pem_x509_certificate(open(sys.argv[2], "rb").read())
scts = cert.extensions.get_extension_for_class(x509.PrecertificateSignedCertificateTimestamps).value
for sct in scts:
operator, name = logs.get(sct.log_id, ("unknown operator", "unknown log"))
print(f"{sct.timestamp:%Y-%m-%d %H:%M:%S} UTC {operator}: {name} ({sct.entry_type.name})")
2026-09-04 15:33:02 UTC Google: Google Xenon2026h2 (PRE_CERTIFICATE)
2026-09-04 15:33:02 UTC Geomys: Geomys Tuscolo2026h2 (PRE_CERTIFICATE)
2026-09-01 00:10:32 UTC Google: Google Argon2026h2 (PRE_CERTIFICATE)
2026-09-01 00:10:31 UTC Sectigo: Sectigo Tiger2026h2 (PRE_CERTIFICATE)
La liste des journaux a été téléchargée le même jour depuis https://www.gstatic.com/ct/log_list/v3/log_list.json. Chaque certificat porte deux SCT issus de deux opérateurs différents, ce que la politique CT de Chrome demande pour un certificat valide 180 jours ou moins (trois au-delà). La ligne Extensions: 00:00:05:00:24:DF:DB:0C du SCT de Tuscolo correspond à l’extension leaf_index que doivent ajouter les journaux qui implémentent l’API static CT : type 0, longueur 5 et un index de 40 bits, ici l’entrée 618 650 380 de ce journal. C’est grâce aux SCT que chacun peut rechercher tous les certificats émis pour son domaine, et qu’un certificat émis à tort ne peut pas rester secret. Le décodeur de SCT les décode sans ligne de commande.
Erreurs fréquentes
- Un certificat dont le nom ne figure que dans le CN. Les navigateurs affichent NET::ERR_CERT_COMMON_NAME_INVALID, Java répond No subject alternative names present. Chaque nom, y compris celui du CN, doit figurer dans le SAN. Le problème survient le plus souvent avec les AC internes et les commandes
openssl reqen une ligne qui ne renseignent que-subj. - Certificat intermédiaire manquant. Fonctionne dans les navigateurs et avec les vérificateurs des plateformes Windows et macOS grâce à la récupération AIA, échoue dans les clients fondés sur OpenSSL, avec Go sous Linux et avec Java. Servez la chaîne complète (certificat feuille en premier, racine facultative).
- Compter sur
clientAuthdans un certificat public. Cet usage disparaît des hiérarchies TLS publiques ; les intégrations de partenaires qui exigeaient « n’importe quel certificat public avecclientAuth» ont besoin d’une AC privée. - Un certificat d’AC créé avec
CA:TRUEmais sanskeyCertSign, ou sans être marqué critique. Les vérificateurs stricts (Python 3.13+, Go pour certains champs) le rejettent ; chez Go, l’erreur est parent certificate cannot sign this kind of certificate. - Prendre le SKI pour une empreinte. Sa valeur est celle que l’AC a choisi d’y mettre. Pour identifier un certificat, hachez le DER entier (
openssl x509 -fingerprint -sha256) ; pour identifier une clé, hachez le SPKI. - Lire la validité en heure locale.
notBeforeetnotAftersont exprimés en UTC. Un serveur dont l’horloge retarde de quelques heures rejette un certificat tout juste émis comme pas encore valide.
Sources
- RFC 5280 : §4.1 (champs du certificat), §4.2.1.1–4.2.1.13 (AKI, SKI, Key Usage, SAN, Basic Constraints, EKU, CRL DP), §4.2.2.1 (AIA)
- RFC 9525 : identité de service dans TLS (§2, §6.3)
- RFC 6962 : Certificate Transparency (§3.3) et l’API static CT
- Baseline Requirements du CA/Browser Forum 2.3.1 (4 octobre 2026) : §6.3.2, §7.1.2.7, §7.1.2.10, §7.1.2.11, §7.1.4.3, §7.1.6.1
- Politique du Chrome Root Program 1.8 et politique CT de Chrome
- Let’s Encrypt : Fin de la prise en charge d’OCSP en 2025, Fin de la prise en charge des certificats d’authentification client TLS en 2026, Chaînes de confiance