Enrollment Protocols
Let devices and workloads enrol automatically using the protocol they already speak.
Architecture
Standard enrollment protocols
Devices and workloads enrol over the protocol they already speak; the CA bound to each endpoint issues and renews their certificates.
Overview
Beyond the manual request-and-approval workflow, DuoKey exposes the standard enrollment protocols so clients can obtain and renew certificates without human steps. Each protocol has a public protocol endpoint (what clients call) and admin configuration in the Cockpit (bound to a CA and gated by permissions).
| Protocol | Standard | Typical clients |
|---|---|---|
| ACME | RFC 8555 | certbot, acme.sh, Kubernetes cert-manager, Caddy |
| EST | RFC 7030 | Routers, gateways, IoT devices |
| SCEP | RFC 8894 | Network devices, MDM-managed endpoints |
| CMP | RFC 4210 / 9483 | Industrial and operator PKIs |
| cert-manager | Kubernetes | Kubernetes workloads (external issuer) |
| KMIP | OASIS KMIP 2.1 | KMIP clients (key / certificate objects) |
| Windows autoenrollment | MS-XCEP / MS-WSTEP | Domain-joined Windows clients through Group Policy (preview) |
ACME (RFC 8555)
An ACME server per CA, covering the account, order, authorization, challenge, finalize and download flow, with ACME Renewal Information (RFC 9773) so clients renew when the CA suggests — see Short-Lived Certificates & ACME ARI. The revoke-cert request is accepted but does not yet add the certificate to the CRL or OCSP responses. Point any ACME client (or cert-manager's ACME issuer) at the CA's ACME directory URL — {cockpit-url}/api/pki/acme/{ca-id}/directory.
http-01 challenges are validated for real: the ACME server fetches http://{domain}/.well-known/acme-challenge/{token} back from the requester and checks the key authorization, exactly like a public CA would. There is no silent auto-approval — an internal or trusted-network CA can opt into skipping this check for lab use, but it is off by default.
Using ACME with Kubernetes cert-manager
The most direct way to get DuoKey-issued, auto-renewing TLS certificates into a Kubernetes cluster today is cert-manager's built-in ACME issuer type, pointed at your CA's ACME directory. This has been verified end-to-end against a real cluster: cert-manager both issuing and renewing a certificate through this endpoint.
Prerequisites
- ACME enabled on the issuing CA (Cockpit → PKI → ACME → Configure)
- cert-manager installed in the cluster
- An ingress controller installed (cert-manager's http-01 solver routes the challenge through it)
- The requested domain resolves to somewhere the Cockpit can reach — a public address, or a private-network address if the Cockpit runs inside your network (loopback and link-local targets are always rejected)
Register a ClusterIssuer
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: dke-cockpit-acme
spec:
acme:
server: https://{cockpit-url}/api/pki/acme/{ca-id}/directory
email: [email protected]
privateKeySecretRef:
name: dke-cockpit-acme-account-key
solvers:
- http01:
ingress:
ingressClassName: nginxRequest a certificate
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: example-tls
namespace: default
spec:
secretName: example-tls
dnsNames:
- app.example.com
issuerRef:
name: dke-cockpit-acme
kind: ClusterIssuer
group: cert-manager.ioRenewal is automatic
cert-manager reissues before expiry (its default is two-thirds of the certificate's lifetime, configurable via renewBefore), driving the exact same order → challenge → finalize flow as the initial issuance — no manual intervention required.
EST (RFC 7030)
Enrollment over Secure Transport, supporting the standard cacerts, simpleenroll, simplereenroll, serverkeygen and csrattrs operations for devices and gateways. For fleet provisioning, renewal and rate limits, see Device Identity at Scale.
SCEP (RFC 8894)
Simple Certificate Enrollment Protocol with configurable profiles for classic SCEP clients such as network devices and MDM-managed endpoints. A profile can validate each request with Microsoft Intune instead of a static challenge — see Intune & MDM Certificate Delivery.
SCEP decrypts each request with the CA key, which vault back-ends do not offer. A SCEP profile therefore needs an RSA CA whose key is held in software by the platform; it cannot use a CA whose key is in an HSM, a cloud KMS or an MPC vault.
CMP (RFC 4210 / 9483)
Certificate Management Protocol with named aliases, transaction tracking and per-alias metrics, for industrial and operator PKIs. See Device Identity at Scale for provisioning and kur renewal.
Windows autoenrollment (MS-XCEP / MS-WSTEP)
Domain-joined Windows users and computers can enroll and renew certificates from a DuoKey CA through Group Policy (preview) — see Windows Autoenrollment.
Kubernetes cert-manager (native external issuer)
DuoKey also defines a native cert-manager external-issuer type (API group dke.duokey.com), for a tighter CSR-relay integration without an intermediate ACME layer — cert-manager submits CSRs directly and DuoKey returns signed certificates.
This integration is still on its way to general availability — reach out to your DuoKey contact for current status. The ACME method above is the supported way to use cert-manager with DuoKey today.
KMIP 2.1 server
DuoKey can act as a KMIP server, exposing key / certificate objects and operations to KMIP clients.
Unified endpoint lifecycle
All protocol endpoints (EST / SCEP / ACME / CMP / KMIP) share a common endpoint lifecycle — deploy, start, pause, stop — with health and metrics, so you can operate them consistently.
Sequence
ACME order flow
ACME (RFC 8555): the client proves control of the domain over http-01, submits a CSR, then downloads the issued certificate, fully automated.