Document more locations of SHA-2 intermediates

[konklone]

I'd been tracking them on the wiki, but let's do it here instead.

They are now at https://shaaaaaaaaaaaaa.com/#sha2-intermediate.

One remaining from the wiki:

There's lots of GoDaddy intermediate CA certs in their repository, some have SHA-2 fingerprints alongside SHA-1 fingerprints, but not clear whether they are signed with SHA-1 or SHA-2.

[mathiasbynens]

https://shaaaaaaaaaaaaa.com/check/mathiasbynens.be says “mathiasbynens.be has a SHA-2 certificate, but needs to update its intermediates”. I think this is caused by the AddTrust External CA Root (in trust store) which uses SHA1 (02faf3e291435468607857694df5e45b68851868).

However, http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html says:

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

I might be misunderstanding something but should this warning be shown or not? Any ideas on what to do?

[konklone]

Ah, interesting -- it is in the trust store, but it's flagged because your server is also including it in the chain. It's actually not necessary for the server to send certificates trusted by the root at all.

I bet this is a common enough configuration. With some fancy maneuvers, I might be able to have openssl detect when a cert is in my server's trust store -- but I would also want to find out first how clients treat a chained root. Do browsers drop it? Or, if it's included in the chain, do they use it, and could it be impersonated?

Google's explanation implies that browsers go from the intermediate to the trust store regardless -- otherwise, an impersonated root could just be put in front of a server's otherwise root-less chain for a MITM, and Google's explanation doesn't allow for that possibility. If that's true, then I should do some work to have the site ignore server-provided roots -- I'll open a new issue for that.

[jonnybarnes]

Are we still trying to map SHA-1 intermediates with SHA-2 intermediates?

[konklone]

That'd be terrific, yeah. A mapping of names or regexes of names, to a name
and link, would help.

I ran out of time last night to add a detailed information display for the
chain, which could incorporate that mapping, but I'd like to do that next.

[vszakats]

No actual intermediates yet, but a indirect intent and a date about RapidSSL:
https://support.servertastic.com/new-intermediate-ca-for-geotrust-and-rapidssl/

[jonnybarnes]

That article doesn't actually say anything about SHA-2 though?

[vszakats]

True, we can only hope. Since RapidSSL is already able to create SHA-2 certificates, it'd be a logical reason for an update. I'm waiting for a support reply about the same issue. Will post updates.

[jonnybarnes]

Awesome, hopefully ghandi will join them soon as well

[vszakats]

Got a fast response from RapidSSL (thanks!) on SHA-2 intermediates: "by October, if not sooner"

[jonnybarnes]

In terms of detecting when SHA-1 certs can be upgraded, I'm curating a list of fingerprints in my sha-stuff repo.

[cadusilva]

Anyone looking for Comodo SHA2 intermediate certs, here you go.

[vszakats]

It's the 15th, no sign of SHA-2 RapidSSL intermediates yet. This seems like the place to look for an announcement: https://knowledge.rapidssl.com/support/ssl-certificate-support/index.html

[vszakats]

Linking to the other thread: #24 (comment)

[AGWA]

Reposting from #24 (comment):

RapidSSL's SHA-2 chain certificate is now available here: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO26459

You only need the first certificate in that chain; the second one is a root certificate that's trusted by virtually all browsers.

[vszakats]

Great news, thank you!

[konklone]

Closing because this is just a continuously and reactively actionable thread, like in #24.

[cadusilva]

Anyone looking for GlogalSign and AlphaSSL SHA-2 certs: follow this link.