Documentation embedded in this build.

Leaving the public CA

If any of your clients authenticate with a certificate a public CA issued, you have a deadline that is not yours to move. This page is the argument for where to go instead, written so you can check every part of it. It is dated: everything below was accurate when it was written in August 2026, and the dates belong to other people's programmes, so verify them at their source before you put them in a plan.

The clock

• Let's Encrypt has ended client-authentication issuance, fully out on 2026-07-08, per their own announcement. That announcement is the citation this page stands on, because it is the primary source that was actually read.
• The Chrome Root Program's version 1.8 policy separates client and server PKIs on a comparable schedule — new subordinate CAs restricted to server authentication from 2026-06-15, leaf certificates from 2027-03-15. The v1.8 text itself was not retrieved when this page was written, so it appears here as corroboration and not as the source. Read it from the Chrome Root Program before you quote those two dates.
• CA/Browser Forum ballot SC-081v3 brings the maximum certificate lifetime down to 47 days by 2029. That one does not force the move; it decides what has to be true about wherever you move to.

Two of these are already in the past. If your renewal against a public CA has started being refused for a reason that names client authentication, that is the schedule arriving, not a fault in your request.

Switching public CAs is not one of your options

The reflex is to find a public CA that still issues client certificates. It is worth understanding why that is a shrinking hiding place rather than a solution.

The exit is happening at the root programme level, not at the CA level. Root programmes are separating the two purposes — a publicly trusted root may vouch for servers or for clients, not both — and a CA that keeps issuing client certificates from a publicly trusted root is not doing you a favour, it is out of step with the programme that makes its root trusted in the first place. Whichever CA you move to next inherits the same constraint, on roughly the same schedule.

There is a second reason, and it is the more useful one: you were never getting anything from public trust on the client side. No browser verifies your clients. The only parties that verify them are your own servers, proxies, and brokers, and they verify against a trust store you already control. What the public CA gave you was a validation ritual — proof of control over a domain name or an email address — that says nothing about whether the holder should be allowed into your system. You have been paying a third party to attest to a fact your authorization rules do not consult.

Moving to a private CA is therefore not a downgrade in trust. It removes a dependency that was decorative on this side of the connection, and it puts the issuing decision where the authorization decision already was.

The 47-day future makes renewal a property of the system

By 2029, a 47-day maximum lifetime means roughly eight renewals per certificate per year. Whatever you build has to renew without a person in it, or it becomes an outage generator with a calendar attached. That is the real requirement the sunset hands you, and it is worth choosing your destination against it rather than against issuance alone — issuing a certificate is the easy part of a private CA, and everyone does it.

AuthBox ships two renewal mechanisms, for two populations, and it is deliberately not one universal one:

• The agent, for endpoints with a person behind them. authbox-agent renews ahead of expiry, replaces the credential, and marks the old one superseded. It holds no privilege beyond what that person already has running the client by hand.
• Renewal by possession plus permission, for unattended services. A service presents the certificate it already holds and receives a replacement. Possession of the key is proved by the handshake; that the deployment wants this identity renewing itself is a separate fact, carried by an autorenew attribute on the subject and evaluated by the same engine that decides everything else. Withdrawing that permission is deleting one attribute — it takes effect at the next renewal and needs no revocation list. The subject cannot change on renewal, and an expired or revoked certificate is refused whatever attributes it holds.

Both are honest about their limits. The attribute is granted per subject rather than being a fleet-wide default, and the agent deliberately does not use it — a credential that renews itself with nobody watching is a decision somebody should make once, out loud, about the specific identities it suits.

First issuance stays a reviewed act in either case. A service's first certificate comes from a single-use join token; a person's comes from an invitation an administrator minted, or from an approval in the enrollment queue. If your fleet already speaks ACME, AuthBox serves RFC 8555 with external account binding, so cert-manager, certbot, Caddy, and lego enrol against it with no AuthBox-specific code — the binding's key identifier is an invitation, which keeps the "somebody authorized this once" property that ACME on its own does not have.

What a private CA does not give you, and what this one adds

