Comment 11 for bug 1031333

> 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