Het Lab

Live certificaatintrekking — vertrouwd, daarna geweigerd

De blikvanger van elk SkyQon-prospectgesprek. Een echt EJBCA-cluster geeft een echt certificaat uit. Dat certificaat opent een mTLS-beschermde dienst. We trekken het in — OCSP antwoordt in dezelfde seconde met revoked, en precies diezelfde client wordt aan de rand geweigerd. Live, zonder simulatie.

De flow

Zes stappen. Onder een seconde. Echte intrekking, dan echt verlopen.

Elke stap hieronder draait tegen een productierijp lab op Proxmox. De exacte commando's worden getoond zodat uw engineers ze kunnen reproduceren.

Het testcertificaat uitgeven

De actie 'Certificaat uitgeven' in het dashboard stuurt een CSR naar de EJBCA REST-API. ECDSA P-384, ondertekend door SkyQon Issuing CA G2 met SHA512withECDSA. Het certificaat komt binnen seconden terug, en de privésleutel verlaat de aanvragende host nooit.

POST /ejbca-rest-api/v1/certificate/pkcs10enroll → 201

Er een beschermde dienst mee openen

Het certificaat wordt aangeboden aan een mTLS-rand die verify required afdwingt tegen de uitgevende CA. De handshake slaagt en de dienst antwoordt met de distinguished name van de geauthenticeerde client — het bewijs dat het certificaat, en niet een wachtwoord, de deur opende.

curl --cert demo.pem --key demo.key https://demo… → 200 access granted

Het certificaat intrekken

Klik op „Intrekken” in het PKI Ops Dashboard, of roep EJBCA REST rechtstreeks aan. Reden: KEY_COMPROMISE. EJBCA schrijft de intrekking in zijn auditlog en werkt de weergave van de OCSP-responder onmiddellijk bij.

PUT /ejbca-rest-api/v1/certificate/{issuer}/{serial}/revoke

OCSP-verspreiding

De OCSP-responder weerspiegelt de intrekking meteen. Bij deze repetitie ging de status in dezelfde seconde van good naar revoked, met reden KEY_COMPROMISE. OCSP is het realtimesignaal; voor vertrouwende partijen die in plaats daarvan CRL's controleren publiceren we op verzoek een verse CRL in plaats van het natuurlijke verversingsvenster af te wachten.

openssl ocsp -issuer IssuingCA-G2.crt -cert test.pem … → revoked

Diezelfde client wordt geweigerd

De rand weigert nu het certificaat dat hij even daarvoor accepteerde, en weigert het op TLS-niveau — de applicatie ziet het verzoek nooit. Een nog geldig certificaat op dezelfde frontend wordt in één adem wél geaccepteerd; juist dat bewijst dat de weigering aan de intrekking ligt en niet aan een kapotte listener.

same command → TLS alert: certificate revoked

Een agent krijgt een identiteit van vijf minuten en verliest die vanzelf

Een echte geautomatiseerde workload — onze push-agent op de PKI-dashboardhost — krijgt een SPIFFE X.509-identiteit van een SPIRE-server waarvan het ondertekencertificaat door onze EJBCA is uitgegeven onder een aparte Workload-CA, geketend aan dezelfde root. De rand laat hem alleen toe als keten, SPIFFE-ID en uitgever kloppen, en weigert hetzelfde certificaat al tijdens de handshake zodra de 300 seconden voorbij zijn. Geen intrekkingslijst, geen OCSP: vertrouwen verloopt gewoon.

spiffe-helper → curl --cert svid.pem https://demo…:8445 → 200 admitted · +300 s → alert certificate expired
0.2s
Uitgeven
<0.1s
Toegang verleend
<0.1s
Intrekken
<0.1s
OCSP-verspreiding
0.2s
Rand weigert
0.6s
Totaal waargenomen

Gemeten op 17 augustus 2026 via het REST-pad op een labnetwerk; elke waarde is de eigen doorlooptijd van die fase. „Rand weigert” omvat het publiceren van de verse CRL, het herladen ervan aan de rand en de geweigerde handshake. Bij een demonstratie vanuit het dashboard komen de klikken van de operator daar nog bovenop.

<0.1s
Identiteit uitgegeven
<0.1s
Agent toegelaten
300s
Levensduur, dan weigering

Stap 6 gemeten op 6 september 2026 in hetzelfde lab: 44 ms voor de eerste identiteit van de workload, 42–67 ms tot de rand hem toelaat, daarna 300 seconden levensduur waarna hetzelfde certificaat tijdens de TLS-handshake wordt geweigerd, zonder dat er een lijst wordt gepubliceerd. De uitgevende CA heeft naast haar ECDSA-sleutel een post-kwantumsleutel (ML-DSA-87) en ondertekent de SPIRE-uitgever dubbel; de agentcertificaten zelf zijn ECDSA.

In uw omgeving

Wat een intrekking verandert in een geweigerd verzoek

Intrekking stopt een aanvaller alleen als de vertrouwende partij daadwerkelijk controleert. Ons lab bewijst het mechanisme van begin tot eind; uw omgeving bepaalt de vorm ervan. Welke terminator de controle afdwingt, welke diensten erachter staan, of hij OCSP raadpleegt of een CRL die u op verzoek publiceert, en wat er gebeurt als de responder onbereikbaar is — dat zijn implementatiekeuzes, geen standaardwaarden, en ze verkeerd maken is precies hoe een ingetrokken certificaat blijft werken. Dat is het ingenieurswerk dat we samen met u doen.

De lab-stack

Productierijp. Geen sandbox.

Elk component draait op Proxmox VE op precies dezelfde manier als in een klantomgeving. We hebben het lab bewust tot ons demo-asset gemaakt — dus als we „beproefd in het lab” zeggen, bedoelen we het letterlijk.

EJBCA-cluster

EJBCA Communityactive/active

Twee backends achter de pki.skyqon.com-VIP. ECDSA P-384 / SHA3-512. SoftHSM2-ondersteunde sleutels.

MariaDB Galera

3 nodesPROXY-v2

Een Galera-cluster met drie knooppunten. HAProxy-single-writer-VIP met PROXY-protocol v2 om het client-IP te behouden.

HashiCorp Vault

KV-v2AppRole

Applicatiesecrets via KV-v2. AppRole-authenticatie voor de levering van niet-menselijke inloggegevens.

HAProxy

TLS terminationmTLS verifySNI

TLS-terminatie en SNI-routering voor de interne diensten van het lab — en de mTLS-rand die de demonstratie zelf afdwingt: verify required tegen de uitgevende CA, met de bijbehorende CRL geladen.

Salt + Woodpecker

Salt 3006salt-apiWoodpecker CI

Salt-master via nginx vooraf geplaatst voor TLS. Woodpecker CI stoot state-apply aan via salt-api.

Graylog

GELFstreams

Eén observability-sink. EJBCA-audit, Salt-events en mislukte TLS-handshakes — één tijdlijn.

Wilt u het live zien?

Plan een rondleiding van 30 minuten. We delen het scherm, voeren de demo end-to-end uit en beantwoorden de technische vragen die uw CA-team zal stellen.