Certificate Authority - OnePAM | Short-Lived Certificates — Replace Static Keys with Auto-Expiring Credentials

Overview

Why Certificate Authority Matters

certificates are the most secure method for SSH authentication, recommended by the NIST and used by companies like Facebook, Google, and Netflix. Unlike SSH keys (which persist indefinitely and must be manually managed), certificates have a built-in expiration time, carry identity information (who the certificate was issued to), and can encode authorization data (which servers the user can access). However, building and operating an certificate authority is complex — it requires key management, certificate issuance infrastructure, sshd configuration, and integration with identity providers. OnePAM provides a fully managed SSH CA that integrates with your SAML/OIDC Identity Provider. When users want to SSH, they authenticate via your corporate IdP, and OnePAM issues a certificate valid for 1-24 hours. The certificate includes the user's identity (principals), permitted hosts, and access restrictions. sshd is configured to trust OnePAM's CA (a one-time change), and certificates are accepted automatically. No authorized_keys files. No key distribution. No key rotation. Certificates expire and access stops — automatically.

Local Agent + CA

The agent configures sshd to trust OnePAM's CA automatically. Certificates are issued after IdP authentication. Works with standard SSH clients.

Gateway + CA

The gateway issues certificates and manages SSH credentials transparently. Target servers trust the CA's key. Combines zero-day protection with certificate-based authentication.

SSH Security Risks

Risks of Static SSH Key Infrastructure

Without identity-based SSH access, these risks threaten your servers every day.

Static SSH keys have no expiration — a leaked key provides indefinite access until manually revoked

SSH key rotation at scale is so painful that most organizations never rotate keys

Building a custom SSH CA requires PKI expertise, HSM infrastructure, and ongoing operational investment

Without certificates, SSH access authorization is scattered across authorized_keys files with no central control

Host key verification (TOFU) is vulnerable to man-in-the-middle attacks without host certificates

The Challenge

SSH Security Challenges

These are the risks organizations face with traditional SSH authentication.

No Built-In SSH PKI

OpenSSH supports certificates natively but provides no CA infrastructure. Organizations must build their own CA, issuance pipeline, and revocation system.

authorized_keys Fragmentation

SSH access authorization is stored in authorized_keys files on each server. No central view of who has access to what. Auditing requires examining every server.

Key Lifecycle Management

SSH keys must be generated, distributed, rotated, and revoked. Each step is manual, error-prone, and rarely completed across all servers.

No Identity in Keys

An SSH public key is just a cryptographic value. It doesn't encode who it belongs to, when it was created, or when it should expire.

Host Key TOFU Problem

First-time SSH connections to new servers trigger a trust-on-first-use (TOFU) warning. Users blindly accept, enabling man-in-the-middle attacks.

Service Account Keys

Service accounts (Ansible, Jenkins, monitoring) use SSH keys that are shared, never rotated, and persist indefinitely. They're the highest-risk SSH credentials.

Setup Guide

How OnePAM's Certificate Authority Works

Step-by-step guide to deploying identity-based SSH access.

1

OnePAM Hosts the SSH CA

OnePAM operates a fully managed certificate authority. No HSM procurement, no PKI expertise required.

OnePAM's CA generates a signing key pair. The CA's public key is distributed to servers (TrustedUserCAKeys in sshd_config). OnePAM optionally issues host certificates to servers, solving the TOFU problem.

2

Servers Trust the CA

Add OnePAM's CA public key to sshd_config. A one-time change on each server.

TrustedUserCAKeys /etc/ssh/onepam_ca.pub — this single line tells sshd to accept certificates signed by OnePAM's CA. No per-user authorized_keys changes needed.

3

Users Authenticate via IdP

When a user wants to SSH, they authenticate via your SAML/OIDC IdP with MFA.

OnePAM verifies the IdP assertion, checks access policies (which servers, what privileges, what time window), and decides whether to issue a certificate.

4

Certificate Issued

OnePAM signs a short-lived certificate (1-24 hour TTL) with the user's identity and access permissions.

The certificate contains: principals (Linux usernames the user can log in as), valid-after and valid-before timestamps, critical options (source IP restriction, force-command), and extensions (permit-pty, permit-port-forwarding).

5

Connect and Auto-Expire

Users run 'onepam ssh server' to connect. sshd validates the CA signature and grants access. When the certificate expires, access stops.

No authorized_keys lookup. No key rotation. No orphan keys. The certificate lifecycle is: authenticate → issue → use → expire. If the user needs more access, they re-authenticate.

