SSH Certificate Authority
Vault-backed SSH certificate issuance — short-lived host and user certificates that replace static host keys and authorized_keys files.
What is an SSH Certificate Authority?
An SSH Certificate Authority (SSH CA) is a vault-backed signing key that issues short-lived, cryptographically signed SSH certificates instead of relying on static, long-lived key files. The CA's private key never leaves the vault — every certificate is signed in place by the vault backend, the same way DuoKey's other key-management workflows keep signing material out of reach of the application layer.
The signing key never leaves the vault; short-lived certificates replace the static files sshd used to trust.
An SSH CA replaces two of SSH's oldest trust problems:
Static host keys
Normally a client trusts a server's host key on first connection (trust-on-first-use) and silently remembers it in known_hosts. A host certificate lets a server present a certificate signed by a CA the client already trusts, so there is nothing to blindly accept and nothing stale to remember.
Static authorized_keys files
Normally each server keeps its own list of public keys allowed to log in, which has to be distributed and pruned by hand. A user certificate lets sshd trust any key signed by the CA for a given set of usernames, so there is no per-server file to maintain.
SSH Certificate Authority is its own item in the Cockpit navigation, not an entry in the Apps catalog. It sits behind its own feature flag and permission subtree, and is disabled by default until your edition grants it.
Certificate types
An SSH CA can issue two kinds of certificate. Both are short-lived by design — a certificate's validity window is capped at the issuing CA's configured maximum.
| Type | Certifies | Replaces | Principals field means |
|---|---|---|---|
| Host | A server's host key, presented to connecting clients | Static host keys trusted via `known_hosts` | The hostnames / IP addresses the certificate is valid for |
| User | A person's or service's key, presented to a server | Static entries in `authorized_keys` | The server-side usernames the certificate authenticates as |
An SSH CA's signing key can use EC P-256, EC P-384, RSA 2048 or RSA 4096 — chosen once when the CA is created. The CA's public key is exposed as a standard OpenSSH public-key line so it can be dropped straight into sshd_config's TrustedUserCAKeys (for user certificates) or a client's known_hosts @cert-authority line (for host certificates).
Creating an SSH CA and issuing certificates
Create the CA
From the SSH Certificate Authority section of the Cockpit, create a CA: give it a name and optional description, choose the vault backend that will hold its signing key, pick a key algorithm, and set the maximum certificate lifetime (TTL) any certificate it issues may request. The Cockpit generates the signing key in the chosen vault and returns the CA's public key line and fingerprint — the private key itself is never exposed.
Issue a host certificate
Submit the server's OpenSSH public key, the hostnames/IP addresses it should be valid for (its principals), and an optional TTL (capped at the CA's maximum). The Cockpit returns a signed certificate line to install alongside the server's host key so sshd presents it to clients.
Issue a user certificate
Submit the user's or service's OpenSSH public key and the server-side usernames it should authenticate as (its principals). The returned certificate line is used in place of an authorized_keys entry — the target sshd only needs to trust the CA, not track individual keys.
Revoke when needed
If a key is compromised or an issued certificate should no longer be trusted, revoke it from the Cockpit with an optional reason. A revoked certificate is excluded from future connections that check revocation (see below).
The five steps below are what actually happens from issuance through to a connection trusting (or, later, rejecting) the certificate:
Only the signature crosses into the vault boundary — the certificate itself travels as an ordinary OpenSSH public-key line.
A certificate issued without an explicit TTL is valid for the issuing CA's configured maximum TTL — which itself defaults to one hour when a CA is created without setting one. Favor short TTLs (and a short CA maximum) and re-issuance over long-lived certificates — a certificate that expires on its own needs no revocation plumbing.
Every certificate carries a key id (a label, defaulting to the first principal if not set) and one or more principals — the hostnames/IPs for a host certificate, or the usernames for a user certificate. At least one principal is required.
CA lifecycle: rotate and deactivate
| Status | Meaning |
|---|---|
| Active | The CA can issue new certificates. |
| Rotated | The CA has been superseded by a newly generated CA key; it can no longer issue certificates. |
| Deactivated | The CA has been manually taken out of service; it can no longer issue certificates. |
Rotating a CA generates a new signing key and marks the old CA Rotated. Certificates already issued under the old key remain individually valid — each certificate embeds the CA public key it was signed under, so verification does not depend on the CA's current status. However, sshd's trusted-CA configuration (known_hosts @cert-authority lines, TrustedUserCAKeys) must be updated to the new public key, or newly presented certificates from the rotated CA will not be trusted for new connections.
Deactivating a CA stops it from issuing further certificates without generating a replacement — use it when a CA should be retired without immediately rotating in a new one.
Revocation and the revoked-keys file
Revoking a certificate marks it Revoked with an optional reason, but revocation only has effect once sshd is told to check it. The Cockpit publishes a revoked-keys file — a plain, one-public-key-per-line list of every currently revoked certificate's subject key for a given CA — that sshd_config's RevokedKeys directive can point at directly.
# Point sshd at the CA's public key for certificate-based trust,
# and at the revoked-keys file for revocation checking.
TrustedUserCAKeys /etc/ssh/ca.pub
RevokedKeys /etc/ssh/revoked_keys
The revoked-keys file is a plain text list (one OpenSSH public-key line per revoked certificate, sorted and de-duplicated) rather than the binary OpenSSH KRL format. Re-fetch it after each revocation and refresh the copy sshd reads.
PKCS#11 enrollment for live signing
Beyond issuing certificates on demand from the Cockpit console, an SSH CA can be enrolled so an on-prem sshd or ssh-agent integration can request certificate signing live, the same pattern used by DuoKey's other PKCS#11 integrations (see Oracle TDE's pkcs11.toml).
Enroll the CA for live signing
From the CA's detail page, enroll it for PKCS#11 access. The Cockpit generates a pkcs11.toml-style configuration file, pointing at this CA's own live-signing endpoint, and a bearer access token shown once.
Install the configuration
Save the generated configuration alongside your PKCS#11-aware SSH tooling. The on-prem client authenticates every signing request with the bearer token in an Authorization header — the token is never embedded in the endpoint URL.
Sign live
Once enrolled, the client can look up the CA's public key and request signatures over certificate data through the PKCS#11 bridge, without an operator manually issuing each certificate from the console.
The bearer token — never the CA id in the URL — is what authenticates every live signing request.
The live PKCS#11 bridge exposes only the operations an SSH CA needs — looking up the CA key and signing — never encrypt, decrypt, wrap or unwrap. The CA's key material stays in the vault at all times.
Live PKCS#11 signing is gated by its own entitlement on top of the base SSH Certificate Authority feature, and enrollment requires its own permission. The entitlement is re-checked on every signing call, not just at enrollment time — so if your edition no longer includes it, live signing stops immediately even for an already-enrolled client.
The bearer token returned at enrollment is a credential, not the CA id in the URL. Store the generated configuration file with restricted permissions, and re-enroll (which issues a fresh token) if it is ever exposed.
Permissions and entitlements
SSH Certificate Authority has its own permission subtree, separate from every other Cockpit module, plus a feature flag that gates the module as a whole and a second flag that separately gates the live PKCS#11 bridge:
| Area | Governs |
|---|---|
| CA management | Create, view, rotate, deactivate and delete SSH CAs |
| Certificates | View certificates, issue host certificates, issue user certificates, revoke certificates |
| PKCS#11 enrollment | Enroll a CA for live signing — gated separately from the rest of the module |
As with the rest of the platform, whether the SSH Certificate Authority module — and the live PKCS#11 bridge within it — is available at all is decided by your edition's feature entitlements; whether this user may use it is decided by permissions. A call must pass both. See Features and Access Policies.