[SSL Observatory] www.torproject.org certificate chain fails to validate in Chrome on Windows

Carl Wallace carl at redhoundsoftware.com
Thu Jan 5 05:07:26 PST 2012


I can't imagine this is related to your error or surprising to anyone, but
none of the paths propagate certificate policies correctly.  Maybe it's a
bit surprising given the EV designation.


On 1/4/12 7:23 PM, "Ondrej Mikle" <ondrej.mikle at nic.cz> wrote:

>Hi,
>
>I've encountered this in the tor-talk mailing list.
>
>Try to connect to https://www.torproject.org in Chrome on Windows. Latest
>Chrome 
>(16.0.912.63 m) will give you "invalid signature" warning.
>
>I've been looking for the reason why that happens, but it seems to be
>client's 
>bug (MS CryptoAPI). Since such case is really rare, there is a good
>chance I'm 
>overlooking something.
>
>Some remarkable points:
>
>1. Chrome (via CryptoAPI) will download certificate from URL specified by
>Authority Information Access (instead of using the one provided by server
>in 
>handshake) and then chains to "DigiCert High Assurance EV Root CA" root
>cert, 
>which is trust anchor in Microsoft's Root Certificate Program.
>
>2. However, the same chain Chrome sees is verified without any problem by
>gnutls. By looking at the cert differences manually, I don't see why
>CryptoAPI 
>thinks there is any problem with signature (differences are in
>not_before, 
>serial, path_len in basicConstraints).
>
>The chains seen by clients are attached (Chrome and two chains
>constructed by 
>Firefox 9.0.1).
>
>OT: is there any way to save certificate chain in Firefox if it gives you
>an 
>uncommon error (i.e. different than "untrusted issuer")? Lately I see
>instances 
>of certs that have unknown extensions, but reload or manual s_client
>won't catch it.
>
>Ondrej





More information about the Observatory mailing list