Windows Certificate Manager does not display the complete trust list

[geographomics]

You can also use certutil to grab all the trusted root certificates from the Windows Update server:

    certutil -generateSSTFromWU roots.sst

Then open roots.sst (which defaults to viewing in certmgr) and it will show the whole lot. Or use certutil -syncWithWU to get all the certs individually.

Alternatively: download http://ctldl.windowsupdate.com/msdownload/update/v3/static/t... [1], extract the authroot.stl file (which is in PKCS#7 format), use 'certutil -dump' to list all the subject key identifiers therein, and then download them from the same location as authrootstl.cab by appending ".crt" to the identifier.

Windows is not lying about anything, you just need to look in the right place.

Also, if you want to examine the CTL list that Windows is currently using - which should be identical to the one above unless it's brand new or there has been a problem downloading it - this will extract it from the registry:

    powershell -Command "[IO.File]::WriteAllBytes('authroot-local.stl',(Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate').EncodedCtl)"

Then use 'certinfo -dump' or whatever you like, it's exactly the same format as the downloaded authroot.stl. This is the same registry data that the OP's CTLInfo tool examines.

[1] as specified in https://support.microsoft.com/en-us/kb/2677070

[mattkrea]

The bigger takeaway from this is with a system like this (fully managed by Windows Updates).. how can you remove certificates you don't trust?

Latest documentation for this seems to be for IE 5. I sure as hell like to run dkpkg-reconfigure ca-certificates every once in a while after some roots get compromised and don't trust Microsoft to be on the ball.

[brudgers]

One feature of Windows is defaulting to not showing messy complexity to the user. The other feature is defaulting to backward compatibility. Combined, this means that Windows often has more than two data stores for some aggregate feature [e.g. web browser security, software configuration etc.] as new versions of Windows implement these features in more robust ways.

So yeah there are two or more places where certificates are stored. Typical users only care about the abstraction of web security so that's what Windows surfaces. Application developers should choose the new store for new applications. Existing applications can use the old method. System administrators and security consultants should make themselves familiar with all the documentation and double their rates.

Bloggers, however, are still free to write linkbait headlines using the Windows bashing meme.

[UnoriginalGuy]

The problem with your argument is that this is an administrative GUI that isn't even normally presented to end users unless you search for it or know how MMC snap-ins work. It is a power-user interface by all measure.

And while Microsoft does simplify UIs for end users, they don't typically do the same for administrative content (just look at anything in the Admin Tools, or MMC snap-ins, no sugar coating there).

Your argument about backwards compatibility is at best confusing. What does the data stores utilised have to do with UI representations of the same? I can name numerous examples where things changed behind the scenes and the UI was just updated to support it (e.g. Disk Manager now supports ESP, and exFat, same UI, ConHost now supports Powershell, same UI, Defrag now supports Trim for SSDs, same UI, etc).

> So yeah there are two or more places where certificates are stored. Typical users only care about the abstraction of web security so that's what Windows surfaces.

No, it doesn't. As the blogpost clearly shows it doesn't "surface" all root CAs usable by websites.

> Application developers should choose the new store for new applications. Existing applications can use the old method.

Huh? What do application developers have to do with this? I don't see the connection. This isn't talking about the custom root CAs you may install, it is talking about Microsoft's list of preinstalled ones.

> System administrators and security consultants should make themselves familiar with all the documentation and double their rates.

Please link to the documentation about this on Microsoft's site.

> Bloggers, however, are still free to write linkbait headlines using the Windows bashing meme.

Aside from the word "lying" (which is emotive), the title is largely accurate. Windows does mislead about installed trusted root CAs. And nothing you've said in this apologist answer has come close to addressing that, you're just dancing around it.

[vtlynch]

"Typical users only care about the abstraction of web security so that's what Windows surfaces."

Typical users do not open certmgr.msc

[TazeTSchnitzel]

