Construire une PKI : AC racine et émettrice, CRL et OCSP

Le problème : un certificat qui devrait cesser de fonctionner

Le certificat que Mariama a obtenu dans l’article 2 est valable un an. Trois mois plus tard, le jeton qui contient sa clé de signature est volé, avec son code PIN. Le certificat affirme toujours, sous la signature d’une AC, que cette clé publique est la sienne. Tant que rien ne change, toute signature produite par le voleur se vérifiera.

Ibrahima a besoin d’un moyen d’apprendre que ce certificat ne mérite plus sa confiance, même si ses dates semblent correctes, et quelqu’un doit avoir fixé par écrit qui peut demander une révocation et où la réponse est publiée. Délivrer un certificat tient en une commande ; construire une PKI, c’est bâtir le système qui l’entoure.

Les RFC de l’IETF, les exigences du CA/Browser Forum et les manuels d’OpenSSL cités ici n’existent qu’en anglais : leurs citations sont traduites par nos soins.

Les composants d’une PKI

Une PKI opérationnelle organise les rôles de l’article 2 en hiérarchie et y ajoute des services qui indiquent l’état des certificats.

La hiérarchie : une racine hors ligne et une AC émettrice

La RFC 5280 n’impose aucune forme : un chemin part d’un certificat d’entité finale, traverse zéro ou plusieurs certificats d’AC et remonte jusqu’à une clé à laquelle la partie utilisatrice (relying party) fait confiance (RFC 5280, §3.2). Une architecture privée courante compte deux niveaux : une racine qui ne signe que des certificats d’AC émettrices et des CRL, et une AC émettrice qui signe tout le reste. Le terme « hors ligne » n’apparaît ni dans la RFC 5280, ni dans la RFC 6960, ni dans la RFC 3647 à propos d’une AC racine. La pratique vient de l’industrie ; les règles du CA/Browser Forum applicables aux autorités de certification TLS reconnues publiquement consignent les contrôles qui l’encadrent.

Les Network and Certificate System Security Requirements admettent des systèmes d’AC racine « isolés du réseau (air-gapped) ou autrement » (CABF-NSR, définitions) : ils n’exigent donc pas une racine hors ligne. Ils exigent en revanche que les systèmes qui détiennent une clé racine se trouvent sur des réseaux physiquement séparés de toute autre infrastructure de l’AC (§1.2.1), et l’accès physique à ces systèmes requiert un contrôle multipartite (multi-party control) : au moins deux personnes autorisées, chacune avec ses propres identifiants (§2.2.4). Les Baseline Requirements ajoutent que chaque opération de signature de la racine exige qu’une personne autorisée « émette délibérément une commande directe » : la signature par la racine n’est jamais automatisée (CABF-BR, §4.3.1.1).

Notre lecture, qu’aucune source ne donne comme justification : une racine qui ne signe que des certificats d’AC et des CRL ne sert que quelques fois par an, et sa clé est donc rarement exposée. L’AC émettrice peut être en ligne car, si elle est compromise, la racine reste intacte et peut la révoquer puis signer une remplaçante ; son pathlen:0 l’empêche de créer d’autres AC (RFC 5280, §4.2.1.9), ce qui limite les dégâts aux certificats d’entité finale.

Cérémonies de clés

Une clé racine est générée une seule fois, au cours d’une cérémonie. Les Baseline Requirements en décrivent une : suivre un script écrit, la faire observer par un auditeur qualifié ou l’enregistrer en vidéo, avec des rôles de confiance soumis au contrôle de plusieurs personnes et au partage des connaissances, dans des modules cryptographiques, et tout consigner (CABF-BR, §6.1.1.1). Le module est le HSM de l’article 3 ; la cérémonie l’entoure de personnes et de témoins.

La RFC 3647 pose les mêmes questions sans imposer de réponses : combien de personnes chaque tâche exige (« n parmi m ») (RFC 3647, §4.5.2), si la clé est découpée de sorte que n parts quelconques sur m suffisent à la reconstituer (§4.6.2, §7), et comment la clé publique de l’AC parvient aux parties utilisatrices de façon sûre (§4.6.1).

