Microsoft Edge displays certificate errors on internal websites, why is that?

Microsoft Edge can show certificate warnings on internal corporate sites because newer Edge versions use a built-in root store and certificate verifier, and that verifier is stricter than the older platform-based behavior.

Common reasons include:

1. Verifier behavior changed in newer Edge versions
   • Starting in Edge 112, Windows and macOS devices default to the certificate verifier and certificate trust list shipped with the browser.
   • Enterprise-managed devices also moved to this behavior in Edge 112.
   • The temporary MicrosoftRootStoreEnabled policy existed to revert to the previous behavior, but support for that policy was removed in Edge 115.
2. Stricter RFC 5280 validation Edge’s built-in verifier is more strict about certificate correctness than the old verifier. Internal CA-issued certificates may now fail if they contain issues such as:
   • ECDSA algorithm parameters being present when they must be absent.
   • IP address name constraints encoded incorrectly.
   • An empty excluded list in Name Constraints.
3. Revocation checking differences
   • The newer verifier does not support LDAP-based CRL URIs.
   • If the environment enables RequireOnlineRevocationChecksForLocalAnchors and the CRLs are not valid per RFC 5280, Edge may show ERR_CERT_NO_REVOCATION_MECHANISM or ERR_CERT_UNABLE_TO_CHECK_REVOCATION.
   • If ERR_CERT_NO_REVOCATION_MECHANISM appears, the CRL returned by the certificate’s URI should be checked to confirm it is DER encoded, not PEM encoded.
4. Internal roots not in the Microsoft CTL Microsoft specifically recommends that enterprises with break-and-inspect proxies or other scenarios using TLS server certificates issued by roots not in the Microsoft CTL proactively identify compatibility issues. Internal enterprise PKI can fall into this category.
5. Certificate chain/path issues Certificate validation can also fail when a certificate has multiple trusted certification paths and the client can validate only one of them, while the server sends a different path. In that case, the browser can report that the certificate was not issued by a trusted authority even though a valid path exists in the environment.

If this affects internal sites, the practical checks are:

1. Inspect the internal site certificate and issuing chain.
2. Verify the certificate and CA chain comply with RFC 5280 requirements noted above.
3. Check whether CRL distribution points use LDAP and whether revocation responses are correctly encoded.
4. If the site depends on enterprise trust, review whether the needed CA certificates are being provided to Edge through supported certificate trust mechanisms and policies such as CACertificates, CACertificatesWithConstraints, CAHintCertificates, or CAPlatformIntegrationEnabled.
5. If the server presents multiple possible chains, verify the chain sent by the server matches a path trusted by client devices.

References:

• Changes to Microsoft Edge browser TLS server certificate verification
• Microsoft Edge - Policies
• Certificate validation fails when a certificate has multiple trusted certification paths to root CAs