SSH Certificate Authority: Setup, Security and Production Best Practices

OpenSSH certificates provide a scalable alternative to managing individual SSH public keys across servers.

Instead of distributing every user's public key to every system they need to access, administrators can configure SSH servers to trust a certificate authority.

The certificate authority signs approved public keys, creating certificates that identify their holders, specify valid principals and define when those credentials may be used.

This changes the operational model of SSH authentication.

Individual public keys no longer need to be installed on every server when certificate trust and authorization are configured appropriately. Instead, the security of the environment depends on the certificate authority, the policies governing issuance and the systems enforcing certificate authorization.

Creating an SSH certificate authority is straightforward.

Operating one securely in production requires considerably more thought.

This guide covers both: from generating CA keys and signing your first certificate to protecting signing infrastructure, managing revocation, rotating CA keys and designing reliable certificate issuance workflows.

What Is an SSH Certificate Authority?

An SSH Certificate Authority, commonly called an SSH CA, is a cryptographic signing authority used to issue OpenSSH certificates.

At its simplest, an SSH CA is an SSH key pair.

The CA private key signs other SSH public keys, producing certificates that contain identity information, validity periods, permitted principals and optional restrictions.

The CA public key is distributed to SSH clients or servers that should trust certificates signed by that authority.

This creates a trust relationship between the certificate issuer and the systems relying on its signatures.

Unlike traditional X.509 public key infrastructure, OpenSSH certificate authentication does not require a hierarchy of intermediate certificate authorities or conventional TLS certificate chains.

OpenSSH uses its own certificate format and validation mechanisms.

The CA Private Key

The private key is the most sensitive component of the authority.

Anyone capable of using it to sign certificates may be able to issue credentials that trusted systems accept, subject to the authorization policies those systems enforce.

Protecting the CA private key is therefore a central security requirement.

The CA Public Key

The CA public key is not secret.

It is distributed to systems that should trust the authority.

SSH servers use trusted user CA public keys to validate user certificates.

SSH clients can use trusted host CA public keys to validate host certificates.

The CA public key establishes which signing authority is trusted. It does not, by itself, define every account or resource that a certificate holder may access.

User CAs vs Host CAs

OpenSSH supports two primary certificate types: user certificates and host certificates.

Although both use digital signatures, they establish different trust relationships.

User Certificate Authorities

A user CA signs public keys belonging to users or automated workloads.

SSH servers configured to trust that authority can authenticate valid user certificates when the relevant principals and authorization policies permit access.

For example, an organization might issue a certificate containing the principal production-deploy.

A server can be configured to authorize that principal for a particular local account.

The certificate proves that the trusted CA signed the user's public key with the specified attributes.

The server decides whether those attributes authorize the requested login.

Host Certificate Authorities

A host CA signs SSH server public keys.

SSH clients configured to trust the host CA can validate server certificates without maintaining an individual known_hosts entry for every server public key.

This is useful in dynamic infrastructure where servers are frequently provisioned or replaced.

Why Separate CA Keys Matter

User and host certificates represent different security responsibilities.

A user CA controls the issuance of authentication credentials for people and workloads.

A host CA controls which servers clients may recognize as trusted hosts.

Using separate CA keys limits the consequences of a compromised signing authority and provides clearer operational separation.

Production deployments should generally maintain distinct user and host CAs.

Creating an OpenSSH Certificate Authority

OpenSSH includes the tools needed to create and operate a basic certificate authority.

The following examples use Ed25519 keys and the standard ssh-keygen utility.

They demonstrate the underlying mechanisms rather than a complete production signing service.

Step 1: Generate a User CA Key Pair

>bash

ssh-keygen -t ed25519 -f ssh_user_ca -C "SSH User CA"

This creates:

>text

ssh_user_ca
ssh_user_ca.pub

The private key is stored in ssh_user_ca.

The public key is stored in ssh_user_ca.pub.

Use a strong passphrase when creating a manually operated CA private key.

For production systems, consider how the signing key will be protected, accessed, backed up and recovered before issuing certificates.

Step 2: Generate a Separate Host CA

>bash

ssh-keygen -t ed25519 -f ssh_host_ca -C "SSH Host CA"

This creates:

>text

ssh_host_ca
ssh_host_ca.pub

Do not distribute either CA private key to clients or SSH servers merely to establish trust.

Only the appropriate CA public key is required by relying systems.

Step 3: Verify the CA Public Keys

>bash

ssh-keygen -lf ssh_user_ca.pub

>bash

ssh-keygen -lf ssh_host_ca.pub

