Root Certificates on Windows
I’m far from a PKI expert so I won’t be going into much detail as a lot of information around certificates can be found through a web search. I spent a considerable amount of time debugging an issue related to certificates and the trusted root store on Windows and I didn’t find much documentation discussing this behavior so I’d figure I’d share.
The basic idea for websites, is there is a leaf certificate that is bound to website that secures the custom domain. It in turn (as long as its not a self-signed cert without any issuer) has a chain or mapping back to a Certificate Authority (CA) whether public or private often through an intermediate certificate. By default most OS’s or hardware will have a list of Certificate Authorities they trust out of the box. A certificate authority could be a public authority that is wildly trusted across the industry like Digicert, a private CA that an enterprise manages inside of their IT department, or even an authority I build for my personal use. The key is who will trust that authority.
For OS’s or browsers, each company will generally maintain a program where Certificate Authorities apply for approval to be added to the list of trusted CAs. Companies like Microsoft, Google, Apple, ect all have a program that CAs can apply and be added to the list that will be trusted in the base install of the OS or browser. Otherwise, the CAs would have to be explicitly installed on those devices to be trusted. If the CA is not trusted by your device or program you’ll often see the error below.
What I’ve seen confuse people (including myself) is certain CAs missing from the trusted root store on the Windows OS when its expected to be CA that is trusted. At the time of the writing of this blog in January 2022, there are a total of 514 CAs in the list trusted by Windows out of the box, but if you check the store on your personal machine you likely won’t see all 514 certificates. This is because Windows has the ability to download the CA cert on demand as needed.
The Automatic Root Certificates Update component is designed to automatically check the list of trusted authorities on the Microsoft Windows Update Web site. Specifically, there is a list of trusted root certification authorities (CAs) stored on the local computer. When an application is presented with a certificate issued by a CA, it will check the local copy of the trusted root CA list. If the certificate is not in the list, the Automatic Root Certificates Update component will contact the Microsoft Windows Update Web site to see if an update is available. If the CA has been added to the Microsoft list of trusted CAs, its certificate will automatically be added to the trusted certificate store on the computer.
https://docs.microsoft.com/en-us/security/trusted-root/participants-list
List of Microsoft trusted CAs: https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT
Microsoft Trusted CA Program: https://docs.microsoft.com/en-us/security/trusted-root/program-requirements
Chrome Trusted CA Program: https://www.chromium.org/Home/chromium-security/root-ca-policy
I went through an example where we navigated to https://www.army.mil which is signed by the ISRG Root X1 CA through the X3 Intermediate CA. Originally the CA was not added in my test VM’s trusted root store, after navigating to the URL it was then added to the Root Store. So the behavior I described below where the CAs are installed on demand as needed is what we observe.
The last part to mention is if you are not seeing a Certificate Authority in the list likely that CA has not applied to the respective program or is in the process of applying. Its up to the Certificate Authority owner to work with the larger organizations (Microsoft, Google, Apple, ect) to have their certificate added to their programs.