Lifecycle Management of SSH Certificate Authorities

You will maintain the rotation of CA keys used for system access.

In this lesson, you will learn how to maintain security posture by systematically rotating the SSH Certificate Authority (CA) keys used to grant system access.

Why Rotate CA Keys?

In a robust SSH infrastructure, individual users don't have static public keys sitting in ~/.ssh/authorized_keys. Instead, you use a CA to sign short-lived user certificates. Over time, the private key of that CA becomes a "crown jewel"—if it were ever compromised, every server trusting that CA would be vulnerable. Lifecycle management ensures that if a breach occurs, the blast radius is limited by periodic key rotation.

The Rotation Workflow

Rotating a CA key is not as simple as swapping a file, because existing valid certificates might still be in circulation. You must manage a "grace period" where the system trusts both the old and the new CA.

Generate the new CA: Create a new key pair on your secure signing server.
Distribute the Public Key: Update the TrustedUserCAKeys directive in sshd_config across your fleet to include both the old and new public keys:
```
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem
```
Note: Ensure the file contains both public keys, one per line.
Transition Signing: Point your automated signing service to use the new private key for all future certificate requests.
Cleanup: Once all previously issued certificates (which usually have short TTLs) have expired, remove the old public key from the trusted-user-ca-keys.pem file and reload sshd.

Managing Revocation

If you need to rotate a key prematurely due to a suspected compromise, rotation alone isn't enough. You must also maintain a KRL (Key Revocation List). Even after rotating your CA keys, you should publish a KRL that explicitly invalidates certificates signed by the compromised key until they naturally expire. This ensures that even an attacker with a valid-looking certificate is denied access during the transition phase.

By automating this rotation through your infrastructure-as-code pipelines, you ensure that no single CA key remains trusted indefinitely, effectively neutralizing the risk of long-term key exposure.

Key Takeaway: Rotating SSH CA keys requires a phased approach where you trust the new CA alongside the old one, allowing short-lived certificates to expire naturally before decommissioning the previous key.