Key Benefits

Benefits of Certificate Authority

What changes when you deploy identity-based SSH access.

Managed SSH PKI

Enterprise certificate authority without HSM procurement, PKI expertise, or custom infrastructure. OnePAM manages the CA for you.

Zero PKI infrastructure to manage

Auto-Expiring Access

Certificates expire after 1-24 hours. No orphan access, no stale credentials, no manual revocation for routine access lifecycle.

Automatic access expiration

Identity-Encoded Certificates

Certificates carry the user's corporate identity — username, email, groups. Every SSH session is attributable to a verified individual.

Full identity attribution

Eliminate authorized_keys

No more managing authorized_keys files on servers. sshd trusts the CA and certificates handle access authorization.

Zero authorized_keys management

Solve the TOFU Problem

OnePAM issues host certificates so clients can verify server identity. No more 'Are you sure you want to continue connecting?' prompts.

No more host key warnings

Service Account Certificates

Service accounts get their own certificates with restricted principals and short TTLs. Replace shared SSH keys with attributable certificates.

Secure service account access

SSO Features

SSH SSO Capabilities

Every feature needed for enterprise-grade SSH authentication.

Fully managed certificate authority

User certificates with configurable TTL (1-24 hours)

Host certificates for server identity verification

Certificate principals from IdP attributes

Certificate extensions (pty, port-forwarding, agent-forwarding)

Critical options (source-address restriction, force-command)

Certificate revocation list (CRL) for emergency revocation

API for programmatic certificate issuance

Works with standard OpenSSH sshd and clients

Compatible with ssh-agent for certificate caching

Security

Zero-Day Protection Features

Enterprise-grade security controls for SSH access.

Short-lived certificates eliminate persistent credential risk

CA signing key stored with HSM-grade protection

Certificate revocation for emergency access removal

Principals restrict which usernames a certificate can use

Source-address restriction limits certificate to specific IPs

Force-command restricts certificate to specific operations

Certificate transparency logging for auditing

Automatic CA key rotation with zero downtime

Real-World Scenarios

Certificate Authority Use Cases

Common scenarios where organizations deploy OnePAM SSH SSO.

1

Enterprise replacing thousands of authorized_keys entries with CA-trusted certificates issued after Okta authentication

2

Cloud-native company issuing 1-hour certificates to developers for production access via CI/CD pipeline

3

Financial institution using host certificates to prevent SSH man-in-the-middle attacks in trading infrastructure

4

DevOps team issuing restricted certificates to CI/CD pipelines with force-command and source-address limitations

5

MSP using short-lived certificates for client server access with automatic expiration after support window

6

Zero-trust architecture implementing certificates as part of identity-based access for all infrastructure

Frequently Asked Questions

Certificate Authority FAQ

Common questions about SSH SSO and zero-day protection.

What is an certificate authority?

An certificate authority (CA) is a signing infrastructure that issues certificates. Unlike SSH keys, certificates are signed by the CA, carry identity and expiration information, and are verified by sshd against the CA's public key. OnePAM operates a fully managed SSH CA that issues certificates after SAML/OIDC authentication.

Do I need to modify sshd_config on every server?

Yes, a one-time change: add TrustedUserCAKeys pointing to OnePAM's CA public key. This is a single line in sshd_config. After this, sshd accepts certificates signed by OnePAM's CA. No per-user changes needed. The agent can do this automatically.

What happens when a certificate expires?

The user can no longer authenticate with the expired certificate. They must re-authenticate via their IdP and receive a new certificate. Active SSH sessions are not terminated when the certificate expires — only new connection attempts are affected.

Can certificates be revoked before expiration?

Yes. OnePAM maintains a certificate revocation list (CRL) that sshd can check. Emergency certificate revocation takes effect within minutes. This is a safety net — the short TTL means most certificates expire before revocation is needed.

How do host certificates work?

OnePAM can issue host certificates to your servers. When configured, SSH clients verify the server's certificate against OnePAM's CA instead of relying on known_hosts (TOFU). This prevents man-in-the-middle attacks and eliminates 'host key changed' warnings.

Does OnePAM's CA support hardware security modules (HSM)?

OnePAM's CA signing key is protected with HSM-grade security. For organizations with specific HSM requirements (FIPS 140-2 Level 3, CloudHSM, Azure Key Vault HSM), OnePAM supports external HSM integration for the CA signing key.

Short-Lived Certificates — Replace Static Keys with Auto-Expiring Credentials