SSH User Certificates: Check Principals, Validity and Trust

An SSH user certificate can be correctly signed and still be rejected by a server. The signing authority must be trusted, the offered private key must match the certified public key, the certificate must be valid and the requested account must be authorized for its principals and restrictions.

The OpenSSH ssh-keygen manual describes user and host certificates, their principals and options. OpenSSH certificates use a different format from the X.509 certificates common in TLS. Do not troubleshoot an SSH user-certificate problem by changing a website’s certificate chain.

Confirm which authentication object is involved

First distinguish user authentication from server identity verification. A user certificate authenticates a user to a server. A host certificate helps a client verify a server. They are not interchangeable even when both are signed by an organizational authority.

Record the intended remote account, hostname and certificate path. Check whether the client is offering a raw key, a certificate or a different identity loaded in an agent. A file existing on disk does not prove it was selected for the connection.

Use a single authorized test connection and bounded diagnostic logging. Avoid repeatedly attempting authentication across a fleet while the basic identity selection remains unclear.

Inspect the public certificate safely

The supported inspection command is:

ssh-keygen -L -f /path/to/user_key-cert.pub

Replace the path with the actual public certificate file. Inspect its type, signing authority, key identifier, principals, validity and critical options. These details can still be operationally sensitive, so sanitize them before sharing a report.

Do not expose the private key to diagnose the certificate. You can compare public-key fingerprints using the implementation’s supported tools without pasting secret key material into a ticket or chat.

Check the principal against the server policy

A principal is an identity name carried by the certificate. It is not necessarily identical to the local Unix account name in every deployment. The server’s configured authorization mapping determines which principals may access which accounts.

For an invented example, a certificate containing deploy-staging may be valid but not authorized for the production-admin account. Changing the certificate’s display label would not establish permission.

Ask the identity or server owner to compare the intended mapping with the actual certificate. Do not broaden the accepted principal list merely to make one failed test pass. A mismatch may be a correct denial rather than a broken system.

Verify time and key matching

Compare the validity interval with the relevant system clocks. A recently issued certificate can appear not yet valid to a machine with an incorrect clock. An expired certificate needs the approved renewal flow, not an indefinite extension added during troubleshooting.

Confirm that the private key selected by the client corresponds to the public key in the certificate. A certificate from one generated key pair combined with another private key will not become valid by renaming files.

Keep renewal atomic from the application’s perspective. If automation updates a certificate path while leaving an old key selected elsewhere, the filesystem can look current while the client continues using a mismatched identity.

Review authority trust and restrictions

On the server, confirm the approved signing authority and the applicable account policy using authorized configuration inspection. Trusting a different authority is a security change, not a harmless formatting correction.

Inspect critical options such as source-address or forced-command restrictions where present. A certificate intended for a specific automation task may correctly refuse an interactive shell or a connection from another network.

Do not remove restrictions to test a theory on production. Reproduce with an explicitly approved test identity and environment, or have the responsible administrator validate the policy through the normal change process.

Correlate client and server evidence

The client can show what it offered; the server can explain what it rejected. Correlate one attempt using time and a safe identifier. Avoid collecting entire unrelated authentication logs or exposing other users’ identities.

Classify the failure layer: identity not offered, untrusted authority, invalid interval, principal mismatch, unsupported option or later account/session restriction. These categories lead to different owners and fixes.

A successful certificate check does not guarantee a permitted session. Shell configuration, account status, command policy and other controls can still deny the requested operation after authentication.

Test renewal and revocation behavior

After the immediate issue is resolved, test the approved lifecycle with a disposable identity. Confirm that a renewed certificate is selected and that an intentionally invalid or revoked test identity is rejected under the documented policy.

Record the accepted combination without copying secrets: authority identifier, principal mapping, key fingerprint, validity policy and client selection method. That makes the next rejection diagnosable without weakening the access boundary.

Conclusion

Treat an SSH certificate as one component of an authorization chain. Verify the offered key, trusted authority, principal mapping, time interval and restrictions before changing security policy.