Skip to main content
AppAlert

Entra app registration certificate expired

Reviewed

On this page
Credential type
Client Auth Certificate
Resource type
Application
Blast radius
Workloads authenticating with this certificate
Likely first responder
Application operations team
Suggested owner
Application owner and certificate administrator
Suggested planning buffer
30 calendar days

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, plus User.Read for 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

  1. Provision a replacement certificate and protect its private key.
  2. 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.
  3. Record the new thumbprint shown in the portal. Switch each workload to the replacement certificate and private key.
  4. Confirm fresh, successful sign-ins use the new thumbprint for every workload, including scheduled jobs.
  5. 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.

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.