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" <[email protected]> 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