Profils de certificats

Un profil est l’ensemble des champs et extensions qu’une AC place dans chaque type de certificat.

Le tableau suit la RFC 5280 : un certificat d’AC exige une extension basicConstraints critique avec cA à vrai (RFC 5280, §4.2.1.9) et une extension keyUsage avec keyCertSign, qui devrait être critique (§4.2.1.3) ; un point de distribution de CRL en HTTP sert une seule CRL encodée en DER (§4.2.1.13) ; et l’AIA indique où trouver l’OCSP et le certificat de l’émetteur, jamais des CRL (§4.2.2.1).

Un magasin de confiance est une politique

Comme l’a montré l’article 2, choisir une ancre de confiance relève de la politique (RFC 5280, §6), et ajouter votre racine au magasin d’Ibrahima revient à dire « j’accepte ce que garantissent cette AC et tout ce qui se trouve en dessous ». OpenSSL vérifie tout de même la période de validité de la racine, mais son autosignature seulement avec -check_ss_sig (openssl-verification-options).

L’expiration n’est pas la révocation

L’expiration est la fin prévue d’un certificat. La révocation, c’est l’AC qui y met fin avant terme, pour un motif comme un changement de nom ou une clé compromise (RFC 5280, §3.3). L’entrée d’un certificat révoqué dans la CRL doit y rester jusqu’à ce qu’elle ait figuré sur une CRL périodique émise après l’expiration du certificat ; elle peut ensuite disparaître (§3.3, §5). Et un certificat ne peut pas être validé pour un instant situé hors de sa période de validité (§6.1). Prouver que Mariama a signé pendant la validité de son certificat exige une heure de confiance pour la signature : c’est le sujet de l’article 7.

Les CRL : une liste signée de numéros de série

Une liste de révocation de certificats (certificate revocation list) (CRL) est une liste horodatée, signée par l’AC ou par un émetteur de CRL délégué, des certificats révoqués, identifiés par leur numéro de série (RFC 5280, §3.3). Une partie utilisatrice « se procure une CRL suffisamment récente », la notion de « suffisamment récente » étant laissée à la politique locale. Une CRL signée peut transiter par des serveurs non fiables ; sa faiblesse est la latence, car les CRL paraissent selon un calendrier et une révocation n’apparaît que dans la suivante.

Lorsqu’une AC émet des CRL, celles-ci doivent être en version 2 et comporter nextUpdate, un numéro de CRL et un identifiant de clé de l’autorité (§5). thisUpdate est la date d’émission et nextUpdate la date à laquelle la CRL suivante paraîtra, au plus tard (§5.1.2.4, §5.1.2.5) ; le numéro de CRL ne fait que croître (§5.2.3). Chaque entrée comporte un numéro de série et une date de révocation (§5.1.2.6), et éventuellement :

• un code de motif, comme keyCompromise, cACompromise, superseded ou cessationOfOperation. La RFC 5280 demande de l’omettre plutôt que d’écrire « unspecified » (§5.3.1) ;
• une date d’invalidité, celle où la compromission a eu lieu ou a été soupçonnée, qui peut précéder la date de révocation (§5.3.2). Pour le jeton volé de Mariama, la date d’invalidité marque l’ouverture de la fenêtre du voleur ; celle-ci ne se referme que lorsque les parties utilisatrices voient la révocation.

OCSP : interroger sur un seul certificat

L’Online Certificate Status Protocol permet à une application de s’enquérir de certificats précis, « à la place des CRL ou en complément », lorsqu’elle a besoin d’informations plus à jour (RFC 6960, §2). La requête désigne le certificat par les empreintes du nom et de la clé de son émetteur, et par son numéro de série (§4.1.1).

