Microsoft Entra certificate-based authentication Certificate Revocation List (CRL)

A Certificate Revocation List (CRL) is a list of certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date. CRLs are essential for maintaining authentication integrity. When a certificate is revoked, it’s marked as untrusted even if not expired. Incorporating CRLs in certificate-based authentication ensures only valid, non-revoked certificates are accepted, and Microsoft Entra ID blocks any attempt using a revoked certificate.

CRLs are digitally signed by the CA and published to publicly accessible locations, allowing them to be downloaded over the internet to verify the revocation status of certificates. When a client presents a certificate for authentication, the system checks the CRL to determine if the certificate has been revoked.

If the certificate is found in the CRL, the authentication attempt is rejected. CRLs are usually updated periodically, and organizations should ensure they have the latest version of the CRL to make accurate decisions about certificate validity.

In Microsoft Entra certificate-based authentication (CBA), when CRLs are configured, the system must retrieve and validate the CRL during authentication. If Microsoft Entra ID cannot access the CRL endpoint, authentication fails because the CRL is required to confirm certificate validity.

How a CRL works in certificate-based authentication

A CRL works by providing a mechanism to check the validity of certificates used for authentication. The process involves several key steps:

• Certificate Issuance: When a certificate is issued by a CA, it is valid until its expiration date unless it is revoked earlier. Each certificate contains a public key and is signed by the CA.
• Revocation: If a certificate needs to be revoked (for example, if the private key is compromised or the certificate is no longer needed), the CA adds it to the CRL.
• CRL Distribution: The CA publishes the CRL to a location accessible by clients, such as a web server or a directory service. The CRL is typically signed by the CA to ensure its integrity.
• Client Check: When a client presents a certificate for authentication, the system retrieves the CRL for each CA in the certificate chain from its published locations and checks for any revoked CAs. If any CRL location is unavailable, authentication fails because the system cannot verify the certificate’s revocation status.
• Authentication: If the certificate is found in the CRL, the authentication attempt is rejected, and the client is denied access. If the certificate is not in the CRL, the authentication proceeds as normal.
• CRL Updates: The CRL is updated periodically by the CA, and clients should ensure they have the latest version to make accurate decisions about certificate validity. The system does cache the CRL for a certain period to reduce network traffic and improve performance, but it does also check for updates regularly.

Understanding the certificate revocation process in Microsoft Entra certificate-based authentication

The certificate revocation process enables Authentication Policy Administrators to revoke a previously issued certificate so it can't be used for future authentication.

Authentication Policy Administrators configure the CRL distribution point during the setup process for trusted issuers in the Microsoft Entra tenant. Each trusted issuer should have a CRL that you can reference by using an internet-facing URL. For more information, see Configure Certificate Authorities.

Microsoft Entra ID supports only one CRL endpoint and supports only HTTP or HTTPS. We recommend using HTTP instead of HTTPS for CRL distribution. CRL checks occur during certificate-based authentication, and any delay or failure in retrieving the CRL can block authentication. Using HTTP minimizes latency and avoids potential circular dependencies caused by HTTPS (which itself requires certificate validation). To ensure reliability, host CRLs on highly available HTTP endpoints and verify that they're accessible over the internet.

