Révocation de certificat en direct — de confiance, puis refusé
Le moment fort de chaque rendez-vous prospect SkyQon. Un vrai cluster EJBCA émet un vrai certificat. Ce certificat ouvre un service protégé par mTLS. Nous le révoquons — l'OCSP répond revoked dans la même seconde, et ce même client est refusé en périphérie. En direct, sans simulation.
Six étapes. Moins d'une seconde. Une vraie révocation, puis une vraie expiration.
Chaque étape ci-dessous s'exécute sur un labo de production sur Proxmox. Les commandes exactes sont affichées pour que vos ingénieurs puissent les reproduire.
Émettre le certificat de test
L'action « Émettre un certificat » du tableau de bord envoie une CSR à l'API REST d'EJBCA. ECDSA P-384, signé par SkyQon Issuing CA G2 en SHA512withECDSA. Le certificat revient en quelques secondes, et la clé privée ne quitte jamais la machine demandeuse.
POST /ejbca-rest-api/v1/certificate/pkcs10enroll → 201
Ouvrir un service protégé avec ce certificat
Le certificat est présenté à une périphérie mTLS configurée en verify required face à l'autorité émettrice. La poignée de main aboutit et le service répond en renvoyant le nom distinctif du client authentifié — la preuve que c'est le certificat, et non un mot de passe, qui a ouvert la porte.
curl --cert demo.pem --key demo.key https://demo… → 200 access granted
Révoquer le certificat
Cliquez sur « Révoquer » dans le PKI Ops Dashboard, ou appelez EJBCA REST directement. Raison : KEY_COMPROMISE. EJBCA écrit la révocation dans son journal d'audit et met à jour la vue du répondeur OCSP immédiatement.
PUT /ejbca-rest-api/v1/certificate/{issuer}/{serial}/revoke
Propagation OCSP
Le répondeur OCSP reflète la révocation aussitôt. Lors de cette répétition, le statut est passé de good à revoked dans la même seconde, avec la raison KEY_COMPROMISE. L'OCSP est le signal temps réel ; pour les parties utilisatrices qui vérifient plutôt les CRL, nous publions une CRL fraîche à la demande au lieu d'attendre la fenêtre de rafraîchissement naturelle.
openssl ocsp -issuer IssuingCA-G2.crt -cert test.pem … → revoked
Le même client est refusé
La périphérie rejette désormais le certificat qu'elle acceptait quelques instants plus tôt, et elle le rejette au niveau TLS — l'application ne voit jamais la requête. Un certificat encore valide sur la même frontale est accepté dans la foulée, ce qui prouve que le refus vient bien de la révocation et non d'un écouteur défaillant.
same command → TLS alert: certificate revoked
Un agent reçoit une identité de cinq minutes, et la perd tout seul
Une vraie charge de travail automatisée — notre agent de collecte sur l'hôte du tableau de bord PKI — obtient une identité X.509 SPIFFE auprès d'un serveur SPIRE dont le certificat de signature est délivré par notre EJBCA sous une CA « Workload » dédiée, rattachée à la même racine. La périphérie ne l'admet que si la chaîne, l'identifiant SPIFFE et l'émetteur sont tous corrects, et refuse le même certificat dès la poignée de main une fois ses 300 secondes de vie écoulées. Pas de liste de révocation, pas d'OCSP : la confiance expire, tout simplement.
spiffe-helper → curl --cert svid.pem https://demo…:8445 → 200 admitted · +300 s → alert certificate expired
Mesuré le 17 août 2026 sur le chemin REST d'un réseau de laboratoire ; chaque valeur correspond au temps écoulé de l'étape concernée. « Refus en périphérie » couvre la publication de la CRL fraîche, son rechargement par la périphérie et la poignée de main refusée. Une démonstration pilotée depuis le tableau de bord ajoute les clics de l'opérateur.
Étape 6 mesurée le 6 septembre 2026 sur le même laboratoire : 44 ms pour la première identité de la charge de travail, 42 à 67 ms pour que la périphérie l'admette, puis une durée de vie de 300 secondes après laquelle le même certificat est refusé pendant la poignée de main TLS, sans qu'aucune liste ne soit publiée. La CA émettrice détient une clé post-quantique (ML-DSA-87) à côté de sa clé ECDSA et signe doublement l'émetteur SPIRE ; les certificats des agents eux-mêmes sont ECDSA.
Ce qui transforme une révocation en requête refusée
Une révocation n'arrête un attaquant que si la partie utilisatrice vérifie réellement. Notre laboratoire prouve le mécanisme de bout en bout ; c'est votre parc qui en décide la forme. Quel terminateur applique le contrôle, quels services se trouvent derrière, s'il interroge l'OCSP ou une CRL que vous publiez à la demande, et ce qui se passe quand le répondeur est injoignable — ce sont des décisions de déploiement, pas des valeurs par défaut, et s'y tromper est précisément ce qui laisse un certificat révoqué continuer à fonctionner. C'est l'ingénierie que nous menons avec vous.
De production. Pas un bac à sable.
Chaque composant tourne sur Proxmox VE de la même façon que dans un déploiement client. Nous avons délibérément fait du labo notre actif de démo — donc quand nous disons « éprouvé en labo », c'est littéralement vrai.
Cluster EJBCA
Deux backends derrière le VIP pki.skyqon.com. ECDSA P-384 / SHA3-512. Clés adossées à SoftHSM2.
MariaDB Galera
Un cluster Galera à trois nœuds. VIP HAProxy mono-writer avec PROXY protocole v2 pour préserver l'IP client.
HashiCorp Vault
Secrets applicatifs via KV-v2. Authentification AppRole pour la livraison d'identifiants non humains.
HAProxy
Terminaison TLS et routage SNI pour les services internes du laboratoire — et la périphérie mTLS qui applique la démonstration elle-même : verify required face à l'autorité émettrice, avec sa CRL chargée.
Salt + Woodpecker
Master Salt exposé via nginx pour le TLS. Woodpecker CI dispatche l'application d'état via salt-api.
Graylog
Un puits d'observabilité unique. Audit EJBCA, événements Salt et échecs de négociation TLS — une seule chronologie.
Trois façons de le voir
Démo guidée
Réservez un appel de 30 minutes avec un ingénieur SkyQon. Nous l'exécutons sur notre infrastructure pendant que vous regardez et posez des questions.
Réserver un appelDepuis le tableau de bord
Le PKI Ops Dashboard pilote la démo de bout en bout, en parcourant chaque étape avec les commandes exactes.
Voir le tableau de bord ↗Sur votre propre infrastructure
Nous vous aidons à déployer le même setup — un engagement de conception PKI plus automatisation. Résultat : vous pouvez l'exécuter un mardi.
En savoir plus →Envie de le voir en direct ?
Réservez une démo guidée de 30 minutes. Nous partageons l'écran, exécutons la démo de bout en bout et répondons aux questions techniques que votre équipe CA posera.