EST (Enrolment over Secure Transport, RFC 7030) is a modern, HTTP/TLS-native enrolment protocol. Skyrsoft CertOps exposes it the same way it exposes SCEP: as named endpoints, each mapping a URL slug to a template and an issuing CA. The slug is fixed at creation, so renaming a template or CA later never breaks a URL a client is already configured with. Unlike SCEP, every EST call authenticates with a real, ongoing credential — an API key — rather than a one-time challenge password embedded in the request. EST is a Pro feature; Free licences get HTTP 402 from the endpoints.
How it works
| Operation | Auth | Purpose |
|---|---|---|
cacerts |
None | Fetch the CA certificate chain |
simpleenroll |
API key | Submit a CSR and receive a certificate |
simplereenroll |
API key | Submit a fresh CSR under the same key to renew |
Re-enrolling with the key you already have
An EST client keeps its API key for the life of the deployment, so renewing is simply presenting
that same key again with a fresh CSR against simplereenroll — there is no separate mechanism to
configure, and nothing expires the way a SCEP one-time challenge does. RFC 7030 §4.2.2 also lets a
client attach its existing certificate to a reenroll request as a courtesy, and CertOps checks the
new CSR’s subject and SANs against it, refusing a mismatch with 403. That certificate arrives as
a client-supplied X-Client-Certificate header rather than something TLS itself verified, so
treat the check as a consistency safeguard rather than proof the caller holds the key it names —
the API key is what actually authenticates the call, on enroll and reenroll alike.
Approval gating and retries
The same two independent settings SCEP uses govern EST, with the same effect: with Enforce
certificate template approval rules off — the default — every enrolment issues immediately once
the API key verifies, whatever the template’s own approval setting says. Turn it on and a queued
request gets 202 Accepted with a Retry-After: 60 header, and the client is expected to resend
the identical request until it gets back 200 with the certificate. When a retry matches an
earlier request from the same API key, template and byte-identical CSR within the last 24 hours,
CertOps looks up that request’s current status rather than queuing a new one — so the very next
automatic retry after an admin approves picks up the certificate, not merely a retry that happens
to land after approval.
Limits
The X-Client-Certificate header on simplereenroll is not an authentication boundary. It is
supplied by the client, not verified by TLS, so it proves nothing about possession on its own —
RFC 7030 describes it as informational, and CertOps checks it as a consistency safeguard rather
than a credential. That is not a gap specific to reenroll: it runs through the same API key,
template, approval rules and issuing CA as an ordinary enroll, so nothing is reachable through it
that enroll does not already reach.
A retried request is matched by content, and the match window is 24 hours. If approval takes longer than that, the client’s next retry queues as a fresh request rather than reconnecting to the one an admin already reviewed — nothing is lost, it simply no longer counts as the same attempt.
A single byte of difference in the retried CSR breaks the match. EST has no per-attempt token of its own to anchor a retry to the way SCEP’s one-time challenge does, so the match relies on the CSR being identical on every resend.