Microsoft Entra certificate-based authentication (CBA) gives you phishing-resistant sign-in with X.509 certificates from your own PKI, without AD FS. When it fails, the error code tells you which stage broke: trust, revocation checking, or matching the certificate to a user. In this post I'll map each common error to its stage, fix the configuration behind it and show how to prove CBA works.
Errors this guide fixes
AADSTS500173: Unable to download a Certificate Revocation List (CRL). Invalid status code {code} from CRL distribution point.Sign-in page / Microsoft Entra sign-in logAADSTS220501: Unable to download Certificate Revocation List (CRL). Invalid response or no response from CRL Distribution PointSign-in page / Microsoft Entra sign-in logAADSTS500179: CRL validation timed out. Please try again later.Sign-in page / Microsoft Entra sign-in logAADSTS2205015: The Certificate Revocation List (CRL) failed signature validation.Sign-in page / Microsoft Entra sign-in logAADSTS500176: The certificate authority that issued your certificate hasn't been set up in the tenant.Sign-in page / Microsoft Entra sign-in logAADSTS500172: Certificate '{name}' issued by '{issuer}' is not valid.Sign-in page / Microsoft Entra sign-in logAADSTS500171: Certificate has been revoked. Please contact your administrator.Sign-in page / Microsoft Entra sign-in logAADSTS50192: No Credential was included in the sign-in request.Sign-in page / Microsoft Entra sign-in log
Symptoms#
The user enters a username, selects Use a certificate or smart card, picks a certificate and gets an error instead of a session, or the certificate picker never appears. Typical messages:
AADSTS500173: Unable to download a Certificate Revocation List (CRL). Invalid status code {code} from CRL distribution point.
AADSTS220501: Unable to download Certificate Revocation List (CRL). Invalid response or no response from CRL Distribution Point {source}
AADSTS500179: CRL validation timed out. Please try again later.
AADSTS2205015: The Certificate Revocation List (CRL) failed signature validation.
AADSTS500176: The certificate authority that issued your certificate hasn't been set up in the tenant.
AADSTS500172: Certificate '{name}' issued by '{issuer}' is not valid.
AADSTS500171: Certificate has been revoked. Please contact your administrator.
AADSTS50192: No Credential was included in the sign-in request.Why it happens#
A CBA sign-in passes through four checks, and each produces its own errors:
| Stage | What Entra ID does | Errors |
|---|---|---|
| Certificate delivery | The client sends the certificate in the TLS handshake to *.certauth.login.microsoftonline.com | 50192 when a proxy or TLS inspection strips it |
| Trust | Builds the chain to a CA in the tenant's trust store, using the Subject Key Identifier rather than the subject name | 500176, 2205015 |
| Revocation | Downloads and caches the CRL of every CA in the chain (up to 10 CAs); one CRL endpoint per CA, HTTP or HTTPS | 500173, 220501, 500179, 500172, 500171 |
| User and strength | Username binding maps a certificate field to a user attribute; authentication binding decides single-factor or MFA | Wrong or no user found; MFA still required afterwards |
CRL limits cause many failures: an interactive sign-in can only use a CRL up to 20 MB (45 MB in the US Government clouds) that downloads within 10 seconds. If a CRL is configured but can't be downloaded, every certificate from that CA fails.
How to fix it#
1. Read the failed sign-in#
In Entra ID › Monitoring & health › Sign-in logs, open the failure and note the error code and the certificate details. The log shows which binding was used, and under Additional Details, Is Legacy Store Used is 1 when the classic CA store rather than the PKI-based store was involved.
2. Fix the trust store#
Microsoft recommends the PKI-based trust store (up to 250 CAs, 8 KB each) over the classic list. With the Privileged Authentication Administrator role, open Public key infrastructure in the Microsoft Entra admin center (Learn lists it under Entra ID › Identity Secure Score), select Create PKI, then Add certificate authority for the root and every intermediate, marking which one is the root and entering the Certificate Revocation List URL and, if you publish one, the delta CRL URL. Uploading a whole .p7b needs Microsoft Entra ID P1 or P2 and can take up to 30 minutes.
For 2205015, the CRL was signed by a key that doesn't match the CA you uploaded: the CA certificate's Subject Key Identifier must equal the CRL's Authority Key Identifier. To check the whole configuration, install the MSIdentityTools module, connect with Connect-MgGraph and run Test-MsIdCBATrustStoreConfiguration. Ignore older guidance that uses New-AzureADTrustedCertificateAuthority; that module is retired.
3. Fix the CRL#
Test the CRL URL from outside your network, exactly as configured:
$url = "http://crl.contoso.com/ContosoIssuingCA.crl"
Invoke-WebRequest -Uri $url -OutFile .\issuing.crl -TimeoutSec 10
"{0:N1} MB" -f ((Get-Item .\issuing.crl).Length / 1MB)
certutil -dump .\issuing.crl # check Next Update, CRL Number and the Authority Key Identifier- HTTP error such as 403 Forbidden (
500173): usually a firewall in front of the CRL host; allow the Azure IP ranges Microsoft publishes. - No response or out of date (
220501,500172): check the certificate's own validity dates, then the CRL; if Next Update is in the past, renew and republish it. Base and delta CRLs must both be valid. - Timeouts (
500179): shrink the CRL by cleaning up expired certificates and using delta CRLs, and host it on a highly available HTTP endpoint. Microsoft recommends HTTP over HTTPS to avoid a circular certificate check. - Versioning: Entra ID strictly requires each new CRL to carry a higher CRL Number than the last.
4. Fix the user match#
By default, the certificate's Principal Name is matched to userPrincipalName. Under Entra ID › Authentication methods › Certificate-based authentication › Configure, username bindings are tried in priority order. High-affinity bindings such as SKI or issuer and serial number use certificateUserIds, with values like X509:<I>DC=com,DC=contoso,CN=ContosoIssuingCA<SR>b24134139f069b49997212a86ba0ef48. Issuer and subject are written in reverse order without spaces, and the serial number is the byte-reversed sequence certutil -dump -v prints under it, without spaces. Set the attribute in the admin center or Graph for cloud users; for synced users, flow it from Active Directory with Entra Connect.
5. Fix "MFA still required"#
Certificates count as single-factor by default. Add an authentication binding rule by issuer, policy OID, or both, set to Multifactor authentication; a policy OID rule beats an issuer rule. Enter the OID in dotted form, for example 2.5.29.32.0 rather than "All Issuance Policies". More in MFA sign-in errors.
6. Fix certificate delivery#
For 50192, allow *.certauth.login.microsoftonline.com through proxies and turn off TLS inspection for it, so the client certificate survives the handshake.
Verify the fix#
- Allow up to an hour after a policy change; the authentication methods policy is cached.
- Sign in to the My Apps portal as a pilot user, choose the certificate and land in the portal.
- The sign-in log shows success, the expected binding, MFA satisfied where your rules require it, and Is Legacy Store Used
0. - Revoke a test certificate and publish the CRL. Once Entra ID refreshes its cached copy (you can't force it), that certificate fails with
500171.
Prevent it next time#
- Turn on Require CRL validation (recommended), and use Add Exemption only briefly while you fix a CA.
- Monitor CRL publication and expiry like a production service: an unreachable CRL blocks every user of that CA.
- Scope CBA to groups who actually hold certificates, never All users; users in scope can't use identity proof to register other methods.
- Revocation isn't instant because CRLs are cached, so revoke the user's sessions as well when you revoke a certificate.

