What breaks
When an Entra app registration certificate expires, workloads that still sign with it risk failing new token requests. Renew the public certificate and switch each workload to its replacement key. See Microsoft's certificate credential model.
Know before the next app certificate expires
AppAlert emails your admins before app registration certificates expire. Read-only, free during Early Access. Connect read-only
- Read-only permissions
- Microsoft Graph application permissions
Application.Read.All,Directory.Read.All,AgentIdentity.Read.All,AgentIdentityBlueprint.Read.All,AgentIdentityBlueprintPrincipal.Read.All, plusUser.Readfor sign-in. No write permissions: AppAlert cannot create, rotate, or delete credentials. - Never received
- Secret values, certificate private keys, Microsoft account passwords, and mailbox contents. AppAlert stores credential metadata such as type, expiry date, and owner email addresses.
- Where data lives
- App functions and database in Frankfurt, Germany (Vercel fra1, Neon on AWS eu-central-1). Alert emails are sent through Resend, which stores them in the United States. Data location
- Revoke any time
- A Microsoft Entra administrator can revoke AppAlert's enterprise application consent. That stops future directory reads; deleting stored data is a separate request. Retention and revocation
How you notice
Open the app registration's Certificates & secrets page, then Certificates, following Microsoft's credential instructions. Compare the registered certificate's thumbprint and expiration with the certificate each workload presents.
Gather evidence of which certificate each workload uses. Follow Which Entra app credential is this workload using? for the log fields and steps. A newly uploaded certificate does not prove a workload uses it.
If a token request fails with AADSTS700027, the client assertion failed signature validation. Compare the certificate the workload signs with against the app registration's certificates. This code alone does not prove expiry.
How do I find certificates that expire soon?
For a single app, Azure CLI lists certificate metadata:
az ad app credential list --id '<app-id>' --cert --output table
For all app registrations, run this snippet in an authenticated Microsoft Graph PowerShell session. It checks keyCredentials against the certificate's endDateTime.
$WarningDays = 30
$Cutoff = [DateTimeOffset]::UtcNow.AddDays($WarningDays)
Get-MgApplication -All -Property @('appId', 'displayName', 'keyCredentials') -ErrorAction Stop |
ForEach-Object {
$App = $_
foreach ($Credential in $App.KeyCredentials) {
if ($null -eq $Credential.EndDateTime) { continue }
$End = [DateTimeOffset][DateTime]::SpecifyKind($Credential.EndDateTime, 'Utc')
if ($End -le $Cutoff) {
[pscustomobject]@{
App = $App.DisplayName
AppId = $App.AppId
KeyId = $Credential.KeyId
EndDateTime = $End.UtcDateTime.ToString('o')
}
}
}
}
Set $WarningDays to your renewal lead time. This example includes expired certificates and skips missing expiry dates. Review those entries separately.
Use Monitor credential expiry for recurring checks. See App secret expiration notifications for notification options.
Why it happens
The app signs a JWT client assertion with its private key. The assertion header carries x5t#S256, the certificate's SHA-256 thumbprint. Microsoft describes this in the certificate credential model.
Uploading a replacement does not switch the workload's signing key. Every workload using the old certificate needs to switch before it expires.
Renewal path
Keep the old certificate registered while you add and verify its replacement. An app registration can hold several certificates because keyCredentials is multi-valued, as described in the certificate credentials reference.
The commands follow Microsoft's documentation and were not run against a real environment.
Choose one tool to register the replacement. Replace the placeholders before running a sample. Keep private keys in the approved key store.
In the Entra admin center
- Provision a replacement certificate and protect its private key.
- Open App registrations, select the app, then go to Certificates & secrets, Certificates, Upload certificate. Upload the public certificate as a .cer, .pem or .crt file, following Microsoft's upload instructions.
- Record the new thumbprint shown in the portal. Switch each workload to the replacement certificate and private key.
- Confirm fresh, successful sign-ins use the new thumbprint for every workload, including scheduled jobs.
- Remove the old certificate only after every workload has switched and been verified.
For production, Microsoft recommends a CA-signed certificate with Azure Key Vault managing access and lifetime in its credential guidance.
Azure CLI
Use az ad app credential reset with --append to add the public certificate from cert.pem. The flag appends instead of overwriting existing credentials.
az ad app credential reset --id '<app-id>' --cert '@cert.pem' --append --output none
Microsoft Graph PowerShell
Add-MgApplicationKey wraps Graph addKey. The operation requires a proof JWT signed with the private key of an existing valid certificate. Supply only the replacement's public key.
Replace <proof-jwt> with a proof prepared as described in that reference. Keep it out of logs. This sample reads a DER-encoded public .cer file:
$Body = @{
keyCredential = @{
type = 'AsymmetricX509Cert'
usage = 'Verify'
key = [System.IO.File]::ReadAllBytes('<public-certificate-path>')
}
passwordCredential = $null
proof = '<proof-jwt>'
}
$NewKey = Add-MgApplicationKey -ApplicationId '<application-object-id>' `
-BodyParameter $Body -ErrorAction Stop
Remove-Variable Body
Graph API
Send this addKey request through an authenticated client. Replace <base64-public-certificate> with the Base64-encoded public certificate and <proof-jwt> with the proof JWT. Keep request bodies out of logs.
POST https://graph.microsoft.com/v1.0/applications/<application-object-id>/addKey
Content-Type: application/json
{
"keyCredential": {
"type": "AsymmetricX509Cert",
"usage": "Verify",
"key": "<base64-public-certificate>"
},
"passwordCredential": null,
"proof": "<proof-jwt>"
}
If no certificate is valid, including when all certificates have expired, addKey cannot run. Use the portal upload path or Update application with keyCredentials instead. Read the current collection first and retain any certificates you still need.
Verify each workload and remove the old certificate
Switch every workload to the replacement private key. Test fresh authentication, including scheduled jobs, before removal. Use the old key ID with Azure CLI:
az ad app credential delete --id '<app-id>' --key-id '<old-key-id>' --cert
Graph removeKey also verifies proof of possession of an existing key. Plan that proof before choosing Graph for removal.
Who should own it
Have the application owner coordinate issuance and deployment. Record who can access the key store and who can change the app registration.
Lead time and business-day math
Suggested planning buffer: 30 calendar days. Reserve working days for issuance, access approvals, deployment, and verification before the expiry date.
Related failure modes
- A SAML signing certificate supports a different authentication flow.
- An expired client secret affects workloads that authenticate with a secret.
- An owner leaving without handing over credentials can leave renewal work without a responsible team.
- The Microsoft Entra Connect Sync authentication certificate is an app certificate with its own rotation process.
Monitored by AppAlert
Monitored
AppAlert monitors client authentication certificate expiry and sends email alerts to configured admin recipients before a certificate expires, with optional routing to application owners.
Expiration tracking does not prove the running workload uses the replacement certificate.
Use the Operations queue to review the expiry and application context. Configure who receives alerts in Alert settings and recipients; for a missing alert, follow Missing notifications.