How can I find the list of certificates present in a set of CA stores

Question

Someone is running an automated scan on our SSL setup and they insist that our root certificate be included in all the following CA stores:

• "Mozilla NSS - 01/2014"
• "Apple - OS X 10.9.2"
• "Java 6 - Update 65"
• "Microsoft - 04/2014"

Now, I could argue about the list of CA stores they are using for their tests but this is not going to be a productive discussion so, I am looking for a way to find the exact list of certificates included in the above CA stores, and derive from that a list of vendors who are going to sell me a valid certificate signed by a root certificate present in all the above CA stores.

Hence, my questions, potentially dumb or naive, sorry for that:

1. For example, how do I know what certificates are included in "Mozilla NSS - 01/2014" ? I thought it would be easy to google for that string and find matching certificates but it's not. I tried to find a matching nss release for that data but I can't find any information about which nss version might have been released on jan 2014.

2. How do I know which vendors might sell certificates that are indirectly signed by a specific root certificate ?

3. Am asking the wrong questions given the problem ?

Answer 1

sslyze and even Qualys SSL Labs are thoroughly unaware of how this works and give you an approximate indication full of false positives matches (using Issuer Subject) and false negatives (missing from store because the issuer subject has no CN but is actually in the store.

An appropriate method for matching a certificate is building the correct chain of trust, where the order is determined by the server certificate (known as a leaf) has an AKI (authority key identifier) which tells you the next certificate in the chain that issued it, i.e. the Issuer certificate will have a matching SKI (subject key identifier) to the AKI of the leaf. Building the chain requires you to keep going until you reach a certificate without any AKI at all, or an AKI that matched it's own SKI (self-signed). That is the root (better known as a trust anchor). That Root certificate is what should be present in the CA bundle, sslyze and Qualys do not use the AKI method and will look for each certificate for presence in the CA bundle regardless if it is actually a root (trust anchor).

So now we know what Root certificate should be present in a CA bundle, how are bundles actually deployed? Again Qualys and sslyze do not do this well and will give you a false sense of security at best, at worst waste your time if you realise the false positive occurred and go try to figure out the truth (you know, the reason you used the tool)

So how are CA bundles deployed? This is complicated too (but is becoming less so lately).

After December 1st 2021 Apple will join Microsoft and Mozilla by using the CCADB as their trust store.

Util April 1st 2022 Apple will support the CCADB and their own legacy stores

Essentially, Microsoft, Mozilla, and Apple are no longer distinct platforms for Root CA Trust. This brings your list of 4 stores down to 2 distinct stores (the sslyze tool is unaware and shouldn't be trusted)

What other platforms offer their own Root CA trust stores?

• Linux: which distro? which release of that distro? Debian-based have a package called ca-certificates that provides a CA bundle. each distro/release/package version will be a slightly different CA bundle and most programs on the system decide if they use it or not (programming languages like Java and Python i'll explain next can just ignore the operating system CA bundle)
• Java: Various servers will use different versions, an updated Debian-based server should include the latest Java JDK (openjdk version "15.0.3" 2021-04-20) distributed by Debian but other operating systems will have different "latest" versions, and servers may not be patched or directly install specific JDK versions. each will be a slightly different CA bundle
• Python similar to Java each version will be a slightly different scenario, I have no source but I believe it was approx Python 2.1 when the built in http module started verifying certificates using the operating system CA bundle, before it skipped all validation. Earlier than that (and for quite some time afterwards too) urllib, django, and requests embedded their own CA bundles and at some point the requests library split thier out to become the certifi package which itself is a unique CA bundle because it consumes the CCADB and further curates certificates based on weaknesses it asserts to make the certificate invalid for trust purposes. After certifi was introduced other libraries like django, urllib, flask, fastapi and many more all seem to prefer this than use the http built-in method. So for python, both the certifi and operating system CA bundles can be used.
• Android: Each major version of Android has it's own CA bundle found here. The master branch is unreleased Android but release specific and tag specific bundles exist for each major Android release.
• Other: many other software and programming languages embed the CA bundle too, like the above nuance it can be very complicated to unpack.

My own tool is still prone to false positives and false negatives, but it is already light years ahead of the alternatives.. (it is less than a month old so it is not covering all the nuance but at least it covers a lot of it that other tools ignore). Give it a try, and read the source here to better understand CA bundles