Les réponses définitives sont signées, par l’AC émettrice, par un répondeur auquel le client fait directement confiance ou par un répondeur que l’AC a autorisé (§2.2). Il existe trois statuts :

• good : aucun certificat portant ce numéro de série n’est révoqué pendant sa période de validité. Ce statut « ne signifie pas nécessairement que le certificat a jamais été délivré ».
• revoked : révoqué définitivement ou suspendu. Rejetez-le.
• unknown : ce répondeur ne connaît pas le certificat, en général parce qu’il ne dessert pas cet émetteur. Essayez une autre source, comme une CRL.

Les réponses d’erreur comme tryLater ne sont pas signées (§2.3) ; traitez-les comme une absence totale de statut.

Une réponse porte thisUpdate, nextUpdate et producedAt (§2.4), et peut être préproduite (§2.5). Une réponse dont le nextUpdate est dépassé n’est pas fiable ; sans nextUpdate, des informations plus récentes sont toujours disponibles (§4.2.2.1). Un client n’accepte une réponse que si elle correspond au certificat, si son signataire est autorisé et valide, et si elle est à jour (§3.2).

Une AC délègue la signature en remettant à un répondeur un certificat portant l’usage étendu de clé id-kp-OCSPSigning, délivré directement par l’AC qui a délivré le certificat contrôlé. Un client n’accepte une réponse que si elle est signée par cette AC elle-même, par un tel répondeur délégué ou par un répondeur auquel il fait confiance localement ; tout autre signataire doit être rejeté (§2.6, §4.2.2.2). Contre le rejeu, une requête peut porter un nonce : de 1 à 128 octets, et au moins 32 de la part des demandeurs (RFC 9654, §2.1). Un répondeur peut omettre le nonce ; un intervalle court entre thisUpdate et nextUpdate sert alors de défense de repli (§3.1).

Lequel choisir ? Le contrôle en ligne réduit la latence, mais le validateur doit faire confiance au service en ligne, alors qu’un dépôt de CRL n’a pas besoin d’être digne de confiance (RFC 5280, §3.3). Une PKI peut publier les deux. Un répondeur peut aussi conserver les données de révocation au-delà de l’expiration, jusqu’à une date dite « archive cutoff » (RFC 6960, §4.4.4) ; les articles 6 et 7 montrent comment un PDF signé embarque CRL et réponses OCSP, pour que personne n’ait à poser la question des années plus tard.

Anticiper la compromission

Un jeton volé, c’est un certificat à révoquer. Une clé d’AC émettrice compromise, c’est la racine qui révoque l’AC émettrice, avec le motif cACompromise, et tout ce qui se trouve en dessous perd son chemin valide. Un répondeur qui sait qu’une clé d’AC est compromise peut répondre revoked pour tous les certificats délivrés par cette AC (RFC 6960, §2.7). La RFC 3647 demande à la déclaration des pratiques de prévoir le signalement des incidents, la reprise après une compromission de clé et la continuité d’activité (RFC 3647, §4.5.7). Une compromission de la racine impose une nouvelle ancre de confiance dans le magasin de chaque partie utilisatrice, et c’est, selon notre lecture, la raison pour laquelle la racine reste hors ligne.

Politique de certification et déclaration des pratiques de certification

Une politique de certification (certificate policy) (PC, ou CP en anglais) est « un ensemble nommé de règles qui indique l’applicabilité d’un certificat à une communauté particulière et/ou à une classe d’applications ayant des exigences de sécurité communes » (RFC 3647, §2). Une déclaration des pratiques de certification (certification practice statement) (DPC, ou CPS en anglais) est « une déclaration des pratiques qu’une autorité de certification applique pour délivrer, gérer, révoquer et renouveler des certificats, avec ou sans changement de clé ».

La PC dit ce que les participants doivent faire ; la DPC dit comment une AC le fait. Une PC couvre souvent plusieurs AC ; une DPC n’en couvre qu’une et entre davantage dans le détail (§3.5). Un certificat désigne sa PC par un OID dans l’extension des politiques de certificat et peut pointer vers la DPC par une URL (§3.3.1).