Record and independently verify the expected fingerprints when distributing CA public keys.

The security of certificate authentication depends on relying systems trusting the intended authority.

Signing SSH User Certificates

A user certificate is created by signing a user's public key with the user CA private key.

The user's private key remains with the user.

Generate a User Key Pair

>bash

ssh-keygen -t ed25519 -f alice_key -C "alice@example.com"

This creates:

>text

alice_key
alice_key.pub

Sign the Public Key

>bash

ssh-keygen -s ssh_user_ca \
  -I alice-2026-001 \
  -z 1001 \
  -n alice \
  -V +1h \
  alice_key.pub

The command produces:

>text

alice_key-cert.pub

The options specify:

Option	Purpose
-s	CA private key used to sign the certificate
-I	Certificate key identifier
-z	Certificate serial number
-n	Valid principals
-V	Certificate validity interval

In this example, the certificate is valid for approximately one hour from issuance.

Inspect the Certificate

>bash

ssh-keygen -Lf alice_key-cert.pub

Inspect the certificate's type, signing CA, serial number, key identifier, principals, validity period and extensions.

Why Key Identifiers and Serial Numbers Matter

The key identifier is useful for associating an issued certificate with an identity or issuance event.

Serial numbers support tracking and revocation.

In a production CA, serial numbers should be allocated consistently and uniquely within the issuing authority's namespace.

A signing service should record sufficient information to identify which certificate was issued, to whom, for which purpose and under which authorization decision.

Configuring SSH Servers to Trust a User CA

To accept user certificates, an SSH server must trust the issuing user CA.

Copy the CA public key to the server:

>bash

sudo install -m 0644 ssh_user_ca.pub /etc/ssh/ssh_user_ca.pub

Configure the SSH daemon:

>sshd_configssh-config

TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub

This directive belongs in the SSH server configuration, normally sshd_config.

Validate the configuration before reloading the SSH service:

>bash

sudo sshd -t

Then reload the service using the appropriate command for the operating system.

For systems with a service named sshd:

>bash

sudo systemctl reload sshd

Service names and management commands vary between operating systems.

Trust Is Not Authorization

Configuring TrustedUserCAKeysestablishes trust in the CA's signatures.

It does not mean every certificate issued by that CA should automatically grant access to every account.

The SSH server must still evaluate the certificate's principals and any applicable account authorization rules.

This distinction is fundamental to secure SSH CA operation.

Controlling Access with Certificate Principals

A certificate principal represents an identity or role for which the certificate may be accepted.

Principals are embedded in the certificate when it is signed.

For example:

>bash

ssh-keygen -s ssh_user_ca \
  -I alice-production \
  -n production-deploy \
  -V +15m \
  alice_key.pub

The resulting certificate contains the principal:

>text

production-deploy

The SSH server must determine whether that principal is authorized for the requested account.

AuthorizedPrincipalsFile

A server can define authorized principals using:

>sshd_configssh-config

TrustedUserCAKeys /etc/ssh/ssh_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

For a local account named deploy, the file:

>text

/etc/ssh/auth_principals/deploy

might contain:

>text

production-deploy
release-engineer

A certificate containing an authorized principal can satisfy the principal-matching requirement for the deploy account, subject to the remaining authentication and authorization checks.

AuthorizedPrincipalsCommand

OpenSSH also supports obtaining authorized principals from an external command.

This can support integration with centralized authorization systems.

However, the command must be protected against unauthorized modification and executed with appropriately restricted privileges.

Dynamic principal authorization should not become an uncontrolled mechanism for granting access.

Avoid Overly Broad Principals

A CA should issue only the principals justified by the approved access request.

Issuing broad certificates containing numerous unrelated principals increases the consequences of credential compromise.

Where practical, principals should reflect specific roles or access purposes.

Signing SSH Host Certificates

Host certificates establish trust in SSH servers.

A host CA signs the public key corresponding to a server's host private key.

Sign a Host Public Key

>bash

ssh-keygen -s ssh_host_ca \
  -I server01 \
  -h \
  -n server01.example.com,server.example.com \
  -V +52w \
  ssh_host_ed25519_key.pub

The -h option creates a host certificate.

The -n option specifies the hostnames for which the certificate is valid.

The certificate validity period is illustrative and should be selected according to the organization's host provisioning and renewal processes.

Configure the SSH Server

In sshd_config:

>sshd_configssh-config

HostKey /etc/ssh/ssh_host_ed25519_key
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

The certificate must correspond to the configured host private key.

