Certificate authentication bindings and limitations

This page's changes and edits · All guidance changes

Microsoft's edit · 7 Aug 2025 19:11 UTC

creating new CRL page

Microsoft's commit message in MicrosoftDocs/entra-docs · commit cb228ca · +0 ~~−73~~ lines · also on GitHub

⋯ 387 unchanged lines

388388

389389 Ensure that CBA in each tenant is configured with the Username Bindings pointing to the certificateUserIds field for the field types that you have mapped from the certificate. Now any of these users may present the certificate at sign-in and after the unique value from the certificate is validated against the certificateUserIds field, that user is successfully signed-in.

390390

391 −## Understanding the certificate revocation process

392 −

393 −The certificate revocation process allows Authentication Policy Administrators to revoke a previously issued certificate from being used for future authentication. The certificate revocation won't revoke already issued tokens of the user. Follow the steps to manually revoke tokens at [Configure revocation](./certificate-based-authentication-federation-get-started.md#step-3-configure-revocation).

394 −

395 −Microsoft Entra ID downloads and caches the customers certificate revocation list (CRL) from their certificate authority to check if certificates are revoked during the authentication of the user.

396 −

397 −Authentication Policy Administrators can configure the CRL distribution point during the setup process of the trusted issuers in the Microsoft Entra tenant. Each trusted issuer should have a CRL that can be referenced by using an internet-facing URL.

398 −

399 −>[!IMPORTANT]

400 −>The maximum size of a CRL for Microsoft Entra ID to successfully download on an interactive sign-in and cache is 20 MB in public Microsoft Entra ID and 45 MB in Azure US Government clouds, and the time required to download the CRL must not exceed 10 seconds. If Microsoft Entra ID can't download a CRL, certificate-based authentications using certificates issued by the corresponding CA fail. As a best practice to keep CRL files within size limits, keep certificate lifetimes within reasonable limits and to clean up expired certificates. For more information, see [Is there a limit for CRL size?](certificate-based-authentication-faq.yml#is-there-a-limit-for-crl-size-).

401 −

402 −When a user performs an interactive sign-in with a certificate, and the CRL exceeds the interactive limit for a cloud, their initial sign-in fails with the following error:

403 −

404 −"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."

405 −

406 −After the error, 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 US Government clouds).

407 −

408 −>[!IMPORTANT]

409 −>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 can be helpful for initial troubleshooting, but shouldn't be considered for production use.

410 −

411 −As of now, 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 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. Customers must publish CRLs for certificate revocation.

412 −

413 −The following steps are a typical flow of the CRL check:

414 −

415 −1. Microsoft Entra ID attempts to download the CRL at the first sign-in event of any user with a certificate of the corresponding trusted issuer or certificate authority.

416 −1. Microsoft Entra ID 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.

417 −1. The user certificate-based authentication fails if:

418 − - A CRL is configured for the trusted issuer and Microsoft Entra ID can't download the CRL, due to availability, size, or latency constraints.

419 − - The user's certificate is listed as revoked on the CRL.

420 −

421 − :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/user-cert.png" alt-text="Screenshot of the revoked user certificate in the CRL." :::

422 −

423 − - Microsoft Entra ID attempts to download a new CRL from the distribution point if the cached CRL document is expired.

424 −

425 −>[!NOTE]

426 −>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.

427 −If the tenant's PKI chain has more than 5 CAs, and if there's a CA compromise, Authentication Policy Administrators should remove the compromised trusted issuer from the Microsoft Entra tenant configuration.

428 −

429 −

430 −>[!IMPORTANT]

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

432 −

433 −As of now, there's no way to manually force or retrigger the download of the CRL.

434 −

435 −### How to configure revocation

436 −

437 −[!INCLUDE [Configure revocation](../../includes/entra-authentication-configure-revocation.md)]

438 −

439 −## Understanding CRL validation

440 −

441 −A CRL is a record of digital certificates that have been revoked before the end of their validity period by a certificate authority (CA).

442 −When CAs are uploaded to the Microsoft Entra trust store, a CRL, or more specifically the CrlDistributionPoint attribute, isn't required. A CA can be uploaded without a CRL endpoint, and certificate-based authentication won't fail if an issuing CA doesn't have a CRL specified.

443 −

444 −To strengthen security and avoid misconfigurations, an Authentication Policy Administrator can require CBA authentication to fail if no CRL is configured for a CA that issues an end user certificate.

445 −

446 −### Enable CRL validation

447 −

448 −To enable CRL validation, select **Require CRL validation (recommended)**.

449 −

450 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/require-validation.png" alt-text="Screenshot of how to require CRL validation." :::

451 −

452 −Once enabled, any CBA fail is because the end user certificate was issued by a CA with no CRL configured.

453 −

454 −An Authentication Policy Administrator can exempt a CA if its CRL has issues that should be fixed. Select **Add Exemption** and select any CAs that should be exempted.

455 −

456 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/exempt-validation.png" alt-text="Screenshot of how to exempt CAs from CRL validation." :::

457 −

458 −The CAs in the exempted list aren't required to have CRL configured and the end-user certificates that they issue don't fail authentication.

459 −

460 −Select CAs and select **Add**. The **Search** text box can be used to filter the CA lists to select specific CAs.

461 −

462 −:::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/exempted.png" alt-text="Screenshot of CAs that are exempted from CRL validation." :::

463 −

464391 ## Certificate Authority (CA) Scoping (Preview)

465392

466393 Certificate Authority (CA) Scoping in Microsoft Entra allows tenant administrators to restrict the use of specific certificate authorities (CAs) to defined user groups. This feature enhances the security and manageability of certificate-based authentication (CBA) by ensuring that only authorized users can authenticate using certificates issued by specific CAs.

⋯ 230 unchanged lines

Microsoft's Markdown source from MicrosoftDocs/entra-docs, © Microsoft Corporation, under MIT. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 10 Oct 03:46 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.