Les deux suivent un même plan en neuf parties (§3.7) : introduction ; publication et dépôt ; identification et authentification ; exigences opérationnelles sur le cycle de vie des certificats ; contrôles des installations, de la gestion et des opérations ; contrôles de sécurité techniques ; profils des certificats, des CRL et d’OCSP ; audit de conformité ; autres questions commerciales et juridiques.

Une rubrique peut indiquer « aucune stipulation », mais la RFC 3647 recommande de conserver chaque intitulé, pour montrer que la décision était délibérée (§4). Une DPC n’est pas automatiquement un contrat ; elle n’engage que lorsqu’un autre accord l’y intègre (§3.4). La RFC 3647 date de 2003 et reflète le contexte américain ; la portée juridique d’une DPC dans un pays donné est une question à poser à un avocat.

Gérer sa propre AC ou recourir à une AC externe ?

Gérer votre propre PKI vous donne un contrôle total, et vous rend responsable de tout ce qui précède. Les parties utilisatrices extérieures à votre organisation n’acceptent vos certificats que s’ils ajoutent votre racine (RFC 5280, §6). Une AC externe figure peut-être déjà dans les magasins de confiance qu’utilisent vos parties utilisatrices (demandez lesquels) et publie sa propre PC et sa propre DPC ; posez-lui les questions de cet article : quelle politique, quels services de statut, quels délais. Le même raisonnement vaut pour choisir un prestataire de signature électronique.

Le certificat de Mariama est révoqué, Ibrahima vérifie

1. Mariama signale le vol par le canal que désigne la DPC de son AC, et l’AC s’assure que c’est bien elle.
2. L’AC révoque le numéro de série 1000 avec le motif keyCompromise, émet une nouvelle CRL portant un numéro plus élevé, et son répondeur OCSP commence à répondre revoked.
3. Un contrat arrive, signé avec son ancienne clé après le vol. La signature est mathématiquement valide et la chaîne remonte jusqu’à la racine d’Ibrahima.
4. Son logiciel trouve le numéro de série 1000 sur une CRL à jour, ou reçoit un revoked signé, et rejette la signature.

Si son logiciel avait utilisé une CRL antérieure à l’étape 2, il aurait accepté la signature.

À vous : révoquer un certificat, contrôler une CRL et interroger OCSP

Une AC minimale construite avec openssl ca délivre des certificats à Mariama et à Ibrahima, révoque celui de Mariama, publie une CRL et contrôle les deux certificats avec elle, puis interroge un répondeur OCSP sur chacun. Pour rester court, cette démonstration utilise une seule AC pour tout : sa clé est en ligne, elle signe certificats, CRL et réponses OCSP, et ses certificats ne comportent ni point de distribution de CRL ni AIA. Un déploiement réel sépare ces fonctions comme décrit plus haut. Le manuel qualifie openssl ca d’« exemple d’application d’AC minimale » qui « n’est pas de qualité production », et conseille de garder les clés de signature dans un HSM ou une carte à puce (openssl-ca).

Enregistrez les scripts de chaque étape sous les noms step1.sh, step2.sh et step3.sh dans un même répertoire, et lancez cette commande depuis celui-ci. Votre répertoire est monté en lecture seule ; les clés et fichiers de l’AC restent dans un conteneur jetable. Ne les réutilisez jamais.

Exemple pédagogique exécutable · Docker · alpine:3.22 · OpenSSL 3.5.8 25 Aug 2026

docker run --rm --mount type=bind,src="$PWD",dst=/in,readonly -w /work alpine:3.22 sh -c '
apk add --no-cache openssl >/dev/null
openssl version
cp /in/step1.sh /in/step2.sh /in/step3.sh .
echo "### Step 1: a CA and two certificates ###"
sh step1.sh
echo "### Step 2: revoke, publish a CRL, check ###"
sh step2.sh
echo "### Step 3: an OCSP responder ###"
sh step3.sh
'

