A replacement certificate must work as the same authorised client

A certificate expiry date can be easy to record and difficult to act on. The next maintainer needs more than a reminder to replace a file. They need to know which client uses it, what the receiving service trusts and how to verify the replacement without disabling the protections that rejected it.

This fictional handover uses an isolated supplier-document connection and test credentials. No real certificates, secrets, provider settings or accounts were changed.

Identify what the certificate does

The connector retrieves authorised documents for account A-14. Its TLS connection requires client-certificate authentication. The provider's inspected test arrangement validates the certificate chain and validity, then checks a registered certificate fingerprint associated with the approved client principal.

The current certificate C-1 expires on 15 November in the fictional test calendar. C-2 is valid from 10 November, has its own protected private key and is intended to authenticate the same principal. The provider explicitly supports a temporary overlap in which both approved fingerprints can be registered for that principal.

These are facts of the invented arrangement, not a universal certificate-rotation feature. TLS 1.3 specifies client certificate exchange and proof of possession; the receiving service's account registration and overlap procedure still need their own documentation.

Keep identity separate from the file change

The handover records the endpoint, client principal, permitted account, issuer chain, validity interval and secret-store references. It contains no private-key material. The replacement must satisfy the expected trust and authentication requirements while retaining the existing account permissions.

A new certificate that successfully authenticates as a different client would not be an acceptable rotation. Nor would a test that succeeds only after certificate verification is disabled. Both could conceal an access change behind an apparently healthy connection.

The maintainer also confirms how the connector selects the credential. Updating a stored secret is insufficient if the running process continues using a previously loaded certificate. The documented reload and fresh-connection procedure belongs in the handover.

Rehearse the supported overlap

In the controlled example, the authorised provider administrator registers C-2 alongside C-1. The maintainer selects C-2 through the approved secret reference and uses the supported reload operation.

The acceptance check opens a fresh authenticated connection, avoiding an old resumed session as evidence for the new credential. The receiving test record identifies C-2's fingerprint and the original client principal. The connector retrieves a permitted document for A-14, whose expected hash matches the known fixture.

An attempt to retrieve account A-15's document remains denied. Authentication as the intended client has not expanded its business permissions. A separate wrong-issuer certificate is rejected, and a controlled expired-certificate fixture fails the required validity check. The team does not modify the clock or trust settings of a live service to create those tests.

Close the overlap deliberately

After the new connection and access checks pass, the authorised administrator removes C-1's registration under the documented procedure. A fresh attempt with C-1 is now refused in the test environment. A new connection with C-2 still retrieves A-14's permitted document and still cannot retrieve A-15's.

The recorded result is therefore more than “the connector is green”. It establishes which credential was accepted, which identity it represented, which permitted task worked and which access remained unavailable.

Removing a registered certificate is not assumed to end every pre-existing connection. The inspected procedure specifies how connections are drained or restarted, and the acceptance record states which fresh-connection checks were performed. The next maintainer should not infer a broader session-revocation guarantee from them.

Give the next person the decision path

The final handover contains the certificate inventory, validity reminders, authorised roles, protected secret references, overlap instructions, reload procedure and expected observations. It explains what to do if C-2 fails before C-1 is retired: stop the transition and investigate within the permitted overlap, rather than weaken verification.

A compromised credential would require the organisation's incident procedure, not this ordinary planned replacement. Future issuer, endpoint or authentication changes also need reassessment. The working example does not certify the entire integration's security.

The receiving maintainer completes the controlled rehearsal and signs off the documented steps. No production rotation is claimed. The outcome is a procedure they can explain and repeat under the appropriate authorisation.

Use the migration and handover service to identify these operational dependencies before ownership changes. The support page helps define who maintains the inventory and handles a failed renewal after delivery.