well, this is certainly beyond my certificate debugging skill level. Would engaging a Chrome mailing list be helpful?
Thanks for all the info so far, Greg 2012/1/4 Ondrej Mikle <[email protected]>: > On 01/04/12 21:30, Pascal wrote: >> >> Running www.digicert.com through that tool shows the 2nd intermediate >> certificate that needs to be included. > > > Their tool is quite good, but not all-powerful. The suggested "2nd > intermediate certificate" must have subject CN="DigiCert High Assurance EV > Root CA". That can be either self-signed root certificate or a > cross-certificate (one cross-cert is issued by GTE CyberTrust and one by > Entrust). The "DigiCert High Assurance EV Root CA" is trusted by Windows > (that's why it appears at the top of the chain shown by Chrome). > > But it really seems the issue is at the client's side (which is frankly > rare). > > The real point is, why does MS CryptoAPI think that the signature > www.torproject.org is invalid (openssl and gnutls don't object)? BTW, the > reason Chrome sees different cert for "DigiCert High Assurance CA-3" than > the one sent by www.torproject.org is because CryptoAPI engages in "AIA > chasing" and downloads the intermediate cert from the URL it finds in > Authority Information Access of torproject.org's cert (but even that chain > should validate). > > > Ondrej > _______________________________________________ > tor-talk mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
