Immediate answer
Rotate before expiry and preserve an overlap window.
Microsoft's application-certificate guidance recommends registering a new public certificate while the current credential is still valid, deploying the new private key to the application, verifying the new identity, and only then removing the old credential.
An abrupt replacement turns a planned maintenance task into an authentication outage. The exact product workflow matters: use the application's supported repair or rotation process instead of manually replacing certificate references, copying private keys, or changing the Entra registration in isolation.
Trust boundary
Microsoft receives public material; the application protects the private key.
For certificate-based client authentication, the application signs a client assertion with its private key. Microsoft Entra validates that assertion against public certificate material registered on the application. The private key should remain in the protected application environment and must never be uploaded with a PFX to the app registration.
| Artifact | Location | Protection objective |
|---|---|---|
| Public certificate | Entra app registration and approved exports | Correct application, thumbprint, validity, and controlled credential list |
| Private key | Application's protected certificate store or key service | Non-exportability where supported and access only for the service identity |
| Certificate reference | Application configuration | Points to the intended credential without embedding private material |
| Exchange authorization | Exchange service principal and App RBAC | Remains scoped independently of which valid certificate proves the app identity |
Early warning
Expiration should be an observed event, not a surprise.
Record the certificate owner, purpose, app registration, installation location, NotBefore, NotAfter, and recovery process. Alert through a channel that does not depend solely on the same SMTP path. Microsoft Entra recommendations can surface application credentials approaching expiration, subject to the tenant's licensing and feature availability.
Also monitor operational evidence: certificate presence, private-key accessibility, token-acquisition success, and the thumbprint used by recent sign-ins. A certificate can be time-valid yet unusable because it is in the wrong store, lacks a private key, or denies the service identity access.
Staged handoff
Use overlap to preserve rollback.
- 01
Create the replacement through the supported workflow
Use an appropriate key size, provider, validity period, private-key protection, and service-store location for the application.
- 02
Register only the new public certificate
Add the public
.ceror PEM material to the correct Entra app without deleting the working credential. - 03
Switch the application candidate
Update the application through its supported configuration or repair flow so the runtime can access the new private key.
- 04
Verify the complete path
Prove token acquisition, Exchange authorization, TLS, XOAUTH2, sender scope, and a controlled mail transaction where the product supports one.
- 05
Observe before retirement
Keep the old credential available for the planned rollback window, then remove it from Entra and local storage through controlled cleanup.
Uploading a new public certificate without making its private key available to the running service changes nothing. Pointing the service at a new private key before Entra trusts the matching public certificate breaks token acquisition.
Proof before deletion
Verify that the new credential—not merely either credential—was used.
Confirm the active application configuration and safe certificate reference, then inspect Microsoft Entra sign-in evidence for the credential used by the successful token request. Exercise service restart and reboot behavior so the test does not rely on an in-memory token or certificate handle left from before the change.
After the observation window, remove the old public credential from the app registration and retire the corresponding local certificate according to the product's cleanup policy. Re-test token acquisition after removal. Preserve change records without copying private keys or sensitive identifiers into tickets or public logs.
Failure isolation
An “expired certificate” symptom can occur at several layers.
| Evidence | Likely boundary | Check |
|---|---|---|
AADSTS700027 with expired-key text | Client assertion signature or registered credential | Certificate validity and public credential on the correct application |
| Certificate not found | Local application configuration | Store location, thumbprint/reference, service account, and installation |
| Private key unavailable | Local key access | Private-key presence, provider, ACL, and service identity |
| Token succeeds but SMTP fails | Exchange or SMTP boundary | App RBAC, sender scope, SMTP AUTH policy, XOAUTH2, and full server response |
Do not weaken TLS validation, introduce a client secret, or grant broad mail permissions as a shortcut around a certificate-lifecycle error.
Released product boundary
Use RelayBridge's Microsoft setup repair flow.
RelayBridge v1.0.0-rc.1 creates an RSA-2048 SHA-256 certificate with a one-year default validity and places its non-exportable private key in the Local Computer personal store. The application stores a reference rather than a PFX or private-key copy.
If the certificate expires, is removed, or becomes inaccessible, follow the supported Microsoft setup repair flow described in the identity and certificate documentation. Do not manually substitute a client secret, export the private key, or independently delete the active Entra credential. The generic overlap model above explains the security objective; it does not override the released product procedure.
Clarifications
Frequently asked questions.
Should the PFX be uploaded to Entra?
No. Register only public certificate material. The PFX contains the private key and belongs inside the protected application environment if that format is used at all.
Does a new certificate require new Exchange RBAC?
Normally the certificate proves the same application identity, while Exchange authorization remains attached to the application service principal. Still verify the complete effective configuration after the change.
Can the old certificate be deleted immediately after one successful test?
A single test may use a cached token or the wrong credential. Confirm the active reference, inspect sign-in evidence, exercise restart behavior, and retain a controlled rollback window before retirement.
Authoritative sources