1. When a user performs an interactive sign-in with a certificate, Microsoft Entra ID downloads and caches the customer's certificate revocation list (CRL) from their certificate authority to check if certificates are revoked during the authentication of the user. Microsoft Entra uses the SubjectKeyIdentifier attribute instead of SubjectName to build the certificate chain. When CRLs are enabled, PKI configurations must include SubjectKeyIdentifier and Authority Key Identifier values to ensure proper revocation checking.

   SubjectKeyIdentifier provides a unique, immutable identifier for the certificate’s public key, making it more reliable than SubjectName, which can change or be duplicated across certificates. This attribute ensures accurate chain building and consistent CRL validation in complex PKI environments.

   Important

   If an Authentication Policy Administrator skips the configuration of the CRL, Microsoft Entra ID doesn't perform any CRL checks during the certificate-based authentication of the user. This behavior can be helpful for initial troubleshooting, but shouldn't be considered for production use.

   • Base CRL only: If only the base CRL is configured, Microsoft Entra ID downloads and caches it until the Next Update timestamp. Authentication fails if the CRL has expired and can't be refreshed due to connectivity issues or if the CRL endpoint doesn't provide an updated version. Microsoft Entra strictly enforces CRL versioning: when a new CRL is published, its CRL Number must be higher than the previous version.

     CRL Number ensures monotonic versioning, preventing replay attacks where an older CRL could be reintroduced to bypass revocation checks. By requiring each new CRL to have a higher version number, Microsoft Entra ID guarantees that the most recent revocation data is always used.

   • Base + Delta CRL: When both are configured, both must be valid and accessible. If either is missing or expired, certificate validation fails per RFC 5280 standards.

2. The user certificate-based authentication fails if a CRL is configured for the trusted issuer and Microsoft Entra ID can't download the CRL, due to availability, size, or latency constraints. This limitation makes the CRL endpoint a critical single point of failure, reducing the resiliency of Microsoft Entra ID’s certificate-based authentication. To mitigate this risk, we recommend using highly available solutions that ensure continuous uptime for CRL endpoints.

3. If the CRL exceeds the interactive limit for a cloud, the user's initial sign-in fails with the following error:

   The Certificate Revocation List (CRL) downloaded from {uri} has exceeded the maximum allowed size ({size} bytes) for CRLs in Microsoft Entra ID. Try again in few minutes. If the issue persists, contact your tenant administrators.

4. Microsoft Entra ID attempts to download the CRL subject to the service-side limits (45 MB in public Microsoft Entra ID and 150 MB in Azure for US Government).

5. Users can retry the authentication after a few minutes. If the user's certificate is revoked and appears in the CRL, the authentication fails.

   Important

   Token revocation for a revoked certificate isn't immediate because of CRL caching. If a CRL is already cached, newly revoked certificates aren't detected until the cache refreshes with an updated CRL. Delta CRLs typically include these updates, so revocation takes effect once the delta CRL is loaded. If delta CRLs aren't used, revocation depends on the base CRL’s validity period. Administrators should manually revoke tokens only when immediate revocation is critical, such as in high-security scenarios. For more information, see Configure revocation.

6. We don't support Online Certificate Status Protocol (OCSP) because of performance and reliability reasons. Instead of downloading the CRL at every connection by the client browser for OCSP, Microsoft Entra ID downloads it once at the first sign-in and caches it. This action improves the performance and reliability of CRL verification. We also index the cache so the search is much faster every time.

7. If Microsoft Entra successfully downloads the CRL, it caches and reuses the CRL for any subsequent usage. It honors the Next update date and, if available, Next CRL Publish date (used by Windows Server CAs) in the CRL document.

8. If the user's certificate is listed as revoked on the CRL, user authentication fails.

   

   Important

   Due to the nature of CRL caching and publishing cycles, it's highly recommended that, if there's a certificate revocation, you also revoke all sessions of the affected user in Microsoft Entra ID.

9. Microsoft Entra ID attempts to pre-fetch a new CRL from the distribution point if the cached CRL document is expired. If CRL has a "Next Publish Date" Microsoft Entra does a CRL pre-fetch even if the CRL in cache is not expired. As of now, there's no way to manually force or retrigger the download of the CRL.

   Note

   Microsoft Entra ID checks the CRL of the issuing CA and other CAs in the PKI trust chain up to the root CA. We have a limit of up to 10 CAs from the leaf client certificate for CRL validation in the PKI chain. The limitation is to make sure a bad actor doesn't bring down the service by uploading a PKI chain with a huge number of CAs with a bigger CRL size. If the tenant's PKI chain has more than 10 CAs, and if there's a CA compromise, Authentication Policy Administrators should remove the compromised trusted issuer from the Microsoft Entra tenant configuration. For more information, see CRL Pre-fetching.

