A new certificate on disk does not prove that a service is presenting it. In a system with Vault Agents, proxy layers, and rootless containers, certificate issuance and certificate activation belong to different processes.

My infrastructure uses separate service identities and per-application agents. That makes permissions easier to reason about, but it creates a handoff that needs its own checks.

Follow the artifact through the system

The path I care about is:

issuer → rendered files → service-readable files
       → process reload → certificate presented to a client

Each arrow can fail independently. An agent can issue a valid leaf certificate while writing it somewhere the service does not read. A file can have the right contents and the wrong ownership. A process can continue using the certificate it loaded hours earlier.

Checking only the issuer gives evidence for the first step. Checking the public endpoint gives evidence for the final step. Troubleshooting becomes much faster when the intermediate steps are visible too.

Keep environment and identity attached

The infrastructure configuration models environments and application identities separately. A replacement certificate must preserve that distinction.

A certificate from the correct CA is still the wrong artifact if its name or intended service differs from the consumer. Similarly, a test-environment chain should not become trusted in production merely because its files have familiar names.

The useful verification record includes the expected identity, serial or fingerprint, validity interval, and chain. Those values make it possible to compare what was issued with what a client receives.

File replacement and process activation are separate decisions

An atomic file replacement can prevent a reader from seeing a partially written certificate. It cannot make multiple services reload simultaneously, nor can it make a certificate and a separately written private key an atomic pair by itself.

The deployment mechanism needs a consistent publication boundary for related material and a controlled activation step. That can be a service-specific reload or a restart, depending on the consumer. The important part is to test the actual consumer after activation.

For rootless workloads, certificate access also needs deliberate ownership. Giving a service access to an entire certificate authority directory just to read one key expands its permissions unnecessarily.

Test the application handshake

A TLS connection is more useful than a process-is-running signal, but the check still needs the right hostname and trust roots. An mTLS endpoint additionally needs an appropriate client identity.

I want the check to fail for the same reason a real client would fail. Disabling verification to make a probe green removes exactly the evidence the rotation needs.

A completed rotation means the intended service presents the replacement identity and the intended client can verify it. Issuance logs, rendered files, and service logs explain how that result was reached; they do not replace it.