Elle affiche la version d’OpenSSL, puis la sortie de chaque script sous une ligne ### Step N ###.

Étape 1 : une AC et deux certificats

Exemple pédagogique exécutable · Docker · alpine:3.22 · OpenSSL 3.5.8 25 Aug 2026

DS="dig""ital""Signature"
mkdir -p newcerts
touch index.txt
echo 1000 > serial
echo 1000 > crlnumber
cat > ca.cnf <<CFG
[ca]
default_ca = CA_default

[CA_default]
dir              = .
database         = ./index.txt
serial           = ./serial
crlnumber        = ./crlnumber
new_certs_dir    = ./newcerts
certificate      = ./ca.pem
private_key      = ./ca.key
default_md       = sha256
default_days     = 825
default_crl_days = 30
policy           = policy_any
x509_extensions  = usr_cert
copy_extensions  = none
crl_extensions   = crl_ext

[policy_any]
commonName = supplied

[req]
distinguished_name = req_dn
prompt              = no
x509_extensions     = v3_ca

[req_dn]
CN = Demo Root CA

[v3_ca]
basicConstraints = critical,CA:true
keyUsage         = critical,keyCertSign,cRLSign

[usr_cert]
basicConstraints = CA:FALSE
keyUsage         = ${DS},nonRepudiation

[ocsp]
basicConstraints   = CA:FALSE
keyUsage           = critical,${DS}
extendedKeyUsage    = critical,OCSPSigning

[crl_ext]
authorityKeyIdentifier = keyid:always
CFG
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ca.key
openssl req -config ca.cnf -new -x509 -key ca.key -out ca.pem -days 3650
openssl x509 -in ca.pem -noout -subject -dates
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out mariama.key
openssl req -new -key mariama.key -out mariama.csr -subj "/CN=Mariama Diallo"
openssl ca -config ca.cnf -batch -notext -in mariama.csr -out mariama.pem
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ibrahima.key
openssl req -new -key ibrahima.key -out ibrahima.csr -subj "/CN=Ibrahima Bah"
openssl ca -config ca.cnf -batch -notext -in ibrahima.csr -out ibrahima.pem
openssl verify -CAfile ca.pem mariama.pem
openssl verify -CAfile ca.pem ibrahima.pem

openssl ca conserve son état dans des fichiers : index.txt recense les certificats délivrés, serial contient le prochain numéro de série et crlnumber le prochain numéro de CRL. copy_extensions = none a son importance : avec copyall, une CSR qui demande CA:TRUE pourrait produire un certificat d’AC fonctionnel (openssl-ca). La ligne DS= sert seulement à contourner une particularité de l’outil de capture ; vous pouvez taper digitalSignature directement.

OpenSSL 3.5.8 25 Aug 2026 (Library: OpenSSL 3.5.8 25 Aug 2026)
### Step 1: a CA and two certificates ###
subject=CN=Demo Root CA
notBefore=Sep 23 08:55:44 2026 GMT
notAfter=Sep 20 08:55:44 2036 GMT
Using configuration from ca.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'Mariama Diallo'
Certificate is to be certified until Dec 26 08:55:44 2028 GMT (825 days)

Write out database with 1 new entries
Database updated
Using configuration from ca.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'Ibrahima Bah'
Certificate is to be certified until Dec 26 08:55:44 2028 GMT (825 days)

Write out database with 1 new entries
Database updated
mariama.pem: OK
ibrahima.pem: OK

Chaque exécution d’openssl ca vérifie la signature de la CSR, affiche le sujet et inscrit le certificat dans index.txt. Les deux certificats se vérifient avec l’AC.

Étape 2 : révoquer, publier une CRL, contrôler

Exemple pédagogique exécutable · Docker · alpine:3.22 · OpenSSL 3.5.8 25 Aug 2026