How to configure revocation

To revoke a client certificate, Microsoft Entra ID fetches the certificate revocation list (CRL) from the URLs uploaded as part of certificate authority information and caches it. The last publish timestamp (Effective Date property) in the CRL is used to ensure the CRL is still valid. The CRL is periodically referenced to revoke access to certificates that are a part of the list.

If a more instant revocation is required (for example, if a user loses a device), the authorization token of the user can be invalidated. To invalidate the authorization token, set the StsRefreshTokensValidFrom field for this particular user using Windows PowerShell. You must update the StsRefreshTokensValidFrom field for each user you want to revoke access for.

To ensure that the revocation persists, you must set the Effective Date of the CRL to a date after the value set by StsRefreshTokensValidFrom and ensure the certificate in question is in the CRL.

The following steps outline the process for updating and invalidating the authorization token by setting the StsRefreshTokensValidFrom field.

# Authenticate to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All"

# Get the user
$user = Get-MgUser -UserPrincipalName "test@yourdomain.com"

# Get the StsRefreshTokensValidFrom property
$user.StsRefreshTokensValidFrom

The date you set must be in the future. If the date is not in the future, the StsRefreshTokensValidFrom property is not set. If the date is in the future, StsRefreshTokensValidFrom is set to the current time (not the date indicated by Set-MsolUser command).

Enforce CRL validation for CAs

When you upload CAs to the Microsoft Entra trust store, you don't need to include a CRL or the CrlDistributionPoint attribute. You can upload a CA without a CRL endpoint, and certificate-based authentication doesn't fail if an issuing CA doesn't specify a CRL.

To strengthen security and avoid misconfigurations, an Authentication Policy Administrator can require CBA authentication to fail if a CA that issues an end user certificate doesn't configure a CRL.

Enable CRL validation

1. Select Require CRL validation (recommended) to enable CRL validation.

   

   When you enable this setting, CBA fails if the end user certificate comes from a CA that doesn't configure a CRL.

2. An Authentication Policy Administrator can exempt a CA if its CRL has issues that need to be fixed. Select Add Exemption and choose any CAs to exempt.

   

3. CAs in the exempted list don't need to configure a CRL, and the end-user certificates they issue don't fail authentication.

   Select CAs and select Add. Use the Search text box to filter the CA lists and select specific CAs.

   

Guidance for setting up CRLs (base and delta CRL) for Microsoft Entra ID

1. Publish accessible CRLs:

   • Ensure your CA publishes both the base CRL and delta CRLs (if applicable) to internet-facing URLs accessible via HTTP.
   • Microsoft Entra ID can't validate certificates if CRLs are hosted on internal-only servers. The URLs should be highly available, performant, and resilient to prevent authentication failures due to unavailability.
   • Validate CRL accessibility by testing the CRL URL in a browser and using certutil -url for distribution checks.

2. Configure CRL URLs in Microsoft Entra ID:

   • Upload the CA public certificate to Microsoft Entra ID and configure the CRL distribution points (CDPs).
   • Base CRL URL: Contains all revoked certificates.
   • Delta CRL URL (optional but recommended): Contains certificates revoked since the last base CRL was published.
   • Use tools like certutil to verify CRL validity and troubleshoot certificate and CRL issues locally.

3. Set validity periods:

   • Set the base CRL validity period long enough to balance operational overhead and security (typically days to weeks).
   • Set the delta CRL validity period shorter (commonly 24 hours) to allow for timely recognition of revoked certificates.
   • Shorter delta CRL validity improves security by reducing the window where revoked certificates remain valid but increases issuance and distribution load.
   • The recommended 24-hour default validity for delta CRLs on Windows Servers is a widely accepted standard security and performance.
   • Microsoft Entra ID is designed to efficiently handle frequent delta CRL updates without performance degradation, and ongoing improvements help enhance this further.
   • Microsoft Entra ID applies throttling mechanisms to protect against DDoS attacks during delta CRL downloads, which can result in temporary errors like "AADSTS2205013" for a small subset of users.

