OpenSSH Host Certificates Replace Per-Host Key Pinning
SSH host authentication protects a client from silently accepting a different server key for a name it intended to reach. The familiar known_hosts model can pin a key directly to a host. That model is simple, but operating it across a large fleet creates a distribution problem: new hosts need trusted entries, planned key rotation changes pins, and stale entries can survive after infrastructure changes.
OpenSSH host certificates move that trust decision one level up. A client can trust a host certificate authority (CA), while servers present host certificates signed by that CA. The client still validates a host key, but acceptance depends on the certificate signature, host identity, validity interval, and certificate semantics rather than a separate long-lived pin for every server.
A host certificate signs a public host key
An OpenSSH certificate is not an X.509 certificate. It uses the OpenSSH certificate format and carries a public key plus signed metadata. For host authentication, the certificate is marked as a host certificate and can contain one or more valid principals representing host identities.
The CA signs the host public key; it does not need the host private key. The server keeps its private host key and presents the corresponding certificate during SSH key exchange. A client configured to trust the issuing host CA can validate the certificate signature against that CA key.
This separation matters operationally. The CA key establishes the trust anchor, while each server retains its own host private key. A CA therefore does not need copies of server private keys merely to issue host certificates.
Principals bind a certificate to host identity
A valid CA signature alone is not sufficient for a host certificate to represent every hostname. Host certificates carry principals, and client verification compares the destination identity with the certificate’s permitted names under OpenSSH’s host-certificate rules.
A certificate issued for db01.example.net should not be treated as authorization for an unrelated host merely because both certificates could chain to the same trusted CA. The signed principal set narrows the identities for which the certificate is acceptable.
This makes issuance policy part of the security boundary. Automation that requests or signs certificates needs controlled input for principal names. Broad principal sets increase the set of names for which a compromised host key and its certificate can be accepted.
@cert-authority records establish host CA trust
OpenSSH clients can place an @cert-authority marker in known_hosts. The pattern on that record defines the hostnames for which the listed CA key is trusted to certify host keys.
Conceptually, the trust relationship looks like this:
known_hosts pattern
|
@cert-authority -> host CA public key
|
+-> verifies presented host certificate
|
+-> principal matches destinationThe hostname pattern and the certificate principals serve different roles. The known_hosts pattern scopes where the client accepts a CA as an authority. The certificate’s principals scope which identities the CA authorized for that particular host key. Both checks constrain acceptance.
A global CA entry should therefore be intentional. Trusting one CA for a broad namespace gives that CA authority to issue host certificates within that configured scope.
Validity intervals turn rotation into an issuance problem
OpenSSH certificates contain validity bounds. Clients reject certificates outside the applicable interval when certificate validation is enforced. Shorter certificate lifetimes can reduce dependence on distributing replacement host-key pins during routine rotation, because a newly issued certificate can bind a replacement key to the same host identity.
That does not eliminate lifecycle work. Issuance must happen before the current certificate expires, servers must load the intended certificate and matching private key, and clocks need to be sufficiently aligned for validity checks. A certificate that is not yet valid or has expired can make an otherwise healthy SSH service fail host authentication.
Certificate lifetime also does not revoke a compromised key immediately. Expiration places a time bound on ordinary certificate acceptance, but incident response may require separate revocation controls and replacement of affected credentials.
Revocation remains a separate control
OpenSSH supports revoked-key handling through mechanisms such as a revoked keys file configured by the client. Certificate deployment should not assume that short validity alone covers every compromise window.
The relevant object also matters. An operator may need to reject a specific host key, a specific certificate, or trust rooted in a CA, depending on the incident. Removing or replacing a CA trust anchor has a much wider effect than replacing one server certificate.
That asymmetry is a reason to protect the host CA private key more strongly than an ordinary server host key. A compromised CA key can enable unauthorized host certificates wherever clients trust that CA and the resulting certificate satisfies the remaining checks.
CA scope limits blast radius
One host CA for every environment is easy to describe but creates a large trust domain. Separate CAs or narrowly scoped client trust records can reduce the authority attached to one signing key.
For example, production and development fleets can use distinct trust anchors. Client configuration can also limit a CA to an intended hostname namespace instead of accepting it for arbitrary destinations. The right boundary depends on administrative ownership and failure containment, not merely on certificate issuance convenience.
CA signing access deserves the same discipline. An automated issuer should authenticate requests, constrain permitted principals, limit certificate lifetime according to policy, and keep an auditable issuance path. Host certificates simplify client trust distribution; they do not make unrestricted signing safe.
Host certificates do not replace user authentication
Host certificates authenticate the server side of an SSH connection. They do not, by themselves, authorize a person or workload to log in. User authentication remains a separate step and can use passwords, public keys, user certificates, hardware-backed credentials, or other mechanisms supported by the deployment.
OpenSSH also supports user certificates, but host and user certificates have different certificate types and policy roles. Treating a trusted host CA as a user CA would collapse two distinct trust decisions and should not be assumed from the presence of certificate support on both sides.
The trust anchor becomes the durable client configuration
Per-host pinning makes each host key a durable client trust record. Host certificates instead let the CA public key and its hostname scope become the durable configuration, while individual host certificates can rotate underneath that boundary.
The security trade is precise. Fleet changes become easier to operate because clients do not need a fresh pin for every legitimate host-key replacement. In exchange, the CA private key and issuance policy become higher-value controls. Tight principal assignment, bounded validity, scoped CA trust, protected signing keys, and explicit revocation procedures keep that centralization from becoming unrestricted authority.