Windows isn't lying. Microsoft openly lists what certificates Windows includes on their site. The fact the root certificate store on your machine only lists certificates it actually contains is to be expected.

This is just a UI failure.

[dtech]

Yep, they release a periodical PDF with interim updates [1]. Only the most lazy "security researcher" would believe that Windows only trusts two dozen root certificates.

[1]: http://social.technet.microsoft.com/wiki/contents/articles/1...

[pandog]

But there's a difference between looking at the list of root certificates that Microsoft say Windows trusts and looking at the list of root certificates that Windows trusts.

[nailer]

So roots are dynamically fetched and this is the list of previously fetched roots? Or is it a revocation check before first use? Do you have a link?

[tellthetruth1]

When an American company lies, it's only a UI failure.

[iancarroll]

If you're interested in seeing new roots, Microsoft has started posting all updates to the cabfpub mailing list:

https://cabforum.org/pipermail/public/2015-August/005847.htm...

[Animats]

What seems to be happening with Windows is that Microsoft is making the machine more a slave of their services with each new release. It's as if they're trying to catch up with Chromebooks, which are totally slaved to Google. Especially since Windows 10 is free with ads. Treating the local certificate store as a cache to the main certificate store at Microsoft HQ is consistent with this.

How difficult it is to hijack the link between the local and remote certificate stores? That's a potential attack surface. It's not hard-coded; it's a registry key (Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate). The default URL is "ctldl.windowsupdate.com".

So what protects that domain from being hijacked via DNS poisoning? It ought to have a valid SSL cert, right? Well, no. Go to "https://ctldl.windowsupdate.com/":

    ctldl.windowsupdate.com uses an invalid security certificate.

    The certificate is only valid for the following names:
    a248.e.akamai.net, *.akamaihd.net, *.akamaihd-staging.net,
    *.akamaized.net, *.akamaized-staging.net  
    (Error code: ssl_error_bad_cert_domain)

Uh oh. Am I missing something, or are root certs downloaded over an unsecured channel?

[geographomics]

They are transmitted over an unencrypted channel, but the CTL files themselves (authroot.stl and disallowedcert.stl) are signed by Microsoft so it's fine. Any modification in transit can be detected and presumably will cause them not to be updated.

[nota_bene]

Isn't the first question to ask "Can I trust Windows?" (and the answer "no", for all the obvious reasons)?

[wfunction]

Is this really true? When I navigate to https://certplusrootcag1-test.opentrust.com/ I see the root certificate is "Certplus Root CA G1", not "OpenTrust Root CA G1"...

[setyfse4]

It is "CertplusRoot CA G1" in my system too. This CA was added recently (http://www.infoworld.com/article/2941594/security/microsoft-...).

[Animats]

The Edge browser doesn't display certificate data at all. This has been discussed on the CAB forum mailing list recently.

[FreeHugs]

    CTLInfo is the result of a few sleepless nights spent
    understanding and reverse engineering some of the CTL
    obscure format

I wonder what the reason is to use a userunfriendly system like Windows and then spend hours and hours fighting it?

No matter how much time you put in, you will never win against an OS that is working against your interests.

[eli]

You're reading Hacker News and you want to know why someone would bother reverse engineering a closed source platform?

[philtar]

1) Because MSFT provides great corporate support for desktops. Keyword: great. Not good. Great.

2) Because people are used to it.

3) Because Office products are the de facto standard, and they run best on windows.

I could go on, but you get the point.

[johnminter]

I'll add to philtar's comment:

Because senior management forces workers to use it.

I'm a scientist who analyzes large data sets. I also need to communicate to my co-workers. I need a secure operating system without a lot of eye-candy that makes it look like a tablet and lets me give priority to my data analysis tasks. Windows is not it, but I have to use it.

[6d0debc071]

For fun, to illustrate that it can't be trusted, because what you want to use isn't available for the alternatives. First few reasons that spring to mind.

[benevol]

Since when did anyone trust Windows/Microsoft/closed source software, anyway?

Did I miss anything?