SSH Certificate Authorities: Past the authorized_keys Sprawl

The default SSH model is a flat list of trusted keys. Each server keeps an authorized_keys file naming every public key allowed to log in as a given user. Add an engineer and you push their key to every server they need. Remove an engineer and you have to find and delete their key from every server, which means the moment your inventory is wrong, a former employee still has access somewhere you forgot about. There is no central authority and no expiry. A key added in 2019 is still valid today unless someone remembered to take it out.

SSH certificates replace the list of trusted keys with a single trusted signer. Instead of asking "is this exact key in my allow list," the server asks "is this key carrying a valid signature from the certificate authority I trust." That one change moves the entire access decision off the individual servers and onto a CA you control.

What an SSH certificate actually is

An SSH certificate is a public key plus a set of signed claims about it. The CA, which is itself just an SSH key pair kept somewhere well protected, signs a user's public key together with metadata. That metadata is the interesting part:

• Principals are the identities the certificate is valid for: the usernames or role names the holder may log in as.
• A validity window sets a start and end time. After the end time the certificate is simply dead, with no action required on any server.
• A key ID is a label that lands in the server's auth logs, so every login is attributable to a person or a request rather than to an anonymous key fingerprint.
• Critical options and extensions can pin the certificate to a source IP range, force a single command, or disable port forwarding and agent forwarding.
• A serial number gives you a precise handle for revocation.

Issuing one looks like this. The CA holder signs a user's public key, naming the principals, validity, and a key ID for the logs:

ssh-keygen -s ca_key -I "jordan@2026-06-24" -n deploy,readonly -V +8h -z 42 jordan_key.pub

That produces a certificate valid for eight hours, usable to log in as the deploy or readonly principal, tagged in the logs as jordan@2026-06-24, with serial 42. The user presents the certificate alongside their private key, and the server checks the CA signature instead of consulting a list.

The host side: killing the trust-on-first-use prompt

Certificates run in both directions, and the host direction fixes a problem most people have trained themselves to ignore. The first time you connect to a server, SSH shows you a fingerprint and asks whether you trust it. Almost nobody verifies that fingerprint out of band. They type yes. That moment is a genuine window for a trust-on-first-use attacker to insert themselves, and the prompt has trained a generation of operators to click through it.

Host certificates remove the prompt. You sign each server's host key with a host CA, and clients are told once to trust that CA for a domain. After that, connecting to any server whose host key carries a valid CA signature is silent and verified. No fingerprint to eyeball, no first-use gamble. A client trusts the host CA with a single line in known_hosts:

@cert-authority *.example.com ssh-ed25519 AAAA...host_ca_public_key

Revocation that actually works

The strongest argument for SSH certificates is what happens when access needs to end. In the authorized_keys model, revocation means visiting every server and deleting a key, and hoping your server inventory is complete. Certificates give you two clean options.

The first is to keep validity windows short. If certificates live for a few hours, revocation is mostly automatic: a compromised or stale certificate expires on its own, and the person simply does not get a new one. This is why short-lived certificates have become the dominant pattern. You pair the CA with an identity provider, the user authenticates, and the CA mints a certificate good for the length of a work session. There is nothing long-lived to steal and nothing to clean up.

The second is a key revocation list (KRL), a compact signed file that names revoked certificates by serial number or key ID. Servers consult it on every login through the RevokedKeys directive, so you can kill a specific certificate immediately without waiting for it to expire. Short lifetimes and a KRL together cover both the routine case and the emergency.

Where certificates are the right call, and where they are not

Situation	Better fit
One personal server, one key	Plain authorized_keys. A CA is overhead you do not need.
A fleet of servers and more than a few people	User and host certificates. The revocation and audit story pays for itself.
Contractors or time-boxed access	Short-lived certificates tied to an identity provider.
You cannot protect the CA private key well	Reconsider. A leaked CA key signs valid access to everything that trusts it.

That last row is the real cost. A certificate model concentrates trust in the CA private key. If that key leaks, an attacker can mint valid credentials for every server in the fleet, which is a far worse outcome than a single stolen user key. The CA belongs in a hardware security module or an offline signer with strict access controls, and the host CA and user CA should be separate so a compromise of one does not hand over the other.

The pattern here is the same one that runs through good security engineering generally, and the same instinct behind how we think about key management at Haven: prefer signed, expiring, attributable credentials over a static list of long-lived secrets that nobody is responsible for cleaning up. The flat allow list feels simpler until the day you need to prove who has access and discover that no single place knows the answer.