Configure Client Trust

SSH clients can trust a host CA through an @cert-authority entry in their known_hosts configuration.

For example:

>known_hoststext

@cert-authority *.example.com ssh-ed25519 <complete-host-ca-public-key>

Replace the placeholder with the actual host CA public key data.

The hostname pattern limits where the authority is trusted.

Distribute trusted host CA public keys through a secure and verified process.

Host certificates reduce the need to maintain individual host-key trust records, but they do not eliminate the need to protect host private keys or verify CA identity.

Securing the CA Private Key

The security of an SSH certificate authority depends heavily on the protection of its signing key.

A compromised CA private key can allow an attacker to issue certificates that trusted systems may accept.

Certificate expiration does not solve this problem if an attacker can continually issue new certificates.

Restrict Access to Signing Operations

Only authorized components and administrators should be able to invoke the CA signing operation.

Do not expose a CA private key through shared filesystems, unrestricted scripts or general-purpose application credentials.

Separate the Signing Key from General Infrastructure

Avoid placing the CA private key on ordinary SSH servers or developer workstations.

A dedicated signing environment reduces the number of systems capable of exposing the key.

Consider Hardware-Backed Key Protection

Where supported by the chosen signing architecture, hardware security modules or managed cryptographic key services can reduce direct exposure of private signing keys.

However, support for particular key algorithms, signing interfaces and OpenSSH certificate formats must be verified.

A generic cloud key management service is not automatically compatible with every OpenSSH certificate signing workflow.

Audit Signing Activity

Record certificate issuance events.

Useful information includes:

Requesting identity.
Public key fingerprint.
Certificate serial number.
Key identifier.
Issued principals.
Validity interval.
Authorization decision.
Issuance timestamp.
Signing authority identity.

Protect these records against unauthorized modification.

Backups and Recovery

Consider how CA signing capability will be recovered after infrastructure failure.

An unavailable CA may prevent new certificates from being issued, although previously issued valid certificates can continue to be verified locally.

Backups of CA private keys are highly sensitive and require protection appropriate to the signing authority.

Designing a Production SSH CA

A production SSH CA is more than a private key and a signing command.

It is a system for deciding who receives certificates, which identities those certificates represent and how long the resulting credentials remain valid.

A secure issuance workflow should separate several responsibilities.

Identity Verification
Establish the identity of the requesting user or workload before any signing decision.
Authorization
Determine which principals, restrictions and validity periods the requester is permitted to receive.
Signing
Sign only approved public keys with the protected CA private key and approved certificate attributes.
Certificate Delivery
Return the issued certificate while keeping the private key under the owner’s control.
Auditing
Record issuance details and authorization decisions for investigation and compliance.
Renewal
Issue new certificates only after current identity and authorization checks are performed.

Identity Verification

Establish the identity of the requesting user or workload.

Identity verification may involve an organizational identity provider, multifactor authentication or a workload identity mechanism.

Possession of an SSH public key is not sufficient proof of authorization.

Authorization

Determine which principals, restrictions and validity periods the requester is permitted to receive.

Authentication establishes who is making the request.

Authorization determines what access may be granted.

Signing

Sign the approved public key using the protected CA private key.

The signing operation should use only attributes authorized by the policy decision.

Certificate Delivery

Return the certificate to the requesting client.

The corresponding private key should remain under the control of its owner.

Auditing

Record the issuance event and the authorization decision.

The record should support later investigation, compliance review and certificate revocation.

Renewal

When the certificate expires, a new certificate can be issued after appropriate checks.

Do not assume that possession of a previous certificate automatically entitles the requester to another.

Short-Lived Certificates and Automated Issuance

OpenSSH certificates contain validity intervals.

This allows a CA to issue credentials that remain valid only for a limited period.

For example:

>bash

ssh-keygen -s ssh_user_ca \
  -I alice-temporary \
  -n production-deploy \
  -V +15m \
  alice_key.pub

The resulting certificate is valid for approximately 15 minutes.

After expiration, it cannot be used for new SSH authentication.

However, expiration does not automatically terminate SSH sessions that were established while the certificate was valid.

Why Automation Is Important

Manually issuing a new certificate every 15 minutes is impractical.

Short-lived credentials become operationally useful when issuance is automated and integrated with identity and authorization systems.

A user can authenticate, request access and receive a temporary certificate without an administrator manually running ssh-keygen.

This creates a foundation for controlled, just-in-time SSH access.

Expiration Is Not Revocation

Short validity periods reduce the window during which compromised credentials can be reused for new authentication.

