Live certificate revocation — trusted, then refused
The headline of every SkyQon prospect call. A real EJBCA cluster issues a real certificate. That certificate opens an mTLS-protected service. We revoke it — OCSP answers revoked in the same second, and the very same client is refused at the edge. Live, no simulations.
Six steps. Under a second. Real revocation, then real expiry.
Each step below executes against a production-grade lab on Proxmox. The exact commands are shown so your engineers can reproduce them.
Issue the test certificate
The dashboard's "Issue Certificate" action posts a CSR to EJBCA REST. ECDSA P-384, signed by SkyQon Issuing CA G2 with SHA512withECDSA. The certificate comes back in seconds, and the private key never leaves the requesting host.
POST /ejbca-rest-api/v1/certificate/pkcs10enroll → 201
Open a protected service with it
The certificate is presented to an mTLS edge that runs verify required against the issuing CA. The handshake completes and the service answers, echoing back the authenticated client's distinguished name — proof that the certificate, not a password, is what opened the door.
curl --cert demo.pem --key demo.key https://demo… → 200 access granted
Revoke the certificate
Click "Revoke" in the PKI Ops Dashboard, or call EJBCA REST directly. Reason: KEY_COMPROMISE. EJBCA writes the revocation to its audit log and updates the OCSP responder's view immediately.
PUT /ejbca-rest-api/v1/certificate/{issuer}/{serial}/revoke
OCSP propagation
The OCSP responder reflects the revocation at once. In this rehearsal the status went from good to revoked in the same second, with reason KEY_COMPROMISE. OCSP is the real-time signal; for relying parties that check CRLs instead, we publish a fresh CRL on demand rather than waiting out the natural refresh window.
openssl ocsp -issuer IssuingCA-G2.crt -cert test.pem … → revoked
The same client is refused
The edge now rejects the certificate it accepted moments earlier, and it rejects it at the TLS layer — the application never sees the request. A still-valid certificate on the same frontend is accepted in the same breath, which is what proves the refusal is revocation doing its job and not a broken listener.
same command → TLS alert: certificate revoked
An agent gets a five-minute identity, and loses it on its own
A real automation workload — our push agent on the PKI dashboard host — obtains a SPIFFE X.509 identity from a SPIRE server whose signing certificate is enrolled from our EJBCA under a dedicated Workload CA chained to the same root. The edge admits it only if the chain, the SPIFFE ID and the issuer all check out, and refuses the identical certificate at the handshake once its 300-second lifetime ends. No revocation list, no OCSP: trust simply expires.
spiffe-helper → curl --cert svid.pem https://demo…:8445 → 200 admitted · +300 s → alert certificate expired
Measured on 17 August 2026 across the REST path on a lab network; each figure is that phase's own elapsed time. "Edge refuses" covers publishing the fresh CRL, the edge reloading it and the refused handshake. A dashboard-driven walkthrough adds the operator's own clicks on top.
Step 6 measured on 6 September 2026 on the same lab: 44 ms for the workload's first identity, 42–67 ms for the edge to admit it, and a 300-second lifetime after which the same certificate is refused during the TLS handshake with no list published. The issuing CA holds a post-quantum (ML-DSA-87) key alongside its ECDSA key and dual-signs the SPIRE issuer; the agent certificates themselves are ECDSA.
What turns a revocation into a denied request
Revocation only stops an attacker if the relying party actually checks. Our lab proves the mechanism end to end; your estate decides the shape of it. Which terminator enforces the check, which services sit behind it, whether it consults OCSP or a CRL you publish on demand, and what happens when the responder is unreachable — those are deployment decisions, not defaults, and getting them wrong is how a revoked certificate keeps working. That is the engineering we do with you.
Production-grade. Not a sandbox.
Every component runs on Proxmox VE the same way it would in a customer deployment. We doubled the lab as our demo asset deliberately — so when we say "lab-proven," we mean it literally.
EJBCA cluster
Two backends behind the pki.skyqon.com VIP. ECDSA P-384 / SHA3-512. SoftHSM2-backed keys.
MariaDB Galera
A three-node Galera cluster. HAProxy single-writer VIP with PROXY protocol v2 to preserve client IP.
HashiCorp Vault
Application secrets via KV-v2. AppRole authentication for non-human credential delivery.
HAProxy
TLS termination and SNI routing for the lab's internal services — and the mTLS edge that enforces the demo itself: verify required against the issuing CA, with its CRL loaded.
Salt + Woodpecker
Salt master fronted by nginx for TLS. Woodpecker CI dispatches state apply through salt-api.
Graylog
A single observability sink. EJBCA audit, Salt events and TLS handshake failures — one timeline.
Three ways to see it
Live walkthrough
Book a 30-minute call with a SkyQon engineer. We run it on our infrastructure while you watch and ask questions.
Book a callFrom the dashboard
The PKI Ops Dashboard drives the demo end to end, walking through every step with the exact commands.
See the dashboard ↗On your own infrastructure
We help you deploy the same setup — a PKI design plus automation engagement. End result: you can run this on a Tuesday.
Read more →Want to watch it live?
Book a 30-minute walkthrough. We share the screen, run the demo end to end, and answer the technical questions your CA team will ask.