openssl ca -config ca.cnf -revoke mariama.pem -crl_reason keyCompromise
cat index.txt
openssl ca -config ca.cnf -gencrl -out crl.pem
openssl crl -in crl.pem -noout -text
cat ca.pem crl.pem > ca-chain.pem
openssl verify -crl_check -CAfile ca-chain.pem mariama.pem
echo "mariama exit=$?"
openssl verify -crl_check -CAfile ca-chain.pem ibrahima.pem
echo "ibrahima exit=$?"

openssl crl ne fait qu’afficher la CRL produite par openssl ca -gencrl (openssl-crl). openssl verify -crl_check contrôle le certificat d’entité finale avec une CRL, et -crl_check_all toute la chaîne (openssl-verification-options). La CRL voyage dans le même -CAfile que le certificat de l’AC (constaté ici ; l’option documentée est -CRLfile) (openssl-verify).

### Step 2: revoke, publish a CRL, check ###
Using configuration from ca.cnf
Revoking Certificate 1000.
Database updated
R	281226085544Z	260923085544Z,keyCompromise	1000	unknown	/CN=Mariama Diallo
V	281226085544Z		1001	unknown	/CN=Ibrahima Bah
Using configuration from ca.cnf
Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=Demo Root CA
        Last Update: Sep 23 08:55:44 2026 GMT
        Next Update: Oct 23 08:55:44 2026 GMT
        CRL extensions:
            X509v3 Authority Key Identifier:
                5A:15:EC:BF:28:81:0B:6F:19:C6:4B:B6:A3:0A:74:6E:DC:F5:C2:D8
            X509v3 CRL Number:
                4096
Revoked Certificates:
    Serial Number: 1000
        Revocation Date: Sep 23 08:55:44 2026 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Key Compromise
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:46:02:21:00:b3:1f:45:39:94:d9:a5:0a:2c:0e:bc:96:22:
        56:31:47:6d:47:d5:2c:29:90:b4:1f:74:ad:44:0b:f8:86:e1:
        b8:02:21:00:e1:b1:a6:63:da:e3:71:d3:61:0f:5e:3b:6d:ae:
        85:1c:81:1f:f3:55:69:a1:74:38:16:f0:d7:8e:7f:1b:63:e9
CN=Mariama Diallo
error 23 at 0 depth lookup: certificate revoked
error mariama.pem: verification failed
mariama exit=2
ibrahima.pem: OK
ibrahima exit=0

-revoke a fait passer la ligne de Mariama dans index.txt de V à R, avec l’heure et le motif ; celle d’Ibrahima reste à V. La CRL affichée contient ce que la RFC 5280 exige d’une AC conforme (§5) : elle est en Version 2 ; Last Update et Next Update correspondent à thisUpdate et nextUpdate, espacés de 30 jours à cause de default_crl_days ; l’Authority Key Identifier désigne la clé d’AC qui l’a signée ; et le CRL Number, 4096, permet à un vérificateur de savoir quelle CRL est la plus récente. openssl ca n’ajoute ce numéro que parce que le fichier crlnumber existe, et n’écrit une CRL en version 2 avec l’identifiant que grâce à la section crl_extensions (openssl-ca).

Pour Mariama, on obtient error 23 at 0 depth lookup: certificate revoked, la profondeur 0 étant son propre certificat, et le code de sortie 2. Celui d’Ibrahima passe avec la même CRL. OpenSSL rejette une CRL dont le nextUpdate est dépassé (erreur 12, CRL has expired), mais accepte toute CRL en cours de validité que vous lui fournissez, même émise avant la révocation. Se procurer la dernière CRL, c’est à vous de le faire.

Étape 3 : un répondeur OCSP

Exemple pédagogique exécutable · Docker · alpine:3.22 · OpenSSL 3.5.8 25 Aug 2026

