Live-Zertifikatswiderruf — vertraut, dann abgewiesen
Der Aufhänger jedes SkyQon-Kundengesprächs. Ein echter EJBCA-Cluster stellt ein echtes Zertifikat aus. Dieses Zertifikat öffnet einen mTLS-geschützten Dienst. Wir sperren es — OCSP antwortet in derselben Sekunde mit revoked, und genau derselbe Client wird am Rand abgewiesen. Live, ohne Simulation.
Sechs Schritte. Unter einer Sekunde. Echter Widerruf, dann echter Ablauf.
Jeder Schritt unten läuft gegen ein produktionsreifes Labor auf Proxmox. Die genauen Befehle werden gezeigt, damit Ihre Ingenieure sie reproduzieren können.
Testzertifikat ausstellen
Die Aktion „Zertifikat ausstellen“ im Dashboard sendet eine CSR an die EJBCA-REST-API. ECDSA P-384, signiert von der SkyQon Issuing CA G2 mit SHA512withECDSA. Das Zertifikat kommt in Sekunden zurück, und der private Schlüssel verlässt den anfragenden Host nie.
POST /ejbca-rest-api/v1/certificate/pkcs10enroll → 201
Damit einen geschützten Dienst öffnen
Das Zertifikat wird einem mTLS-Rand vorgelegt, der verify required gegen die ausstellende CA durchsetzt. Der Handshake gelingt, und der Dienst antwortet mit dem Distinguished Name des authentifizierten Clients — der Beweis, dass das Zertifikat und nicht ein Passwort die Tür geöffnet hat.
curl --cert demo.pem --key demo.key https://demo… → 200 access granted
Zertifikat sperren
Klicken Sie im PKI Ops Dashboard auf „Sperren“ oder rufen Sie EJBCA REST direkt auf. Grund: KEY_COMPROMISE. EJBCA schreibt die Sperrung in sein Audit-Log und aktualisiert die Sicht des OCSP-Responders sofort.
PUT /ejbca-rest-api/v1/certificate/{issuer}/{serial}/revoke
OCSP-Verbreitung
Der OCSP-Responder bildet den Widerruf sofort ab. In diesem Probelauf wechselte der Status in derselben Sekunde von good auf revoked, mit dem Grund KEY_COMPROMISE. OCSP ist das Echtzeitsignal; für vertrauende Parteien, die stattdessen CRLs prüfen, veröffentlichen wir eine frische CRL auf Abruf, statt das natürliche Aktualisierungsfenster abzuwarten.
openssl ocsp -issuer IssuingCA-G2.crt -cert test.pem … → revoked
Derselbe Client wird abgewiesen
Der Rand lehnt nun das Zertifikat ab, das er Augenblicke zuvor akzeptiert hat — und zwar auf TLS-Ebene, die Anwendung sieht die Anfrage nie. Ein noch gültiges Zertifikat wird am selben Frontend im gleichen Atemzug akzeptiert; genau das beweist, dass die Abweisung der Sperrung geschuldet ist und nicht einem defekten Listener.
same command → TLS alert: certificate revoked
Ein Agent erhält eine Fünf-Minuten-Identität und verliert sie von selbst
Eine echte Automatisierungs-Workload — unser Push-Agent auf dem PKI-Dashboard-Host — erhält eine SPIFFE-X.509-Identität von einem SPIRE-Server, dessen Signaturzertifikat aus unserer EJBCA unter einer eigenen Workload-CA stammt, die an dieselbe Wurzel gekettet ist. Der Rand lässt sie nur zu, wenn Kette, SPIFFE-ID und Aussteller stimmen, und weist dasselbe Zertifikat nach Ablauf seiner 300 Sekunden schon im Handshake ab. Keine Sperrliste, kein OCSP: Vertrauen läuft einfach ab.
spiffe-helper → curl --cert svid.pem https://demo…:8445 → 200 admitted · +300 s → alert certificate expired
Gemessen am 17. August 2026 über den REST-Pfad in einem Labornetz; jeder Wert ist die reine Laufzeit der jeweiligen Phase. „Rand weist ab“ umfasst das Veröffentlichen der frischen CRL, deren Neuladen am Rand und den abgewiesenen Handshake. Eine über das Dashboard geführte Vorführung dauert um die Klicks des Bedieners länger.
Schritt 6 gemessen am 6. September 2026 im selben Labor: 44 ms für die erste Identität der Workload, 42–67 ms, bis der Rand sie zulässt, danach 300 Sekunden Lebensdauer, nach denen dasselbe Zertifikat im TLS-Handshake abgewiesen wird — ohne dass eine Liste veröffentlicht wird. Die ausstellende CA hält neben ihrem ECDSA-Schlüssel einen Post-Quanten-Schlüssel (ML-DSA-87) und signiert den SPIRE-Aussteller doppelt; die Agent-Zertifikate selbst sind ECDSA.
Was aus einem Widerruf eine abgewiesene Anfrage macht
Ein Widerruf stoppt einen Angreifer nur, wenn die vertrauende Partei tatsächlich prüft. Unser Labor belegt den Mechanismus von Anfang bis Ende; welche Form er annimmt, entscheidet Ihre Umgebung. Welcher Terminator die Prüfung durchsetzt, welche Dienste dahinterliegen, ob er OCSP oder eine von Ihnen auf Abruf veröffentlichte CRL abfragt und was geschieht, wenn der Responder nicht erreichbar ist — das sind Deployment-Entscheidungen, keine Standardwerte, und Fehler darin sind genau der Grund, warum ein gesperrtes Zertifikat weiter funktioniert. Das ist die Ingenieursarbeit, die wir mit Ihnen leisten.
Produktionsreif. Keine Sandbox.
Jede Komponente läuft auf Proxmox VE genauso wie in einer Kundenbereitstellung. Wir haben das Labor bewusst zu unserem Demo-Asset gemacht — wenn wir „im Labor erprobt“ sagen, meinen wir es wörtlich.
EJBCA-Cluster
Zwei Backends hinter dem VIP pki.skyqon.com. ECDSA P-384 / SHA3-512. SoftHSM2-gestützte Schlüssel.
MariaDB Galera
Ein Galera-Cluster mit drei Knoten. HAProxy-Single-Writer-VIP mit PROXY-Protokoll v2 zur Erhaltung der Client-IP.
HashiCorp Vault
Anwendungssecrets über KV-v2. AppRole-Authentifizierung für die Auslieferung nicht-menschlicher Anmeldedaten.
HAProxy
TLS-Terminierung und SNI-Routing für die internen Dienste des Labors — und der mTLS-Rand, der die Vorführung selbst durchsetzt: verify required gegen die ausstellende CA, mit geladener CRL.
Salt + Woodpecker
Salt-Master über nginx für TLS vorgeschaltet. Woodpecker CI stößt State-Apply über salt-api an.
Graylog
Eine einzige Observability-Senke. EJBCA-Audit, Salt-Events und fehlgeschlagene TLS-Handshakes — eine Zeitleiste.
Drei Wege, es zu sehen
Live-Begehung
Buchen Sie ein 30-minütiges Gespräch mit einem SkyQon-Ingenieur. Wir führen es auf unserer Infrastruktur aus, während Sie zusehen und Fragen stellen.
Gespräch buchenAus dem Dashboard
Das PKI Ops Dashboard steuert die Demo durchgängig und führt durch jeden Schritt mit den genauen Befehlen.
Zum Dashboard ↗Auf Ihrer eigenen Infrastruktur
Wir helfen Ihnen, dasselbe Setup bereitzustellen — ein PKI-Design- plus Automatisierungs-Engagement. Ergebnis: Sie können es an einem Dienstag ausführen.
Mehr erfahren →Möchten Sie es live sehen?
Buchen Sie eine 30-minütige Begehung. Wir teilen den Bildschirm, führen die Demo durchgängig aus und beantworten die technischen Fragen, die Ihr CA-Team stellen wird.