Create a Certificate
Request, approve, issue and deploy a certificate under a DuoKey certificate authority.
Overview
Issuing a certificate under a DuoKey CA follows a request-and-approval workflow with an optional deployment step:
| Phase | Who | Result |
|---|---|---|
| 1 — Request | Requester | A pending certificate request |
| 2 — Approve | Approver | An approved request, ready to issue |
| 3 — Issue | Issuer / CA operator | A signed, active certificate |
| 4 — Deploy (optional) | Operator | Certificate installed on a target, with rollback available |
Prerequisites
- A certificate authority to issue from (or a connected external issuer)
- Permission to request certificates
- A vault selected for managed key storage
- The subject details and SANs ready
Phase 1 — Create the request
Open the certificate area
In the Cockpit, go to the PKI / Certificates area and start a new certificate request under the CA you want to issue from.
Enter subject details
Provide the subject and any subject alternative names:
| Field | Required | Example |
|---|---|---|
| Certificate name | Yes | prod-web-server |
| Common Name (CN) | Yes | www.example.com or *.example.com |
| Organization (O) | Yes | Acme Corporation |
| Organizational Unit (OU) | No | IT |
| Country (C) | Yes | CH |
| State / Locality (ST / L) | Yes | Vaud / Lausanne |
| Subject Alternative Names | No | api.example.com, 10.0.0.1 |
For a wildcard certificate, set the common name to *.example.com and add specific hosts as SAN entries where needed.
Choose the certificate type
Pick the purpose — Server (TLS), Client (mTLS), Code signing or Email (S/MIME). The type sets the appropriate extended key usage (for a server certificate, ServerAuth).
Select the key algorithm
| Algorithm | Category |
|---|---|
RSA-2048 / RSA-4096 | Classical (RSA) |
EC-P256 / EC-P384 | Classical (ECC) |
ML-DSA-44 / 65 / 87 | Post-quantum (FIPS 204) |
SLH-DSA-128F / 128S | Post-quantum (FIPS 205) |
ML-DSA-65 + ECDSA-P256 | Hybrid / composite |
There is no RSA-3072, EC-P521 or 8192-bit option. Post-quantum and hybrid keys require a vault-backed issuing CA.
Confirm key usage and validity
A TLS server certificate uses Digital Signature + Key Encipherment. Set the validity period in days (1 year / 365 days is a common choice for TLS).
Select the vault and access
Choose the vault that will hold the managed key — for managed leaf certificates the key is currently generated and held in the platform's software vault — and assign the roles allowed to manage this certificate.
Submit
Review and submit. The request appears in Pending requests.
Phase 2 — Approve the request
Open pending requests
Go to Pending requests. Each row shows the certificate name, common name, requester, date and status.
Review and decide
Open the request, verify the subject, SANs, type and algorithm, then approve or reject. A comment is recorded in the audit trail.
Separation of duties is enforced by permissions: approving a request is a distinct permission from requesting one, so the same person need not (and often cannot) do both.
Phase 3 — Issue the certificate
Issue the approved request
From the approved request, choose Issue. The CA signs the certificate; a managed key pair is created in the vault (or your supplied CSR public key is certified).
Certificate is active
The issued certificate appears in the certificates list, ready to view, export or deploy.
By default, exporting a certificate returns public certificate material only. With the export permission, a certificate's private key can also be downloaded (PEM or inside a PKCS#12 bundle) if it was marked exportable at issuance.
Post-issuance operations
View and export
Open a certificate to see its subject, SANs, validity, key usage, serial number and fingerprints, and to download it. Typical export formats are PEM and DER for the certificate and chain, plus a PKCS#12 bundle. Downloading the private key itself (as a standalone PEM, an encrypted PEM, or inside the PKCS#12 bundle) requires a separate export permission and only works for a key that was marked exportable when it was created.
Deploy to a target
Rather than exporting and installing by hand, push the certificate directly to where it terminates TLS. Deployment jobs validate the result and can be rolled back.
| Target | Notes |
|---|---|
| F5 BIG-IP | Deploy cert+key or cert-only via iControl REST |
| Fortinet FortiGate | Deploy with rollback |
| Azure App Service | Bind to an app service |
| Entra ID | App Proxy / App Registration |
| Apache · Nginx · IIS · JKS · Windows CAPI | Generic deploy targets |
For servers you manage directly, reference the deployed material in the web-server configuration:
ssl_certificate /path/to/certificate.pem;
ssl_certificate_key /path/to/private-key.pem; # or an HSM/PKCS#11-backed keyRenew and revoke
- Renew before expiry — re-issue from the request, or renew through the external issuer that issued it.
- Revoke with an RFC 5280 reason. The revocation is published in the CA's CRL and reflected by its OCSP responder.