When establishing a secure HTTPS connection with a server, a browser must validate that the certificate sent by the server is valid — that is to say, that:
- it’s non-expired (current datetime is within the validity period specified in the
notBefore
andnotAfter
fields of the certificate - that it contains the hostname of the target site in the
subjectAltNames
field - that it’s properly signed with a strong algorithm, and
- that either the certificate’s signer (Certificate Authority) is trusted by the system (Root CA) or that it chains to a root that is trusted by the system (Intermediate CA).
In the past, Chromium running on Windows delegated this validation task to APIs in the operating system, layering a minimal set of additional validation (e.g. this) on top of the verdict from Windows. As a consequence, Chromium-based browsers relied on two things: The OS’ validation routines, and the OS’ trusted root certificate store.
Starting in Edge version 109, Edge will instead rely on code and data shipped in the browser for these purposes — certificate chain validation will use Chromium code, and root trust determination will depend on a trust list generated by Microsoft and shipped with the browser.
Importantly: This should not result in any user-visible change in behavior for users. That’s true even in the case where an enterprise depends upon a private PKI (e.g. Contoso has their own Enterprise CA for certificates for servers on their Intranet, or WoodGrove Bank is using a “Break-and-Inspect” proxy server to secure/spy on all of their employee’s HTTPS traffic). These scenarios should still work fine because the browser will still check the OS root certificate store if the root certificate in the chain is not in the browser-carried trust list.
Q: If the outcome is the same, why make this change at all?
A: The primary goal is consistency — by using the same validation logic and public CA trust list across all operating systems, users on Windows, Mac, Linux and Android should all have the same experience, not subject to the quirks (and bugs) of the OS-provided verifiers or the sometimes- misconfigured list of OS-trusted CAs.
Please Preview ASAP
I’ve written before about the value and importance of practical time machines, and this change arrives with such a mechanism. Starting in Microsoft Edge 109, an enterprise policy (MicrosoftRootStoreEnabled) and a flag (edge://flags/#edge-microsoft-root-store-enabled) are available to control when the built-in root store and certificate verifier are used.
Please try these out, and if anything breaks in your environment, please report the issue!
Impatient optimist. Dad. Author/speaker. Created Fiddler & SlickRun. PM @ MSFT '01-'12, and '18-, working on Office, IE, Edge, and Web Protection. My words are my own, I do not speak for any other entity. View more posts