Certificate rotation and validation

Renewing without changing the registration

All domains, identifiers, and tokens in these examples are fictional. The order service generates a new key pair and asks the print lab's partner CA for a new certificate with the same subject alternative name, orders.printer.example. Issuing, renewing, and revoking certificates followed the same steps for a website. The new certificate is valid from 30 November 2026, two weeks before the old one expires, so both work while the change rolls out across the order service's servers.

With tls_client_auth, nothing changes at the authorization server. The registration names the subject to expect, not a particular certificate, so any certificate from a trusted CA that carries orders.printer.example authenticates the client. That is the main convenience of the PKI method.

With self_signed_tls_client_auth, the registration lists the certificates themselves, so order matters. The client adds the new certificate to its registered key set first, waits until the authorization server has had time to fetch the updated set, switches to the new certificate, and removes the old one afterwards. It is the same overlap Rotating client credentials used for signing keys. Switching first and registering second produces a burst of invalid_client errors.

The trust side changes occasionally too. If the print lab replaces its partner CA, its authorization server must trust the new CA before any partner receives a certificate from it, and keep trusting the old one until the last certificate it issued has expired.

Tokens bound to the old certificate

Each certificate has its own thumbprint, because the thumbprint is a hash of the whole certificate:

Even a renewal for the same name with the same key would produce a new thumbprint, because the serial number and dates differ. So the moment a server in the order service starts connecting with the renewed certificate, any token it holds that was bound to the old one fails at the API with invalid_token. The API is doing exactly what it should: the certificate on the connection is not the one the token names.

The fix is the same as for an expired token. The order service requests a new access token over a connection that uses the new certificate and retries. On 1 December, the replacement's claims include:

{
  "client_id": "printer-orders",
  "iat": 1796151600,
  "exp": 1796152500,
  "jti": "demo-lab-token-id-4",
  "cnf": {
    "x5t#S256": "3WslWa2R8mrdJ7U93p0Rn-UW1VNnTzwl6yxm4CGQ7Lc"
  }
}

Only the claims that changed are shown. 1796151600 is 19:00 UTC on 1 December 2026.

A client can avoid the failed request entirely by keeping its cached tokens alongside the certificate they were obtained with. When a server switches certificates, it discards the tokens bound to the old one instead of trying them first. This matters most when several servers share a token cache but switch certificates at different times.

The order service has no refresh token to think about, because with client credentials it simply asks for a new access token. A confidential client that does hold refresh tokens keeps them through a rotation. The authorization server ties those refresh tokens to the client, which must authenticate every time it uses one, rather than to a particular certificate. After authenticating with its renewed certificate, the client can keep refreshing, and each new access token comes back bound to the new certificate. A public client has no such flexibility: when a server binds its refresh token to its self-signed certificate, changing the certificate makes the refresh token unusable.

Watching expiry

An expired client certificate fails early and quietly. The handshake is refused before any HTTP request is sent, so the order service sees a connection error rather than an OAuth error, and its logs may never mention the token endpoint at all.

Renewal should be automated, as it is for server certificates, and the automation itself needs watching. The order service keeps an inventory of its client certificates with their expiry dates and raises an alert well before each one, independently of the renewal job. That includes certificates it depends on but does not control, such as the partner CA's own certificate.

A leaked private key needs a faster path. The order service obtains a new certificate and asks the CA to revoke the old one. The PKI method leaves revocation checking to each authorization server's discretion, so the print lab may not notice the revocation by itself. Short certificate lifetimes, and the ability to suspend a client registration until a new certificate is in place, are the dependable controls. Tokens bound to the leaked certificate stay usable by whoever holds the key until they expire, so the print lab should also revoke those tokens where it can.

What the authorization server validates

For tls_client_auth, the print lab's TLS layer and its OAuth layer share the work:

1. The handshake proves the client holds the private key for the certificate it presented.
2. The certificate chains to a trust anchor configured for client certificates, here only Printlab Partner CA 1, and not to the general set of public CAs a browser trusts.
3. Each certificate in the chain is within its validity period, the client certificate permits TLS client authentication, and the issuers are permitted to act as CAs.
4. Revocation is checked, if this deployment checks it.
5. The registration for the client_id in the request uses this method, and the one subject value it names matches the certificate exactly.

The second step is easy to get wrong. If the server trusted every public CA for client authentication, anyone who could get any one of them to issue a certificate naming orders.printer.example, through a mistaken issuance or a briefly hijacked DNS name, could authenticate as the printer. Limiting client authentication to a small set of CAs whose issuing practices the server has accepted closes that path. The subject comparison needs care too. Distinguished names can be written in more than one equivalent way, so they have to be compared with consistent matching rules, not as raw strings.

For self_signed_tls_client_auth, there is no chain to build and no CA to trust. The handshake proves possession of the key, and the server checks that the certificate is exactly one of those registered for the client.

Certificate parsing and chain validation have a long history of subtle bugs, and the specification advises using an established, well-tested TLS or X.509 library rather than writing these checks by hand. The API's job remains much smaller: it compares one thumbprint, and leaves the rest to the authorization server that issued the token.