4. Ensure high availability and performance:

   • Host CRLs on reliable web servers or content delivery networks (CDNs) to minimize delays or failures during retrieval.
   • Monitor CRL publication and accessibility proactively.

5. Protect against throttling and distributed denial-of-service (DDoS) attacks:

   • To protect Microsoft Entra ID services and users, throttling is applied to CRL fetch operations during high load or potential abuse.
   • Schedule CRL publication and expiration cycles during off-peak hours to minimize the likelihood of throttling impacting users.

6. CRL size management

   • Keep CRL payloads as small as possible, ideally by frequent delta CRL issuance and archival of old entries, to improve fetch speed and reduce bandwidth.

7. Enable CRL validation

   • Enforce CRL validation in Microsoft Entra ID policies to ensure revoked certificates are detected. For more information, see Enable CRL validation.
   • Consider temporary bypass of CRL checking only as a last resort during troubleshooting, with an understanding of the security risks.

8. Test and monitor

   • Perform regular tests to verify that CRLs are downloadable and recognized correctly by Microsoft Entra ID.
   • Use monitoring to detect and quickly remediate any CRL availability or validation issues.

CRL error reference

Frequently asked questions

This next sections cover common questions and answers related to Certificate Revocation Lists.

Is there a limit for CRL size?

The following CRL size limits apply:

• Interactive sign-in download limit: 20 MB (Azure Global includes GCC), 45 MB for (Azure US government, includes GCC High, Dept. of Defense)
• Service download limit: 65 MB (Azure Global includes GCC), 150 MB for (Azure US government, includes GCC High, Dept. of Defense)

When a CRL download fails, the following message appears:

"The Certificate Revocation List (CRL) downloaded from {uri} has exceeded the maximum allowed size ({size} bytes) for CRLs in Microsoft Entra ID. Try again in few minutes. If the issue persists, contact your tenant administrators."

Download remains in the background with higher limits.

We're reviewing the impact of these limits and have plans to remove them.

I see a valid Certificate Revocation List (CRL) endpoint set, but why don't I see any CRL revocation?

• Make sure the CRL distribution point is set to a valid HTTP URL.
• Make sure the CRL distribution point is accessible via an internet-facing URL.
• Make sure the CRL sizes are within limits.

How do I instantly revoke a certificate?

Follow the steps to manually revoke a certificate.

How can I turn certificate revocation checking on or off for a particular CA?

We recommend against disabling certificate revocation list (CRL) checking because you won't be able to revoke certificates. However, if you need to investigate issues with CRL checking, you can exempt a CA from CRL checking in the Microsoft Entra admin center. In the CBA Authentication methods policy, select Configure and then select Add exemption. Choose the CA that you want to exempt, and select Add.

After a CRL endpoint is configured, end users can't sign in and they see "AADSTS500173: Unable to download CRL. Invalid status code Forbidden from CRL distribution point."

When a problem prevents Microsoft Entra from downloading the CRL, the cause is often firewall restrictions. In most cases, you can resolve the issue by updating firewall rules to allow the required IP addresses so Microsoft Entra can successfully download the CRL. For more information, see List of Microsoft IPAddress.

Next steps

• Overview of Microsoft Entra CBA
• How to configure Microsoft Entra CBA
• Microsoft Entra CBA on iOS devices
• Microsoft Entra CBA on Android devices
• Windows smart card logon using Microsoft Entra CBA
• Certificate user IDs
• How to migrate federated users
• FAQ
• Troubleshoot Microsoft Entra CBA