Certificate rotation rarely fails at the moment someone creates a new certificate. It fails in the gap between systems: one service starts signing with a new key, another still trusts the old metadata, a customer IdP has not refreshed its configuration, or an HTTPS endpoint is technically alive but no longer trusted by the client trying to reach it.
That is why certificate lifecycle work belongs in identity operations, not in a calendar reminder owned by one infrastructure engineer. In an identity platform, certificates are part of the availability model. They decide which tokens can be validated, which metadata can be trusted, and which external identity providers can still be reached.
Where certificates show up
For this discussion, keep the scope concrete: token signing, HTTPS, and external identity provider trust.
Token signing is the most visible identity-platform use case. A JWT is not trusted because it is JSON; it is trusted because the verifier can validate the JSON Web Signature. JWS defines the signed structure, and JWK defines how public keys can be represented as JSON Web Keys or JWK Sets.
OpenID Connect Discovery then makes those keys discoverable. The provider metadata includes a jwks_uri, and the OpenID Connect Discovery specification requires that URL to use HTTPS. Relying parties use the referenced JWK Set to validate signatures from the OpenID Provider.
HTTPS is the second trust surface. Discovery documents, token endpoints, user info endpoints, and remote metadata all depend on TLS server certificates. A token signing certificate might be perfectly valid while the metadata endpoint that publishes the public key is unavailable or no longer trusted.
External identity providers add a third surface. When ProAuth federates to a customer IdP, ProAuth has to trust the issuer, endpoints, and signing keys used by that external provider. For ADFS OAuth integrations, the ProAuth source supports configured signing certificates for an IdP instance and can also obtain signing information from the configured metadata endpoint when local certificate settings are not present. For generic OpenID Connect IdPs, ProAuth configures the external middleware with HTTPS metadata requirements enabled.
Those are different certificates with different owners, but they meet in the same runtime path: sign-in.
Why rotation becomes an outage
The hard part is overlap. A clean rotation has three live states for a while:
- the old private key may still sign tokens until the cutover;
- the new public key must be visible before the new private key is used;
- verifiers must retain the old public key until tokens signed before the cutover have expired.
If the new key appears too late, clients reject new tokens. If the old key disappears too early, clients reject still-valid tokens. If an external IdP rotates its signing certificate without metadata refresh or local trust updates, ProAuth can no longer validate the upstream response. If HTTPS certificates expire, the metadata and token endpoints may fail before application code sees an identity-specific error.
This is an operational problem because the failure mode looks like authentication itself is broken. Users cannot sign in. APIs reject tokens. Customer onboarding stalls. The fix may be simple once found, but the blast radius is usually broad.
How ProAuth narrows the problem
ProAuth keeps certificate management centralized instead of scattering signing material across each application. The ProAuth certificate management documentation describes certificate store entries for default certificates, OIDC token signing, ADFS OAuth token signing, and audit trail signing.
For signing use cases, ProAuth requires an X.509 leaf certificate with a matching private key. Public-certificate-only input is not valid for ProAuth signing certificates. When certificates are stored, ProAuth records certificate metadata such as thumbprint, validity dates, issuer, serial number, and subject from the X.509 certificate. That metadata is not a substitute for monitoring, but it gives operations teams the fields they need for inventory and expiry checks.
ProAuth also supports scope. The documentation describes tenant-level, subscription-level, and default certificate lookup for token signing. That gives operations teams a way to rotate signing certificates for a tenant or subscription without turning every application into a separate certificate owner.
The benefit is not magic rollover. It is a smaller and clearer control plane. Applications trust ProAuth as the issuer. ProAuth owns the signing material and the federation configuration. Customer IdP certificates remain part of the external trust relationship, but they are handled at the identity boundary rather than in every consuming service.
flowchart TD
A["Inventory certificates"]
B["Create replacement certificate"]
C["Publish new public key"]
D["Wait for metadata refresh"]
E["Switch signing to new certificate"]
F["Keep old public key until old tokens expire"]
G["Remove expired trust material"]
A --> B --> C --> D --> E --> F --> G
T["TLS endpoint certificate"] -. keeps metadata reachable .-> C
I["External IdP signing certificate"] -. keeps federation valid .-> DPlan the overlap, not just the date
A useful rotation plan starts with consumers, not certificates.
For ProAuth-issued tokens, list the applications and APIs that validate tokens. Confirm how they discover signing keys, how often they refresh metadata, and how long accepted tokens can live. OpenID Connect metadata and JWK Sets are built for this, but they are only effective if verifiers refresh them before the cutover and keep old keys long enough after it.
For HTTPS, list the identity endpoints that clients and external providers call. This includes discovery, token, user info, redirect, callback, and metadata endpoints. Certificate expiry monitoring should cover those hostnames directly, not only the underlying ingress or load balancer certificate object.
For external IdPs, record whether ProAuth trusts signing keys through provider metadata or through certificates configured on the IdP instance. Metadata-based trust still needs monitoring: the URL has to be reachable over HTTPS, and the provider’s published keys need to be refreshed before their previous keys vanish.
Operational checklist
Use a checklist that reflects the trust path:
- Inventory ProAuth certificate store entries by purpose, tenant or subscription scope, thumbprint, subject, issuer,
ValidFrom, andValidTo. - Monitor expiry dates for token-signing certificates and TLS certificates on all identity endpoints.
- Track external IdP signing-key sources: local configured certificates, metadata endpoints, issuer values, and HTTPS reachability.
- Create replacement signing certificates early enough to allow a real overlap window.
- Publish or expose the new public key before any service signs production tokens with the new private key.
- Verify metadata refresh behavior for applications and APIs that validate ProAuth-issued tokens.
- Keep the previous public key trusted until tokens signed before cutover can no longer be accepted.
- Rehearse rollback: know which certificate ProAuth should use again, which metadata clients will see, and which IdP configuration must be restored.
- For audit trail signing, do not remove expired certificates that are still needed to verify historical audit entries.
That last point is easy to overlook. Expired does not always mean disposable. If a certificate was used to verify historical data, deleting it can remove evidence needed later.
Centralization reduces certificate sprawl
The practical argument for central identity is not that certificates disappear. They do not. The argument is that the operating model becomes smaller.
Without a central identity provider, every application may need to manage customer IdP metadata, signing-key refresh, token validation configuration, and HTTPS trust decisions independently. With ProAuth in the middle, applications consume tokens from one issuer, while ProAuth handles tenant-specific federation and certificate-backed signing at the identity layer.
That still requires discipline: inventory, monitoring, overlap, rehearsal, and rollback. But it moves the discipline into one place where security and operations teams can reason about the whole trust chain.
For the implementation details, start with the ProAuth certificate management documentation. Treat the renewal date as a milestone, not the plan. The plan is the overlap.