OpenBao SSH certificate authority

The rollout succeeds or fails on sequence, not on the signing configuration. Before any sshd change, inventory every host and every place a login is accepted: the authorized_keys files for each local account, the sshd configuration, bastion and jump host policies, and any automation that logs in with a key. Record which keys belong to people, which belong to service accounts and which have no known owner. Ask each team which hosts it logs in to and how, because this inventory defines the rollback surface for every later phase.

Next, mark the OpenBao SSH CA as trusted on a pilot group without removing anything. Trust is set with TrustedUserCAKeys in the sshd configuration, and access can be narrowed with principals through AuthorizedPrincipalsFile. Choose pilot hosts that are low risk and owned by a team that can test logins and respond quickly. Keep the existing static keys in place so both methods work during the transition. Run the sshd configuration test before every reload, and confirm on each operating system image that the SSH server supports the options you plan to use.

Keep a break-glass path throughout the transition. This should be an emergency access route that does not depend on the new CA or on OpenBao being reachable, such as a local administrator account whose credential is held offline under a documented approval process, or a console or out-of-band access path. Test it before the first host changes and retest after each wave. Also plan for an OpenBao outage during an incident: it blocks new certificate issuance, while certificates already issued remain valid until they expire. Confirm the lifetimes your signing roles will set, because they determine how long that exposure lasts.

Move one host class at a time, such as web servers, then application servers, then databases, with wave sizes set in the written scope. For each wave, change the configuration through your configuration management tool, reload sshd so existing sessions survive, then verify certificate logins for each identity group and confirm that automation still runs. Bastions need a specific decision: if they proxy sessions, determine whether the user certificate is presented to the bastion, the target or both, and test ProxyJump paths end to end. For service accounts, move each one to a dedicated machine identity or keep its key under separate review. Do not leave them for the final wave, where they are most likely to break unnoticed.

Remove static keys only after certificate logins are verified on every host in the wave. Set the exit criteria in advance: successful certificate logins on each host, an observation period agreed in the scope, audit records showing the expected identities, and no unowned keys left in the group. Then remove the authorized_keys entries through configuration management, keep a copy of each removed file, and log the change. Pace and group sizes depend on your estate, change windows and the number of teams involved, so the written scope should set them rather than a generic template.

For engineers, the largest change is that every connection starts with a request. Before logging in to a host, the engineer authenticates to OpenBao with the method the organization has chosen, such as Userpass for developer machines, and receives a signed SSH certificate that is valid for a short period. The SSH client presents that certificate, and the host accepts it because it trusts the CA. The long-lived private key that many people keep for years stops being the thing that grants access. Plan a short onboarding guide that shows the request command, explains what happens when a certificate expires during a session, and names who to contact when authentication fails.

For operators, revocation becomes a question of where issuance is controlled. Access is granted through the signing roles, the allowed principals and the policies that permit an identity to request them. Removing a person or group from those policies stops new certificates from being signed. The part operators must plan for is that a certificate already issued stays valid until its lifetime ends, unless the hosts also check revocation data. OpenSSH supports revoking certificates through revocation lists and related settings, so confirm with the host team how quickly an emergency removal must take effect and whether it needs a push to hosts.

Auditors receive a different kind of evidence. Instead of a spreadsheet of key files, owners and rotation dates, the record is the issuance history: which identity requested a certificate, when, for which principals and with what lifetime. That history exists only if audit devices are enabled and their output is retained and protected, so confirm the setup with the audit logging topic before relying on it. Auditors will also ask how the host trust configuration was approved and deployed, and how changes to roles and the CA are tracked in version control and change tickets. Prepare a sample trace that follows one access event from request to login so the auditor can see the full path.

Several friction points need a plan before rollout. Scripts that use a fixed key path, such as cron jobs, deployment tools and backup agents, will fail once the static key is retired, so inventory them and decide whether each one gets a certificate, a dedicated workload identity or another method. CI runners raise a similar question. A runner needs an identity that OpenBao can authenticate, and that identity should be scoped so a single job cannot request access to every host in the fleet. Test these paths in a non-production environment and record an owner for each one who signs off on the change.

On-call access during an OpenBao outage needs a deliberate answer. If OpenBao cannot issue certificates, engineers who already hold unexpired certificates can still connect until those expire, but nobody new can obtain access. Decide in advance whether a break-glass path exists, such as a separately held and monitored emergency credential or a documented procedure the security team has approved, and test it before it is needed. High availability and upgrades reduce how often this situation arises. Both are covered in the separate HA and upgrade topics, so use those to size the operational risk before committing to a design.