Key Points
- SSH Certificates include a public key and metadata, with user certificates authenticating users and host certificates verifying server identity.
- While SSH certificates secure SSH connections, SSL certificates manage security between web servers and clients.
- SecureW2's Managed Cloud PKI simplifies SSH & SSL certificate management, enhancing network security by handling key generation, distribution, and revocation.
Secure Shell (SSH) certificate authentication is how organizations such as Google, Netflix, and Uber manage server access at scale. If you are still relying on static SSH keys and `authorized keys` files, SSH certificates are a more secure, auditable, and operationally efficient alternative.
This guide covers:
- What an SSH certificate is and how it works
- Why SSH certificates outperform traditional SSH keys
- How to set up your own SSH certificate authority (CA)
- How managed PKI simplifies the entire process
What Is an SSH Certificate?
An SSH certificate pairs a standard SSH public key with signed metadata: the principal (who or what the certificate identifies), a validity period, optional constraints (like forced commands or source IP restrictions), and the certificate authority signature that ties it all together.
OpenSSH supports two certificate types:
- User certificates authenticate a person or service account connecting to a server. The server trusts the CA rather than maintaining individual `authorized keys` entries.
- Host certificates authenticate the server itself to the connecting client. This eliminates trust-on-first-use (TOFU) warnings — the “Are you sure you want to continue connecting?” prompt that most users blindly accept.
You can generate both types using `ssh-keygen` with the `-s` flag to sign a public key against a CA private key. The result is a `.pub` file replaced by a `-cert.pub` file containing the signed certificate.
A common question that arises is if SSH certificates are the same as X.509 certificates.
While SSH certificates and X.509 certificates (used in SSL/TLS (Secure Sockets Layer/Transport Layer Security)) both bind public keys to identities through a CA signature, they differ in scope
How SSH Certificates Differ from X.509 Certificates
X.509 certificates follow a standardized ASN.1 format, support certificate chains, and are used across web browsers, VPNs, Wi-Fi (802.1X), and application authentication.
SSH certificates use a simpler, OpenSSH-specific format designed exclusively for SSH connections. They do not support certificate chains — there is one CA, and it signs everything directly.
How SSH-Based Certificate Authentication Works
The authentication flow for SSH certificates follows a straightforward sequence:
- Key pair generation: The user or host generates a standard SSH key pair (RSA, ECDSA, or Ed25519) using `ssh-keygen`.
- Certificate signing: The user submits the public key to the SSH certificate authority. The CA signs it with its own private key, producing a certificate that includes the principal name, validity period, and any restrictions.
- Server configuration: The server is configured to trust the CA by adding the CA public key to `TrustedUserCAKeys` in `sshd_config`. For host certificates, clients add the CA public key to `known hosts` with a `@cert-authority` prefix.
- Connection: When the client connects, it presents its certificate. The server validates the CA signature, checks the principal against allowed users, and verifies that the certificate has not expired.
- Session established: If all checks pass, the encrypted session begins. No `authorized keys` lookup is needed.
This flow eliminates the biggest operational headache of traditional SSH key management: distributing and maintaining per-user public keys across every server.
The next section takes a closer look at how SSH certificates outperform SSH keys.
Why SSH Certificates Beat SSH Keys
Static SSH keys have been the default authentication method for decades, but they follow a decentralized trust model, making them difficult to scale and track.
SSH certificates adopt a centralized trust system and enable granular control.
The following comparison table shows how SSH certificates win over SSH keys:
| Feature | SSH Keys | SSH Certificates |
|---|---|---|
| Expiration | Keys never expire. A compromised key remains valid until manually removed. | Certificates expire automatically. Short-lived certificates limit the impact of compromise. |
| Access Control | Access is granted by adding public keys to authorized keys on each server. | Access is centrally managed. Servers trust the CA, not individual keys. |
| Onboarding/Offboarding | Adding or removing users requires updating every server. | Access is revoked by stopping certificate issuance. Existing certificates expire automatically. |
| Auditing | Limited visibility into which keys have access to which servers. | Certificates include metadata (principal, validity, serial number) for logging and auditing. |
| TOFU Risk | Users must trust unknown host keys on first connection (TOFU). | Host certificates eliminate TOFU by verifying servers against a trusted CA. |
| Scalability | Difficult to manage at scale across many users and servers. | Easily scales to thousands of users and hosts with centralized management. |
The shift from SSH keys to SSH certificates is the same pattern driving enterprise adoption of certificate-based authentication for Wi-Fi networks, VPN, and web applications: replace shared or static credentials with short-lived, identity-bound, centrally managed certificates.
How to Set Up an SSH Certificate Authority
Setting up a basic SSH CA with OpenSSH involves four steps:
1. Generate the CA Key Pair
A CA key pair includes a private key and a public key that are related mathematically.
You can use a tool, such as ssh-keygen to create the CA key pair. Use separate keys for user and host signing.
Experts recommend Ed25519 for its speed and security.
2. Sign a User Certificate
This step involves signing the user key to generate a certificate valid for 8 hours (`-V +8h`), bound to principal `jane`, and identified as `jane.doe@company.com`.
3. Configure the Server to Trust the CA
Configure the server to trust the CA by adding the public key reference in the SSH configuration file.
The server now accepts any user certificate signed by this CA without needing `authorized keys`.
4. Sign a Host Certificate
This step involves using your CA’s private key to approve the SSH public key by attaching details, such as hostname and validity period.
Signing the host certificate ensures the systems trust the server automatically, eliminating TOFU warnings for any host in `*.company.com` signed by the CA.
The Operational Challenge
A manual SSH CA works for small teams. But as the organization grows, the CA private key becomes a high-value target, certificate issuance needs automation, and expiration policies need enforcement.
This is where managed PKI comes in, enabling PKI authentication using digital certificates instead of passwords.
SSH Certificate vs. SSL/TLS Certificate
| Feature | SSH Certificate | SSL/TLS Certificate |
|---|---|---|
| Format | OpenSSH-specific | X.509 (ASN.1) |
| Issued by | SSH certificate authority | Public or private certificate authority |
| Use case | Server access (remote shell, file transfer) | Web traffic, VPN, Wi-Fi, application authentication |
| Chain of trust | Single CA, no intermediate certificates | Supports full certificate chains |
| Expiration | Configurable (minutes to years) | Typically 90 days to 1 year |
| Revocation | KRL (Key Revocation List) | CRL or OCSP |
SSH does not require an SSL/TLS certificate. The two protocols serve different authentication contexts. That said, many organizations manage both SSH and X.509 certificates through a single PKI platform to centralize certificate lifecycle management across all use cases.
Managed PKI for SSH Certificate Authentication
Running your own SSH CA introduces the same challenges as any PKI deployment:
- Managing certificate lifecycles
- Automating workflows
- Securing the keys
- Maintaining detailed audits
For organizations that already manage X.509 certificates for Wi-Fi (802.1X), VPN, and web applications, adding SSH certificates to a managed PKI platform consolidates operations.
SecureW2 JoinNow Dynamic PKI provides managed certificate authority infrastructure that handles the full certificate lifecycle. It handles generation, signing, distribution, renewal, and revocation across SSH, Wi-Fi, VPN, and application authentication.
Instead of maintaining a separate SSH CA with manual signing workflows, IT teams use a single cloud-native PKI that issues certificates for every access layer.
Here are the key capabilities of SecureW2 JoinNow Dynamic PKI for SSH certificate management:
- Automated certificate issuance tied to identity provider (IdP) attributes from Entra ID, Okta, or Google Workspace
- Configurable validity periods for short-lived, ephemeral credentials that expire automatically
- Centralized revocation through a single management console
- Audit logging of every certificate issued, renewed, or revoked
- No on-premises CA infrastructure to deploy, patch, or maintain
This approach brings SSH certificate management into the same platform IT teams already use for 802.1X and VPN certificate-based authentication, reducing operational overhead and closing a common gap in credential management.
Schedule a custom demo or talk to our team to get started with managed PKI for SSH certificates.
Frequently Asked Questions
What is the difference between an SSH certificate and an SSH key?
An SSH key is a static public-private key pair used for authentication. An SSH certificate wraps a public key with signed metadata including principal name, expiration, and permissions issued by a certificate authority.
The CA signature lets servers trust the certificate without maintaining per-user `authorized keys` files, and the expiration date means compromised credentials automatically stop working.
Do SSH certificates expire?
Yes. Every SSH certificate includes a validity period set during signing (the `-V` flag in `ssh-keygen`).
Certificates can be valid for minutes, hours, days, or longer. Short-lived certificates that are valid for a single work session are considered a best practice because they limit the window of exposure if a private key is compromised.
How do I revoke an SSH certificate?
OpenSSH supports Key Revocation Lists (KRLs). You generate a KRL with `ssh-keygen -k` and reference it in `sshd_config` using `RevokedKeys`.
Any certificate listed in the KRL is immediately rejected. For organizations using managed PKI, revocation is handled through a centralized console.
Can I use SSH certificates with existing SSH keys?
Yes. SSH certificate authentication is backward-compatible. You sign your existing public key with the CA to produce a certificate.
The underlying key pair does not change. Servers configured to trust the CA accept the certificate, while servers without CA configuration continue to use traditional `authorized keys` authentication.
Is an SSH certificate the same as an SSL certificate?
No. SSH certificates use an OpenSSH-specific format for authenticating shell connections. SSL/TLS certificates use the X.509 standard for securing web traffic, VPN tunnels, and Wi-Fi authentication.
Both rely on public key cryptography and certificate authorities, but they are not interchangeable.
