Giters

nabla-c0d3 / trust_stores_observatory

Continuously monitor and record the content of the major platforms' root certificate stores.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Parse blacklisted.certs to populate the blocked_certificates entry of the Java store

nabla-c0d3 opened this issue · comments

commented

The file at /lib/security/blacklisted.certs contains the SHA-256 hash of blacklisted CA certificates. We should parse that to store it in the Java store's YAML file.

commented

How would these be added? There's no fields for blacklist / trust status.

commented

@adamdecaf do you mean inside blacklisted.certs?

I'm not sure if I understood the contents of the file correctly but my interpretation is that each individual line represents a fingerprint, and one could split on new lines to parse? The problem with this is that the values for subject_name would be missing inside the YAML file.

commented

@RaheelaKhan1172 It would assume that the blacklisted certificates are already available in ./certificates (which is probably true as we have the blacklisted certs from the other stores already). If a certificate isn't there, we have to find first and add it ./certificates. After that, it's easy to look them up using the fingerprint.
@adamdecaf There's a field in the YAML file for blocked_certificates.

commented

There were about 8 certs that weren't available in ./certificates; I found some from the second link @adamdecaf posted and the rest from here: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/8181f8b6ef0d/src/share/lib/security/blacklisted.certs.pem#l590

I used openssl to generate the fingerprint and verify that the fingerprints from blacklisted.certs match! All of the blacklisted certs are in the YAML file now, but I did have to add some manually. If we don't add them manually, they will be missing a subject name until we do :/ .
Is that okay @nabla-c0d3 ?

commented

Which certs were missing? Could you paste their crt.sh or censys.io links?

commented

You should not edit the YAML files as they are auto-generated when running python main.py --refresh.

However when a --refresh is done, you should parse the blacklist and look for each fingerprint in the local repository (using the lookup_certificate_with_fingerprint() method), and then add them to the list of blocked_certificates for the Java TrustStore; this will put the proper fingerprint and subject name in the YAML file.

If the actual certificates are not in ./certificates, this whole process will fail which is why they need to be added first (as PEM files).

commented

Ack, I re-read my comment and realize how confusing it is ( I'm going to blame that on not feeling well these past few days )

What I meant to say was:
inside java_store.py, when I'm parsing the trusted certs, I parsed blacklisted.certs as well.
The blacklisted certs go through the same cleansing that the trusted certs go through, so a run of python main.py --refresh updates the YAML file ( if there is a change ) and adds in the section for the blacklisted certs with the fingerprint and subject name ( the ones that are in the /certificate have a subject name, but the ones that are not in the repo yet only the fingerprint without a subject name ):
screen shot 2018-04-15 at 12 13 05 pm

now, I know which ones are missing, so I manually find and add the certificate as a PEM file to /certificates. Refreshing again:
screen shot 2018-04-15 at 12 47 07 pm

ta-da! All is well and good now-- BUT, I had to manually add the PEM file inside /certificates for the certs that were not in the repo. I was wondering if adding the missing certificates inside that repository is okay?

commented

@RaheelaKhan1172 Yes adding the missing certificates manually to ./certificates is the right way to go here. ;)