Getting Started
Roles and permissions, supported algorithms and certificate types, and the certificate lifecycle in DuoKey PKI.
Overview
Getting started with DuoKey PKI means understanding three things: the roles and permissions that gate PKI actions, the algorithms and certificate types the platform supports, and the request-to-issuance lifecycle. This page covers all three; the Create a Certificate walkthrough then takes you through issuing your first certificate.
Prerequisites
- Active DuoKey Cockpit account
- The relevant PKI permissions (or an admin role)
- A vault configured for CA signing keys
- A CA to issue from (create one, or connect an external issuer)
Roles and permissions
PKI actions are authorized by fine-grained, tenant-scoped role-based permissions. A typical separation of duties splits responsibilities like this:
| Responsibility | Typical role |
|---|---|
| Request a certificate | Certificate requester |
| Approve / reject requests | Certificate approver |
| Manage certificate authorities | CA administrator |
| Revoke certificates | Certificate operator |
| Manage revocation data (CRL) | CA administrator |
| Read-only visibility | Auditor / viewer |
Different operations may need different permissions. If you hit a permission error, check which PKI permission the action requires and ask your administrator to grant it.
Required information
Before creating a certificate, gather the subject details:
| Field | Example | Description |
|---|---|---|
| Common Name (CN) | www.example.com | Primary identity (FQDN for TLS; may be a wildcard) |
| Organization (O) | Acme Corporation | Legal organization name |
| Organizational Unit (OU) | IT | Optional department |
| Country (C) | US, CH, GB | Two-letter country code |
| State/Province (ST) | Vaud | Full state or province name |
| City/Locality (L) | Lausanne | City name |
| Subject Alternative Names | api.example.com, 10.0.0.1 | Extra DNS / IP / email / URI identities |
Certificate types
The platform issues certificates for distinct purposes, each mapped to the appropriate extended key usage:
| Type | Purpose | Extended key usage |
|---|---|---|
| Server (TLS/SSL) | HTTPS and TLS-terminating services | ServerAuth |
| Client (mTLS) | Mutual-TLS client authentication | ClientAuth |
| Code signing | Signing software and artifacts | CodeSigning |
| Email (S/MIME) | Signing and encrypting email | EmailProtection |
| CA | Root and intermediate signing certificates | Certificate signing |
Subject alternative names can be DNS, IP, email or URI. To secure all first-level subdomains, use a wildcard common name such as *.example.com, optionally with additional SAN entries for specific hosts.
Key algorithms
Choose the key algorithm at request time. Classical and post-quantum options are available:
| Algorithm | Category | When to use |
|---|---|---|
RSA-2048 | Classical (RSA) | General-purpose, widely compatible |
RSA-4096 | Classical (RSA) | Higher-assurance RSA |
EC-P256 | Classical (ECC) | Efficient default for modern TLS |
EC-P384 | Classical (ECC) | Higher-assurance ECC |
ML-DSA-44 / 65 / 87 | Post-quantum (FIPS 204) | Quantum-resistant signatures |
SLH-DSA-128F / 128S | Post-quantum (FIPS 205) | Hash-based quantum-resistant signatures |
ML-DSA-65 + ECDSA-P256 | Hybrid / composite | Quantum-resistant plus classical assurance in one certificate |
There is no RSA-3072, EC-P521 or 8192-bit RSA option. Unrecognized algorithm choices fall back to EC-P256, so select from the list above explicitly. Post-quantum and hybrid keys are vault-resident (the signing CA must be vault-backed).
The certificate lifecycle
Create request
A requester submits a certificate request with the subject details, type, key algorithm and SANs. The request enters the Pending state.
Approve or reject
An approver reviews the request and approves or rejects it. Comments are recorded for the audit trail.
Issue
On issuance the CA signs the certificate. For managed keys the key pair is generated and held in the vault; for a CSR-supplied key, the submitted public key is certified. The request moves to Issued.
Operate
The active certificate can be viewed, exported (public parts), deployed to a target, and monitored via OCSP / CRL.
Renew or revoke
Renew before expiry (re-issue from the request or via the issuer), or revoke with an RFC 5280 reason — which is then reflected in the CA's CRL and OCSP responses.
Beyond the manual request workflow, devices and workloads can enrol automatically over ACME, EST, SCEP, CMP, Kubernetes cert-manager or KMIP — see the Overview.