openssl ocsp -index index.txt -port 8080 -rsigner ca.pem -rkey ca.key -CA ca.pem -nrequest 2 -text -out responder.log &
RESPONDER_PID=$!
sleep 1
echo "=== query: mariama.pem (revoked) ==="
openssl ocsp -CAfile ca.pem -issuer ca.pem -cert mariama.pem -url http://127.0.0.1:8080 -resp_text -no_nonce | tail -n 15
echo "=== query: ibrahima.pem (good, not revoked) ==="
openssl ocsp -CAfile ca.pem -issuer ca.pem -cert ibrahima.pem -url http://127.0.0.1:8080 -resp_text -no_nonce | tail -n 15
wait $RESPONDER_PID 2>/dev/null

Avec -index, openssl ocsp devient un répondeur qui, selon le manuel, « n’est utile qu’à des fins de test et de démonstration » (openssl-ocsp). Il tourne en arrière-plan et s’arrête après deux requêtes (-nrequest 2). La clé de l’AC elle-même signe les réponses, ce que la RFC 6960 permet. Côté client, -issuer vient avant -cert, et -no_nonce désactive le nonce par défaut pour garder l’échange minimal.

### Step 3: an OCSP responder ###
ACCEPT 0.0.0.0:8080 PID=35
ocsp: waiting for OCSP client connections...
=== query: mariama.pem (revoked) ===
ocsp: received request, 1st line: POST / HTTP/1.0
ocsp: sending response, 1st line: HTTP/1.0 200 OK
Response verify OK
        75:29:de:81:b5:28:1b:df:0e:8d:03:b9:d2:48:e0:41
-----BEGIN CERTIFICATE-----
MIIBcTCCARigAwIBAgIUfbAvE1eIfl/ZEa3LTsMWDPFrwMwwCgYIKoZIzj0EAwIw
FzEVMBMGA1UEAwwMRGVtbyBSb290IENBMB4XDTI2MDkyMzA4NTU0NFoXDTM2MDky
MDA4NTU0NFowFzEVMBMGA1UEAwwMRGVtbyBSb290IENBMFkwEwYHKoZIzj0CAQYI
KoZIzj0DAQcDQgAE5/RwiFcQa5qkK6lO4Vf4/YGRMFhloWVVFX5LZsXqnheS63Zw
juGKh0SSZy0PWfTmTriWISJSm2z1b+9Hi5iDwqNCMEAwDwYDVR0TAQH/BAUwAwEB
/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFoV7L8ogQtvGcZLtqMKdG7c9cLY
MAoGCCqGSM49BAMCA0cAMEQCIG1RdDajaYRqI8qNLl5Zv+klwvf5swgb+/FuZ5Ny
Wcx6AiBbGt3CqR9YgN9LRlvSUy3IdSnegbUoG98OjQO50kjgQQ==
-----END CERTIFICATE-----
mariama.pem: revoked
	This Update: Sep 23 08:55:45 2026 GMT
	Reason: keyCompromise
	Revocation Time: Sep 23 08:55:44 2026 GMT
=== query: ibrahima.pem (good, not revoked) ===
ocsp: received request, 1st line: POST / HTTP/1.0
ocsp: sending response, 1st line: HTTP/1.0 200 OK
Response verify OK
        bf:e9:25:c2:f7:f9:b3:08:1b:fb:f1:6e:67:93:72:59:cc:7a:
        02:20:5b:1a:dd:c2:a9:1f:58:80:df:4b:46:5b:d2:53:2d:c8:
        75:29:de:81:b5:28:1b:df:0e:8d:03:b9:d2:48:e0:41