A bare private CA — an OpenSSL hierarchy, a small CA server, your cloud provider's private CA — solves issuance. Everything below issuance stays your problem: who is allowed to do what once the certificate exists, how a revocation actually reaches a verifier, how you demonstrate any of it to a reviewer, and whether it works at all without an internet connection.

These are the things AuthBox does about that. Each one names how you would check it, because a claim you cannot test is worth what you paid for reading it:

• A signed decision receipt for every request. Where AuthBox's proxy makes an authorization decision, it mints a signed receipt carrying the rule that granted access, bound to one route as its audience, and alive for single-digit seconds. The application behind the proxy verifies it against its own copy of the signing key's public half, so the application can prove why it was allowed to serve a request rather than trusting a header. Check it by minting one and verifying it outside the system.
• Conformance tests generated from your own declarations. For every operation your specification declares, a generated suite asserts the named subject is permitted, then decomposes the requirement into clauses — the project, each attribute, the mission — and for each clause finds a subject that fails exactly that one. Each must be denied, and the audited reason must name the clause that denied it. A clause no subject can isolate is reported as uncovered and fails the run, because an untested clause and a passing one look identical in a green build. Check it with go test ./internal/conformance/, and by deleting a requirement to watch the suite change.
• Revocation that is checked, and fails closed. Every certificate in a presented chain is checked against a revocation list held for its issuer. A missing or stale list denies the handshake rather than being ignored, on the grounds that a revocation source you cannot read is not evidence that there are no revocations. There is an online queue for requesting a revocation, and nothing online signs one — the list is signed where the CA key lives. Check it by revoking a certificate and watching the handshake fail, and by removing the list and watching handshakes fail rather than succeed.
• Airgap as a mode rather than a deployment story. Revocation lists and authority bundles cross an air gap as signed files on whatever medium you use; their integrity comes from the signature, not from the medium. Bundles carry a monotonically increasing serial, so an older bundle replayed at a one-way boundary is refused rather than silently adopted. Check it by running a deployment with no route to anywhere and seeing what still works.
• FIPS-only as the compiled-in default. The validated module is linked at build time, strict mode is the compiled-in default in the daemon itself, and the process asserts its effective mode at startup and refuses to serve below strict — because the first two layers can be overridden by an environment variable, and a downgraded deployment that does not say so is indistinguishable from a correct one. Check it with make fips-only-test, and by trying to start the daemon with the mode turned off.

The boundary: this is the client side of your PKI

AuthBox replaces the client half of what the public web PKI was doing for you. It does not replace the server half, and you should be suspicious of anyone who says otherwise.

Server certificates for public-facing surfaces stay on the public web PKI. A browser you do not control will never trust your private root, and no amount of internal PKI changes that. The sunset described at the top of this page is not an exit from server authentication either — public CAs continue issuing server certificates, that is the purpose the root programmes are consolidating toward, and your public server certificates should keep being issued and automated exactly as they are now. AuthBox's own listeners are no exception: where one faces the public web, it holds a publicly issued serving certificate like anything else, renewed on the public CA's schedule.

The place where both halves can be private is a system with no browsers in it — service to service, where you own every verifier. That is a legitimate design and AuthBox is usable for it, but it is a decision you make about your own topology, not a claim this page is making for you.

What moving actually involves

Seven stages, in order, and the order carries the only rule that reliably breaks migrations when it is inverted: every verifier gains your new root before any client presents a leaf signed by it. Inventory what presents a public client certificate and who verifies it; stand up the CA and decide the naming scheme; choose the intake, by invitation or by ACME; run the dual-trust window in which both roots are accepted; cut clients over in batches; retire the public root from client verification only; and prove it by keeping one retired credential and confirming that a connection using it now fails.

The full procedure, with the commands and with what breaks if the order is reversed, is the operations runbook: Migrating a client fleet off a public CA.

Where to look next

• Enrolling with AuthBox — the four intake paths as one of your endpoints will experience them.
• Living with your certificate — renewal, expiry, and what happens when a key is lost, from the holder's side.
• Migrating a client fleet off a public CA — the runbook, for whoever will actually run it.