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 generated and used inside a vault, HSM, cloud KMS or MPC cluster when the CA is created with one (see CA Key Protection).
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) plus Windows autoenrollment and Intune delivery, 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) with renewal information (RFC 9773), EST (RFC 7030), SCEP (RFC 8894), CMP (RFC 4210/9483), Kubernetes cert-manager, a KMIP 2.1 server endpoint, Windows autoenrollment (preview) and Intune SCEP / PKCS delivery (preview).
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, then renew and redeploy them automatically before they expire.
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).
HSM, KMS and MPC-protected CA keys
A CA created with a vault keeps its signing key in that vault — HSM (e.g. Securosys), cloud KMS or MPC cluster — and every certificate, CRL and OCSP response is signed there; nothing is exported. A CA created without a vault uses a software key stored by the platform, and can be migrated. 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).
Expiry alerts & short-lived certificates
Expiry alerts by e-mail, Microsoft Teams, Slack and webhooks, once per threshold, and ACME renewal information so clients renew on time as lifetimes shrink towards 47 days.
Code signing & device identity
A code signing service for SignTool, JAR, Git and cosign with non-exportable vault keys and approvals, and EST / CMP device provisioning for IoT and network fleets.
Governance
M-of-N quorum on CA revocation, archive, CA and template changes and high-value issuance, and access policies by user, IP, country and time on issuance and revocation, across every enrollment protocol.
Architecture
Architecture
PKI/SSL 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. When it is created with a vault, its signing key is generated and held in that vault (HSM, cloud KMS or MPC cluster) and never exported; without a vault, the key is generated in software and stored by the platform. Post-quantum and hybrid CAs are always vault-resident. See CA Key Protection.
| 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-3072, RSA-4096, RSA-8192 (CA keys) |
| ECC | EC-P256, EC-P384, EC-P521 (CA keys) |
| Post-quantum (signatures) | ML-DSA-44/65/87 (FIPS 204), SLH-DSA-128F/128S (FIPS 205) |
| Hybrid / composite | ML-DSA-65 + ECDSA-P256 |
RSA-2048, RSA-4096, EC-P256 and EC-P384 are available for a CA key in every vault. RSA-3072, RSA-8192 and EC-P521 depend on where the CA key is held:
- Software Vault and Securosys Primus: all three.
- Azure Key Vault:
RSA-3072andEC-P521. Azure stops at 4096-bit RSA. - AWS KMS:
EC-P521. RSA CA keys are not held in AWS KMS, because the platform creates AWS RSA keys for encryption. - Google Cloud KMS: none of the three. Google has no P-521 curve, and the platform creates Google RSA keys for encryption.
- No vault: all three, held as a software key stored with the CA.
The CA creation page only lists the sizes the selected vault can hold. A P-521 CA signs with ECDSA and SHA-512. Certificates issued by the platform with a server-generated key use RSA-2048, RSA-3072, RSA-4096, EC-P256 or EC-P384; RSA-8192 and EC-P521 are CA key sizes only.
Post-quantum and hybrid CAs are vault-signed (their keys are vault-resident); classical CAs are vault-signed when created with a vault, otherwise they sign with a software key.
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 + RFC 9773 (ARI) | 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 |
| Windows autoenrollment | MS-XCEP / MS-WSTEP | Domain-joined Windows users and computers through Group Policy (preview) |
| Intune | SCEP / PKCS | Microsoft Intune-managed devices (preview) |
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.
On top of permissions, PKI governance binds M-of-N quorum approval and access policies (user, IP, country, time) to CAs and certificate templates.
Explore by module
CA Management
Root, intermediate and external CAs, and the full CA lifecycle
CA Key Protection
CA keys in an HSM, cloud KMS or MPC cluster
Issuers
External, cloud and internal CA connectors
Enrollment Protocols
ACME, EST, SCEP, CMP, cert-manager, KMIP
Windows Autoenrollment
Group Policy enrollment and renewal for Windows
Intune & MDM
SCEP and PKCS delivery to managed devices
Short-Lived Certificates
ACME ARI and 47-day readiness
Device Identity
EST and CMP provisioning for device fleets
Deployment
Push certificates to F5, Fortinet, Azure, Entra and more
Renewal & Alerts
Automatic renewal, redeploy and expiry alerts
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
Code Signing
SignTool, JAR, Git and cosign with vault keys
PKI Governance
M-of-N quorum and access policies on CAs
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)