-----BEGIN CERTIFICATE-----
MIIBcTCCARigAwIBAgIUfbAvE1eIfl/ZEa3LTsMWDPFrwMwwCgYIKoZIzj0EAwIw
FzEVMBMGA1UEAwwMRGVtbyBSb290IENBMB4XDTI2MDkyMzA4NTU0NFoXDTM2MDky
MDA4NTU0NFowFzEVMBMGA1UEAwwMRGVtbyBSb290IENBMFkwEwYHKoZIzj0CAQYI
KoZIzj0DAQcDQgAE5/RwiFcQa5qkK6lO4Vf4/YGRMFhloWVVFX5LZsXqnheS63Zw
juGKh0SSZy0PWfTmTriWISJSm2z1b+9Hi5iDwqNCMEAwDwYDVR0TAQH/BAUwAwEB
/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFoV7L8ogQtvGcZLtqMKdG7c9cLY
MAoGCCqGSM49BAMCA0cAMEQCIG1RdDajaYRqI8qNLl5Zv+klwvf5swgb+/FuZ5Ny
Wcx6AiBbGt3CqR9YgN9LRlvSUy3IdSnegbUoG98OjQO50kjgQQ==
-----END CERTIFICATE-----
ibrahima.pem: good
	This Update: Sep 23 08:55:45 2026 GMT

Response verify OK signifie que la signature de la réponse a été vérifiée avec l’AC de confiance. Au-dessus du statut, tail -n 15 laisse voir la fin de la signature et le certificat du signataire. Vient ensuite le statut : revoked pour Mariama, avec le motif keyCompromise de la CRL, et good pour Ibrahima. Sans -ndays, les réponses ne portent pas de nextUpdate, si bien que seule une ligne This Update apparaît ; sans nonce non plus, cette démonstration n’offre aucune protection contre le rejeu. Un vrai client garde le nonce et un vrai répondeur fixe nextUpdate.

Les clés et les signatures sont aléatoires : les identifiants de clé, les octets de signature et le bloc de certificat changent à chaque exécution, et les dates suivent l’horloge. Les numéros de série s’affichent en hexadécimal (1000 et 1001, soit 4096 et 4097) et le numéro de CRL en décimal (4096) ; tous deux viennent des fichiers serial et crlnumber que l’étape 1 initialise à 1000, pas d’OpenSSL. Le PID du répondeur peut aussi changer, tout comme la ligne de version d’OpenSSL, puisque alpine:3.22 suit la dernière version 3.22.x.

La place de SEDEYA

SEDEYA signe des PDF au format PAdES, jusqu’au niveau B-LTA, avec des horodatages RFC 3161 et les données de validation intégrées au fichier ; les informations de révocation, comme les CRL et les réponses OCSP, font partie de ces données. Ses clés de signature sont conservées dans un HSM (PKCS#11) ou un KMS. Ibrahima n’a pas besoin d’openssl verify : il peut déposer le PDF sur la page de vérification publique de SEDEYA ou scanner son QR code. Les prochains articles de cette série traitent de la transaction de signature et de la durée pendant laquelle une signature reste vérifiable.

Risques et idées reçues

En résumé

• Une PKI privée comprend souvent une racine hors ligne qui ne signe que des certificats d’AC et des CRL, et une AC émettrice en ligne limitée par pathlen:0, selon une pratique de l’industrie plutôt qu’une règle de RFC.
• Les certificats d’AC exigent une extension basicConstraints critique avec CA:TRUE, et keyCertSign. Les points de distribution de CRL et l’AIA indiquent aux parties utilisatrices où contrôler le statut.
• Une CRL est une liste signée de numéros de série révoqués, à jour jusqu’à nextUpdate. OCSP fournit un statut signé good, revoked ou unknown pour chaque certificat.
• Dans la partie pratique, le contrôle par CRL (erreur 23) comme OCSP ont signalé le certificat de Mariama comme révoqué ; celui d’Ibrahima est resté good.
• Une PC dit à quoi sert un certificat et ce que les participants doivent faire ; une DPC dit comment une AC le fait.

Vérifiez votre compréhension

Prochaine étape

Un certificat, une chaîne et un contrôle de statut indiquent à Ibrahima à qui appartient la clé qui a signé et si elle était encore valable, mais pas ce que Mariama a accepté de signer. L’article 5 traite de la transaction de signature. D’ici là, parlez-nous : nous vous montrerons un PDF signé par SEDEYA qui embarque ses propres données de validation, et comment n’importe qui peut le vérifier.