DuoKey PKI/SSL Overview
A full certificate-authority and certificate-lifecycle platform built into DuoKey Cockpit, with vault/HSM-protected signing keys.
What is DuoKey PKI/SSL?
DuoKey PKI/SSL is a complete Public Key Infrastructure built into DuoKey Cockpit. It lets an organization run its own certificate authorities (root and intermediate), or front external / public CAs, then issue, deploy, monitor and revoke certificates across its estate — with the CA signing keys held in a vault / HSM and never leaving it in the clear.
Unlike a single-purpose SSL request form, the platform covers the whole certificate life cycle: a CA hierarchy, a request-and-approval workflow, the standard enrollment protocols (ACME, EST, SCEP, CMP, Kubernetes cert-manager, KMIP), a catalog of external CA issuers, deployment connectors to network devices and cloud services, OCSP responders and CRL distribution, and both classical and post-quantum key algorithms.
Where a public-CA concept (such as DV/OV/EV validation tiers) does not apply to a privately operated CA, it is intentionally omitted from this platform.
Core capabilities
CA hierarchy & lifecycle
Root, intermediate and imported external CAs, with suspend / reactivate, simple and cascading revoke, archive, and a read-only lifecycle-impact preview before any cascading action.
Certificate lifecycle
Issue under a CA, a CSR approval workflow (request → approve/reject → issue), renew, revoke with RFC 5280 reasons, and reusable certificate templates.
Standard enrollment protocols
ACME (RFC 8555), EST (RFC 7030), SCEP (RFC 8894), CMP (RFC 4210/9483), Kubernetes cert-manager, and a KMIP 2.1 server endpoint.
External CA issuers
Front public and cloud CAs: Let's Encrypt, AWS Private CA, Azure Key Vault CA, Google Cloud CAS, Sectigo, DigiCert, QuoVadis, Cloudflare and more.
Deployment automation
Push certificates to F5 BIG-IP, Fortinet FortiGate, Azure App Service, Entra ID, and Apache / Nginx / IIS / JKS / Windows CAPI — with validation and rollback.
Validation & revocation
Per-CA OCSP responders and CRL generation and distribution, so relying parties can check certificate status in real time.
Post-quantum ready
Issue with NIST PQC signature algorithms (ML-DSA, SLH-DSA) and a hybrid ML-DSA-65 + ECDSA-P256 composite, alongside classical RSA and ECC.
Discovery & compliance
Network and agent-based TLS/certificate scanning, discovered-certificate import, per-certificate SSL/TLS audit and compliance evaluation (Mozilla / NIST / PCI DSS).
Vault-protected keys
CA signing keys are vault-backed, including external HSM-backed vaults (e.g. Securosys FIPS 140-2 Level 3). Managed leaf-certificate keys are currently generated and held in the platform's software vault; with the export permission, a certificate's private key can be downloaded (PEM or PKCS#12).
Architecture
Requesters and devices enroll through the PKI service, which signs against the vault/HSM, records to PostgreSQL, and fans out to issuer, validation and deployment connectors.
Certificate authorities
A CA is created inside the platform and its signing key is generated locally or, for post-quantum and HSM-protected CAs, held in the vault.
| CA type | How it is created |
|---|---|
| Root CA | Self-signed trust anchor |
| Intermediate / issuing CA | Signed by a parent root or intermediate; parent-algorithm compatibility is enforced for PQC / hybrid chains |
| External CA | Imported from an existing PKI so the platform can track and manage it |
Every CA supports a full lifecycle: suspend (RFC 5280 certificateHold) and reactivate, simple revoke and cascade revoke (which also revokes sub-CAs and issued certificates), and archive / unarchive (once the CA has stopped issuing). Before any cascading action you can request a lifecycle-impact preview that reports the blast radius. Each CA can publish its chain, a CRL, and an OCSP responder.
Certificate types and key algorithms
| Certificate type | Typical extended key usage |
|---|---|
| CA | Certificate signing (roots / intermediates) |
| Server (TLS/SSL) | ServerAuth |
| Client (mTLS) | ClientAuth |
| Code signing | CodeSigning |
| Email (S/MIME) | EmailProtection |
Subject alternative names can be DNS, IP, email or URI, including wildcard DNS entries (for example *.example.com). Available key usages and extended key usages follow the RFC 5280 set (ServerAuth, ClientAuth, CodeSigning, EmailProtection, TimeStamping, OcspSigning).
| Family | Supported key algorithms |
|---|---|
| RSA | RSA-2048, RSA-4096 |
| ECC | EC-P256, EC-P384 |
| Post-quantum (signatures) | ML-DSA-44/65/87 (FIPS 204), SLH-DSA-128F/128S (FIPS 205) |
| Hybrid / composite | ML-DSA-65 + ECDSA-P256 |
RSA-3072 and EC-P521 are not supported, and there is no 8192-bit RSA option. Post-quantum and hybrid CAs are vault-signed (their keys are vault-resident); classical CAs can sign locally.
Enrollment protocols
Devices and workloads can enrol directly using the protocol they already speak — each has a public protocol endpoint plus admin configuration in the Cockpit.
| Protocol | Standard | Typical use |
|---|---|---|
| ACME | RFC 8555 | Automated web-server certificates (Let's-Encrypt-style clients, cert-manager) |
| EST | RFC 7030 | Enrollment over secure transport for devices and gateways |
| SCEP | RFC 8894 | Network devices and MDM-managed endpoints |
| CMP | RFC 4210 / 9483 | Certificate management for industrial / operator PKIs |
| cert-manager | Kubernetes | External issuer for Kubernetes workloads |
| KMIP | OASIS KMIP 2.1 | Cockpit acts as a KMIP server for key/cert objects |
External CA issuers
Instead of (or alongside) your own CAs, the platform can drive external certificate authorities through issuer connectors, so requests, renewals and revocations flow through one console.
| Issuer | Backend |
|---|---|
| Let's Encrypt | Public ACME CA (incl. http-01 challenge handling) |
| AWS Private CA | AWS ACM Private CA |
| Azure Key Vault CA | Azure Key Vault certificate CA |
| Google Cloud CAS | Google Certificate Authority Service |
| Sectigo | Commercial CA |
| DigiCert / QuoVadis | DigiCert CertCentral (and QuoVadis subsidiary) |
| Cloudflare | Origin / edge CA |
| Volkswagen Group PKI | PPCS mTLS enterprise PKI |
| Internal CA | A locally operated, vault-backed CA |
Each issuer supports test-connection, issue, renew, revoke and (for ACME) account registration.
Deployment targets
Issued certificates can be pushed straight to where they terminate TLS, with per-job validation and rollback.
| Target | Notes |
|---|---|
| F5 BIG-IP | iControl REST — deploy cert+key or cert-only, with rollback |
| Fortinet FortiGate | Deploy and rollback |
| Azure App Service | Bind certificates to app services |
| Entra ID | App Proxy and App Registration |
| Apache · Nginx · IIS · JKS · Windows CAPI | Generic deploy targets |
| ServiceNow CMDB | Inventory / expiry sync (not a TLS-termination target) |
Access control
PKI operations are gated by fine-grained, tenant-scoped role-based permissions, checked per action. Separate permissions cover managing certificate authorities, issuing and revoking certificates, approving or rejecting requests, and managing revocation data — so you can enforce a clean separation of duties.
Because permissions are tenant-scoped, each organization only ever sees and manages its own CAs and certificates.
Explore by module
CA Management
Root, intermediate and external CAs, and the full CA lifecycle
Issuers
External, cloud and internal CA connectors
Enrollment Protocols
ACME, EST, SCEP, CMP, cert-manager, KMIP
Deployment
Push certificates to F5, Fortinet, Azure, Entra and more
Revocation (OCSP & CRL)
Publish and check certificate status
Post-Quantum PKI
ML-DSA, SLH-DSA and hybrid certificates
Discovery & Compliance
Scan, audit and score TLS across the estate
Prerequisites
Prerequisites
- Active DuoKey Cockpit account with PKI access
- The relevant PKI permissions (or an admin role)
- A vault configured for CA signing keys
- For external issuers: credentials for the target CA (API key, account, or cloud role)