Est

Enterprise certificate enrollment has a tooling problem. Most organizations run a certificate authority — often Red Hat Certificate System (Dogtag), Microsoft AD CS, or EJBCA — but getting certificates onto devices, servers, and workloads still involves brittle SCEP integrations, custom scripts, or manual CSR submission. The enrollment layer is the weak link. EST (Enrollment over Secure Transport) was designed to fix this. Published as RFC 7030 in 2013, it replaces SCEP with a modern HTTPS-based protocol that supports mutual TLS, one-time passwords, and integration with existing CAs. But production-ready EST implementations remain scarce — especially ones that meet government and enterprise compliance requirements. ...

A Certificate Authority that only speaks one protocol is a CA that only serves one audience. Enterprise networks need EST for managed devices. DevOps teams expect ACME for automated renewal. IoT deployments require CoAP for constrained devices. Kubernetes clusters want SPIFFE for workload identity. HashiCorp shops need Vault integration. And existing Red Hat infrastructure needs Dogtag compatibility. PKI.Next serves all six from a single CA, using independent protocol server binaries that communicate with the CA through mTLS-authenticated API calls. This post explains the architecture, the protocol implementations, and why the Registration Authority pattern makes this possible without compromising security. ...

In the previous post, I covered event-driven certificate lifecycle management — how Ansible automates revocation when identity events fire. But revocation is only half the story. Before you can revoke a certificate, you have to issue one. And for IoT devices, issuance needs to be automated, constrained, and scalable. This post digs into the enrollment side: how to configure Dogtag PKI certificate profiles specifically for IoT devices, how to expose those profiles over the EST protocol for automated device enrollment, and how to manage it all with Ansible. ...