They do not provide immediate revocation.

A certificate may remain usable until expiration unless an effective revocation or authorization control prevents its acceptance.

For a detailed discussion, read our guide to Short-Lived SSH Certificates.

/guides/short-lived-ssh-certificates/

Revoking SSH Certificates

OpenSSH supports Key Revocation Lists, commonly called KRLs.

A KRL can identify certificates and public keys that should no longer be accepted.

Create a KRL

>bash

ssh-keygen -k -f revoked_keys.krl alice_key-cert.pub

This creates a revocation list containing the specified certificate.

Query a KRL

>bash

ssh-keygen -Q -f revoked_keys.krl alice_key-cert.pub

This checks whether the supplied certificate is revoked by the KRL.

Configure Revocation

In sshd_config:

>sshd_configssh-config

RevokedKeys /etc/ssh/revoked_keys.krl

The SSH daemon must be able to read the revocation file.

If the configured file cannot be read, public-key authentication may fail.

Revocation Distribution

KRLs must be distributed to the servers expected to enforce them.

Because OpenSSH certificate validation can occur without contacting the CA, revoking a certificate centrally does not automatically notify every relying server.

Production deployments need a defined revocation distribution and enforcement process.

Compromised CA Keys

Compromise of a CA private key is more serious than compromise of an individual certificate.

An attacker with the signing key may be able to create additional certificates.

Responding to CA compromise may require removing the affected CA from trusted configurations, deploying a replacement authority and reissuing legitimate credentials.

The response should also consider host certificates, existing sessions and other systems relying on the compromised authority.

Rotating SSH Certificate Authority Keys

CA keys should have a planned lifecycle.

Rotation may be required because of security policy, algorithm changes, operational restructuring or suspected compromise.

Unlike ordinary user certificate renewal, CA rotation changes the trust anchor itself.

Step 1: Create a Replacement CA

Generate a new CA key pair using the same protected signing procedures as the original authority.

Step 2: Distribute the New CA Public Key

Configure relying systems to trust the replacement CA.

During a planned migration, systems may temporarily trust both the old and new authorities.

For user certificates, a TrustedUserCAKeys file can contain multiple trusted CA public keys.

For host certificates, clients may temporarily maintain trust entries for both authorities.

Step 3: Begin Issuing with the New CA

Switch certificate issuance to the replacement signing authority.

Ensure newly issued certificates are accepted by systems that have received the updated trust configuration.

Step 4: Retire the Old CA

After the migration period, remove the old CA public key from trusted configurations.

Verify that all required systems have completed the transition.

Emergency Rotation

If the old CA private key is compromised, a gradual overlap period may be inappropriate.

An emergency response may require immediately removing trust in the compromised authority, accepting temporary disruption where necessary.

The correct response depends on the environment and the consequences of continued trust.

CA Rotation Requires Planning

A certificate signed by the old CA does not become trusted by the new CA automatically.

Trust migration and certificate reissuance must be coordinated.

Organizations should test CA rotation procedures before they are needed during an incident.

Availability and Disaster Recovery

Certificate authorities introduce a dependency during certificate issuance.

However, OpenSSH certificate authentication does not normally require the CA to be online for each SSH connection.

Servers can validate certificates locally using the trusted CA public key.

This distinction allows certificate authentication to remain available even when the issuance service is temporarily unavailable.

Existing Certificates

Previously issued certificates can continue to be accepted until their validity periods end, provided trust and authorization requirements remain satisfied.

New Certificates

If the CA signing service is unavailable, users and workloads may be unable to obtain new certificates.

For short-lived certificates, this can quickly affect operational access.

Recovery Planning

Production CA architecture should consider:

Signing service availability.
Secure key recovery.
Issuance service redundancy.
Authorization service dependencies.
Certificate lifetime selection.
Administrative emergency access.
Recovery from CA compromise.

High availability should not be achieved by unnecessarily distributing copies of sensitive CA private keys.

Common SSH CA Mistakes

Treating CA Trust as Universal Authorization

A trusted CA signature is only one part of certificate authentication.

Server-side principal matching and authorization policies remain essential.

Leaving CA Private Keys on General-Purpose Servers

A CA private key should not be exposed unnecessarily to ordinary infrastructure.

Compromise of a signing key can affect every system trusting that authority.

Issuing Certificates with Excessive Lifetimes

Long-lived certificates weaken the operational advantages of certificate expiration.

Choose validity periods appropriate to the intended use.

Reusing the Same CA for Unrelated Trust Domains

