Reconcile truststores between TLS Obs DB, Common CA database and NSS

[jvehent]

The list of CA in each truststore changes regularly. In the Observatory database, it's just a flag set on a certificate to indicate which truststore it belongs to. We should have a job that regularly reconciles the values in tlsobs with a trusted source.

From discussion with Mozilla's root ca team, it sounds like the Common CA database can be that trusted source. If we could pull that list on a regular basis, maybe via a job in the runner or something similar, we could keep our truststores automatically up to date.

Bonus points if we can get a notifications about changes applied to the DB, just in case the Common CA database gets corrupted.

[0xdiba]

Should an updated truststore trigger a rescan of all domains?

On 1 Aug 2016 23:30, "Julien Vehent [:ulfr]" notifications@github.com wrote:

Updating the truststores in the docker container could be done automatically during build time, so we always have the latest version when we build the containers.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mozilla/tls-observatory/issues/133, or mute the thread https://github.com/notifications/unsubscribe-auth/AE6OFHzscWdU-xMKvNdfqwx-iuRcQJtzks5qbld_gaJpZM4JZ933 .

[jvehent]

No. This is too costly and brings no benefit without notifying the users who triggered the original scan. I think it's better handled by daily rescans from people who care to do so.

[jvehent]

Rather than using travisci, we could have a job that reconcile the database with data in NSS and the CA program. See https://bugzilla.mozilla.org/show_bug.cgi?id=1295698

[tomato42]

What about stuff like WoSign?

[jvehent]

What about stuff like WoSign?

What exactly are you referring to? WoSign is trusted at the moment. We should update the truststores when it is no longer trusted.

[tomato42]

I mean that we can have situation in which certificates which were signed by a particular CA only before certain date are trusted. There are other instances of this, but I don't remember their names now.

[jvehent]

I think it's probably its own separate issue. Maybe an analyzer that calls moz::pkix? This issue is specifically about keeping the list of CAs up to date in the database.

[tomato42]

Yes, but I wonder if such CAs shouldn't be tagged, so that he UI could show that the server certificate may not be trusted.

In other words, to not have a situation in which Firefox says the certificate is invalid but the scanner says everything is hunky dory, without even a hint that something may be wrong.

[jvehent]

@tomato42 : let's take this to #151.

[jvehent]

I have an intermediate solution in https://github.com/mozilla/tls-observatory/pull/157/commits/40ad9cf1d9a7a2a5a82f85119ec63cbe32c230f0 Travisci pulls the latest from https://github.com/kirei/catt and updates the truststores in configuration, then scanners disable the trust of certificates no longer in truststores.

This still depends on building new scanners and restarting them, which I dislike. This issue will really be fixed when we can have a daily job that updates the DB based on data from the root CA program.

[jvehent]

catt continues to be very out of date, so today I added this tool: https://github.com/mozilla/tls-observatory/blob/master/tools/retrieveMozillaTrustedCAs.go It retrieves the PEM of trusted mozilla CAs directly from the common CA database, which is the most up to date source of information. We just need to make sure there are no differences between this and the content of NSS.

[jvehent]

2 out of 4! Microsoft truststore is now also being pulled from the Common CA database via https://github.com/mozilla/tls-observatory/blob/master/tools/retrieveTruststoreFromCADatabase.go