Missing root certificate(?) [Verisign EV]

[fuzzykiller]

I've got some ssl errors in PHP recently, with steamcommunity.com.

Sure enough, checking the server certificate confirms the problem:

[fuzzykiller]

Anyone? To clarify the problem: The certificate verification fails. Now I sure could easily install the other G5 certificate in place of the existing one, but that'll likely break things on the other end. From what I understand, OpenSSL looks for certificates based on a hash of the subject field, which is the same.

So is there any cool solution to this or do I need to ask Valve & Verisign wtf they are doing?

[pigiron]

Wow! Confusing and scary.

I was able to repeat the same failure with the steamcommunity.com certs... but have not found an answer as to why they don't verify.

I even downloaded the root certificate(s) from VeriSign's website and unsuccessfully used those for verification using "openssl verify". Once I got rid of the carriage returns, and added an ending new line at the end of the file(s), they matched Firefox's root certs exactly... so I guess that's not too surprising.

At first I thought the problem could be that one of the certificates from the cert chain downloaded from steamcommunity.com was signed by "VeriSign Class 3 Public Primary Certification Authority - G5"... and a root cert exists for that in the Firefox package... and if you use the "-issuer_hash" parameter on the "openssl x509" command against that steamcommunity downloaded cert, the hash matches that root cert found in /etc/ssl/certs.

BUT... another cert downloaded in the cert chain from steamcommunity.com shows that the "VeriSign Class 3 Public Primary Certification Authority - G5" cert was actually signed by the "Class 3 Public Primary Certification Authority" root certificate... and that root cert also exists in the Firefox package... and the issuer hash of that Steam cert also matches one of those found in /etc/ssl/certs.

Why there are two possible root certs for Steam's cert chain I have no idea, and it doesn't sound like a great idea.

So... my thought was that the verify operation was getting confused about which root cert it should be using. So I copied all the certs from Firefox into the /tmp directory, then removed the "VeriSign Class 3 Public Primary Certification Authority - G5" cert. Next I did a "cat" on all the remaining certs, and used that file as the trusted certs in the "openssl verify" command. But the command still complains exactly the same.

I don't have a Windows box, so I can't go there... and you unfortunately use the following to explain some of it:

"Also, there's two certificates of this name."

But you talk about multiple certs, so I'm confused about which one you mean... but none of the certs that I downloaded from the Steam site are root certs (and that's normal), so I would expect any fingerprints to be different.

I even tried some "openssl ocsp" operations to see if the cert(s) were revoked, but hit an "unauthorized" problem... such is life I guess.

So like I said... confusing and scary.

[fuzzykiller]

I didn't have much time lately, but maybe I've got a few things wrong. From what I understand, there is a unique relation between issuer certificate and subject certificate, which is what openssl verify and hopefully any application checks. The flaw is that while the relation is unique, it is still based on the CN of the certificates, which are not unique. So a less sophisticated algorithm might select the wrong issuer certificate for verification, which then fails.

I guess the question really is: Is it possible to move away from this CN-based certificate lookup? It clearly breaks the moment there's two certificates with the same CN.