Separating user and host authorities reduces unnecessary coupling between different authentication responsibilities.

Failing to Track Certificate Issuance

Without useful issuance records, investigating a compromised certificate or determining which credentials were issued becomes difficult.

Assuming Expiration Ends Existing Sessions

Certificate expiration normally prevents new authentication.

It does not automatically terminate established SSH sessions.

Ignoring CA Rotation

A production CA should have a tested process for replacing its signing key and updating trust.

Automating Signing Without Authorization

A certificate signing service that approves arbitrary principals or durations can undermine the security benefits of centralized issuance.

Automation must enforce policy, not bypass it.

Build Your Own SSH CA or Use Managed Certificate Issuance?

OpenSSH makes it possible to create a certificate authority with a small number of commands.

For a limited environment, that may be entirely sufficient.

However, a production CA introduces ongoing responsibilities.

Someone must authenticate certificate requesters, determine their permitted access, protect signing keys, issue credentials, maintain audit records, manage revocation and rotate trusted authorities.

These responsibilities exist independently of the underlying cryptographic implementation.

Building Your Own CA

Provides direct control over issuance and integration behavior.
Can fit specialized requirements and existing internal systems.
Requires the organization to maintain the CA platform and security controls.

Managed Certificate Issuance

Provides an operational layer around native OpenSSH certificate authentication.
Can integrate identity, authorization, and short-lived credential delivery.
Keeps compatibility with standard OpenSSH clients and servers.

Building Your Own CA

A custom SSH CA can provide complete control over issuance and integration.

It may be appropriate where an organization has specialized requirements or already operates suitable identity, authorization and signing infrastructure.

However, the organization must maintain the system and its security controls.

Managed Certificate Issuance

A managed certificate issuance system provides an operational layer around native OpenSSH certificate authentication.

It can integrate existing identities, enforce issuance policy and automate the delivery of short-lived credentials.

The SSH clients and servers can continue using standard OpenSSH certificate mechanisms.

The decision is therefore not necessarily between standard SSH and a proprietary alternative.

It is between operating the certificate management infrastructure yourself and using a system designed to manage those responsibilities.

Managing SSH Certificate Authorities with SSH Teams

SSH Teams is Jadaptive's approach to managed, certificate-based SSH access.

It builds on native OpenSSH certificates to support short-lived credentials linked to identity and access policy.

Rather than requiring administrators to maintain manual certificate signing workflows, SSH Teams provides an operational framework around certificate issuance.

Its architecture is designed to work with existing SSH clients and servers, without requiring a mandatory bastion host or proprietary SSH protocol.

SSH Teams also incorporates device-trust mechanisms into its access model.

For organizations adopting OpenSSH certificates, this provides a route from basic CA trust to centrally managed infrastructure access.

Explore SSH Teams

https://jadaptive.com/sshteam

Frequently Asked Questions

What is an SSH certificate authority?

An SSH certificate authority is a signing authority that creates OpenSSH certificates by signing SSH public keys. Systems that trust its public key can validate certificates it issues.

Does OpenSSH include a certificate authority?

OpenSSH includes the cryptographic tools required to create CA key pairs and sign certificates. It does not provide a complete organizational certificate issuance and lifecycle management service by itself.

Can I create an SSH CA using ssh-keygen?

Yes. ssh-keygen can generate CA keys and sign user or host public keys.

Should user and host certificates use different CAs?

Generally, yes. Separate CA keys provide clearer trust boundaries and reduce the consequences of a compromised signing authority.

Does an SSH CA need to be online for every connection?

No. OpenSSH certificate validation can occur locally using a trusted CA public key.

What happens if an SSH CA private key is compromised?

An attacker may be able to issue unauthorized certificates. A response may require removing trust in the compromised authority, deploying a replacement CA and reissuing legitimate certificates.

Can SSH CA keys be rotated?

Yes. Rotation involves creating a replacement CA, distributing its public key, switching issuance and eventually removing trust in the old authority.

Do SSH certificates eliminate authorized_keys?

Certificates can eliminate the need to distribute individual user public keys through authorized_keys when trusted CA authentication and appropriate principal authorization are configured. OpenSSH may still use authorized_keys for other authentication or authorization purposes.

Can an SSH CA use a hardware security module?

Potentially. The signing architecture must support the required algorithms and OpenSSH certificate signing operations. Compatibility depends on the chosen hardware or key management service and its integration.

Are SSH certificates the same as TLS certificates?

No. OpenSSH certificates use a native SSH certificate format rather than the X.509 format commonly used for TLS.