SSH Certificates Shift Access Trust to a Signing Authority

Public-key SSH access often starts with a simple mapping: place a user’s public key in authorized_keys, keep the private key with the user, and let the server accept possession of the matching private key. The model is direct and effective, but its administrative cost rises as people and hosts multiply. Every host can become another place where access state must be added, audited, and removed.

OpenSSH certificates change that distribution model. A certificate authority signs an SSH public key and attaches identity and policy metadata. A server configured to trust that CA can accept certificates issued by it without storing each certified user key locally. Trust moves from a large set of individual keys toward a smaller set of signing authorities plus server-side policy.

This is not the X.509 certificate system used by HTTPS. OpenSSH defines its own certificate format and validation rules. The shared term certificate describes a signed binding, not compatibility between the two formats.

A certificate carries more than a public key

An OpenSSH user certificate contains the certified public key, a serial number, a certificate type, an identifier, valid principals, a validity interval, critical options, extensions, and the CA signature. These fields let the verifier evaluate more than possession of a private key.

Principals are central to authorization. A certificate can name identities or roles that the server may map to an account. The server still controls which principals are acceptable; a valid CA signature alone does not grant arbitrary account access.

Time bounds add another useful constraint. A CA can issue a certificate that is valid only for a limited interval. The underlying key pair may exist much longer, but the signed authorization expires at the certificate boundary. Short validity reduces dependence on removing long-lived user keys from many hosts after routine access ends.

Critical options and extensions carry additional behavior. OpenSSH distinguishes options that a verifier must process from extensions that advertise permitted capabilities. This distinction matters operationally: certificate issuance policy can restrict forwarding or other session behavior, but administrators must verify the exact OpenSSH semantics they rely on rather than treating metadata as free-form labels.

The server trusts the CA, then applies account policy

For user authentication, sshd can be configured with TrustedUserCAKeys pointing to public keys for trusted user CAs. When a client presents a user certificate, the server verifies the CA signature and certificate constraints, then applies its authorization rules.

A common design maps certificate principals through AuthorizedPrincipalsFile or AuthorizedPrincipalsCommand. This keeps the CA responsible for signing asserted principals while leaving the server or host fleet responsible for deciding which principals may enter a particular account.

That separation avoids a dangerous interpretation of CA trust. A signing authority should not automatically mean that every certificate it issues can log in as every local user. Principal mapping provides a second policy boundary between identity issuance and account authorization.

The same separation supports role-oriented access. A certificate might carry a principal such as production-readonly, while selected accounts accept that principal. The exact role model remains an operational policy choice; SSH certificates provide signed input to that policy rather than a complete authorization system.

Short validity changes revocation pressure

Traditional authorized_keys deployments often treat removal as the main revocation mechanism. With certificates, short validity intervals can make routine access naturally expire. A user can receive a new certificate when current access policy still permits it, while an old certificate becomes unusable after its validity interval.

Expiration is not instant revocation. A certificate remains acceptable until its validity ends unless another control rejects it. OpenSSH supports key revocation lists through RevokedKeys, which can be used to reject specified keys or certificates. Environments that require immediate response need a revocation process sized to that requirement rather than relying only on short lifetimes.

The CA private key deserves stronger protection than an ordinary user key because compromise changes the scale of impact. An attacker who can issue accepted certificates may create identities and principals within the authority recognized by servers. CA key storage, signing access, audit records, rotation, and recovery therefore belong to the core security design.

Short-lived certificates reduce stale authorization, but they do not compensate for an uncontrolled signing service. The issuance path becomes a high-value enforcement point.

Host certificates address a different side of SSH

OpenSSH also supports host certificates. A host CA signs a server host key, and clients can trust that CA for designated hostnames or patterns. This can reduce the need to distribute every host key fingerprint individually while retaining cryptographic server authentication.

User and host certificates solve related but distinct distribution problems. User certificates help servers evaluate client identities. Host certificates help clients evaluate server identities. Mixing their CA keys or certificate types weakens administrative separation and can make policy harder to audit.

A host certificate does not remove hostname verification. The certificate carries principals for the host identities it represents, and the client checks the presented host against applicable trust configuration. CA trust is therefore combined with name constraints rather than replacing them.

Issuance policy becomes part of access control

Once certificates replace broad authorized_keys distribution, the signing workflow becomes the place where identity, requested principals, validity, and session constraints converge. That workflow may be manual or automated, but its authorization decision needs an explicit source of truth.

A signer should not accept arbitrary requested principals merely because a caller possesses a valid public key. The public key proves control of key material; it does not establish entitlement to root, a production role, or another privileged principal. The signing service must derive allowed claims from authenticated identity and access policy.

Audit data is also more useful when it records certificate serials, key identifiers, principals, validity intervals, and issuance decisions. These fields can connect a server authentication event to the specific authorization artifact that was issued, subject to the logging and retention rules of the environment.

Automation can make short certificate lifetimes practical, but availability becomes relevant. If users require fresh certificates frequently, an unavailable issuer can block new sessions after existing certificates expire. The service therefore needs a failure model that preserves security without turning emergency bypass keys into a permanent parallel access system.

Migration works best with explicit trust boundaries

A fleet does not need to switch every account at once. Certificate trust can be introduced for selected users or roles while existing key-based access remains for controlled exceptions. The important part is to keep each path visible. A forgotten authorized_keys entry can outlive the certificate policy and silently preserve access that operators assume has expired.

Inventory should therefore cover both certificate-based and direct-key authorization. Break-glass keys, automation accounts, and recovery paths need named owners and deliberate lifecycle rules. Certificate adoption simplifies key distribution only when legacy paths do not become an unaudited second system.

SSH certificates are most useful when their claim stays precise: a trusted authority signed a public key together with defined principals, time bounds, and options. Servers and clients still apply local policy, private keys still require protection, and the CA becomes infrastructure with concentrated security significance. Used with those boundaries intact, certificates replace repetitive key distribution with a smaller and more auditable trust relationship.