Many of the root certificates on Windows are not needed
For folks discovering this: Unfortunately, this isn’t a good idea, and can seriously harm your system.<p>I’ll be the first to tell you that I believe Google and Mozilla have done a lot for supervising TLS, but realize that the trust stores contain many other non-TLS purposes, and with the CAs constrained from TLS issuance (e.g. only trust for S&#x2F;MIME).<p>CryptoAPI, for its warts, is actually beautifully engineered, in that Microsoft has had the ability to add arbitrary constraints and properties to certificates from the very first release (via CERT_PROP_IDs). You don’t really see these in the UI; you only find out about them in WinCrypt.h, or via debugger stepping. However, it means that even if the UI is showing “trusted for TLS”, Microsoft may have disabled trust for TLS via the extended properties, which their APIs respect, and which are delivered through authroots.cab<p>You can see a little bit about this at <a href="https:&#x2F;&#x2F;github.com&#x2F;crtsh&#x2F;certwatch_db&#x2F;issues&#x2F;69" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;crtsh&#x2F;certwatch_db&#x2F;issues&#x2F;69</a> and <a href="http:&#x2F;&#x2F;unmitigatedrisk.com&#x2F;?p=259" rel="nofollow">http:&#x2F;&#x2F;unmitigatedrisk.com&#x2F;?p=259</a><p>Approaches like the OP link fail to take that into consideration, and can easily break core OS services, non-TLS cases like code signing or S&#x2F;MIME, or even reintroduce trust in CAs that Microsoft has programmatically disabled.