Skip to main content

PKI protocols

The point of speaking standard protocols is that ordinary clients work without a vendor SDK. This page is what actually serves, and what deliberately does not.

What serves​

ProtocolWhat it does
OCSPOnline revocation status, with a responder and a staple cache so revocation is answered on the wire
CRLX.509 certificate revocation lists
SSH KRLSSH key revocation lists, with their own propagation path
SPIFFE workload APIIssues X.509 and JWT identity documents to workloads
KMIPExternal clients create, get and destroy keys over the standard protocol

Those five are real, ungated surfaces.

What does not serve, and why that is the right answer​

ACME, EST and SCEP are wire-surface scaffolds. They do not issue certificates in any configuration.

This matters more than it looks, because ACME is the first thing a security evaluator tests: certbot and cert-manager both speak it, and pointing one at a platform is a thirty-second check.

ProtocolState
ACME (RFC 8555)Fail-closed scaffold. Returns 503 by default
EST (RFC 7030)Fail-closed scaffold. Returns 503 by default
SCEPFail-closed scaffold. Returns 503 by default

There are operator opt-in switches for all three, and they do not make them work. Turning one on converts the 503 into a deterministic 501 from an explicit not-implemented error. There is no configuration in which these three issue a certificate.

Say five, not eight

The platform's own claim register carries this as a corrected claim: an earlier proof point said "eight PKI protocol servers" and counted all three scaffolds. It was a claim defect rather than a code defect, since the code was already refusing correctly and only the description was wrong.

Quote five. The full implementations for the three enrollment protocols, CSR validation, challenge engines, account stores, CMS verifiers and real issuance, are roadmap.

Why refuse deterministically​

A scaffold that accepted an enrollment request and returned something plausible-looking would be the worst available outcome. An operator would wire certbot against it, see a response, and believe their certificate lifecycle was automated.

The posture here is the same one the object surface takes when it returns 501 for operations it will not enforce: an unenforced acceptance is a false assurance, and worse than a missing feature. A 503 that becomes a 501 when you insist is a control an evaluator can verify in one command, and it is why the five that do serve are believable.

What to use instead today​

Certificate issuance runs through the platform's own provisioning path rather than through an enrollment protocol: every principal is issued X.509, SSH and OpenPGP material at creation, and devices enroll over the Edge Agent's own bootstrap channel, generating their key on-device and receiving a short-lived certificate bound to a delegation token.

For workloads, the SPIFFE workload API is the standard-protocol answer and it does serve.