> I'm not sure there are any left though.
There are. As of today 5/11/2013, Verisign's md2 certificate *is* still in use,
i.e., still being sent out as part of the cert chain at actual sites,
see e.g., pip.verisignlabs.com -- which is Verisign/Symantec's openid provider
and thus may be particularly widely used.
and causing connections to fail. My own particular trouble is with Perl's
IO::Socket::SSL but
openssl fails as well, even with the certificate path/file explicitly specified:
openssl s_client -showcerts -tls1 -CApath /etc/ssl/certs -connect
pip.verisignlabs.com:443 </dev/null
openssl s_client -showcerts -tls1 -CAfile /etc/ssl/certs/ca-certificates.crt
-connect pip.verisignlabs.com:443 </dev/null
both result in
Verify return code: 20 (unable to get local issuer certificate)
Adding in the md2 certificate as a locally trusted certificate fixed things.
This being on a fresh upgrade of Debian 7.0 (wheezy) ca-certficates version
20130119
Also, there's another certificate from "Startcom Certification Authority"
that's in a similar boat
i.e., two versions -- SHA1 and SHA256 --- of the same certificate in the
Mozilla bundle, identically named
According to openssl's "verify" manpage, verification is SUPPOSED to
fail in situations like these
The lookup first looks in the list of untrusted certificates and if no
match is found the remaining lookups are from the
trusted certificates.
from which I infer that if a match IS found in the supplied chain then
there won't BE a lookup in the certificate store and the actual bona
fide issuer for Verisign's "G5" subject (the root certificate self-
signed by "G5") will never actually be found. I.e., there's no way to
know a priori that the supposedly intermediate "G5" actually *is* backed
by a known root certificate unless we're going to look up *every*
certificate we get in the root store.
So I don't see how this can be an openssl bug unless openssl is
interpreting the spec wrong (and I have no idea about that other than
that it seems silly to require looking up every certificate received in
the root store on the off-chance that it might be a root and the remote
server maintainer who is the primary user of the certificate somehow
didn't realize it...)
... which would then mean there needs to be a way to include the m2
certificate in the root store somehow
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1031333
Title:
Missing Verisign certs due to broken extract script
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1031333/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
