SSL certificate fails to adhere to basic constraints and PCI compliance

Question

We have an SSL cert from GoDaddy and tried to run a PCI compliance check using McAfee's scan. The one problem they found was that the basic constraints / path length is not configured. Here's what they wrote back:

An X.509 certificate sent by the remote host contains one or more violations of the restrictions imposed on it by RFC 3280. This means that either a root or intermediate Certificate Authority signed a certificate incorrectly. Certificates that fail to adhere to the restrictions in their extensions may be rejected by certain software. The existence of such certificates indicates either an oversight in the signing process, or malicious intent.

and also

Please follow the below steps to test the vulnerability manually: -Use Internet Explorer. -Enter the URL using 'https://'. -Click on the Browser tab: View -Click Security Report -Click on the Pop-Up 'View Certificates'. -Click on the Details tab. -Cursor 'Field' to 'Basic Constraints' -You may view the 'Path Length Constraint='

If the 'Certificate Basic Constraints' is set to False, Internet Explorer will not properly check the Certificate Authority.

'Certificate Basic Constraints' indicates 'Path Length Constraint='. This indicates how deep the Certificate Authority will be checked. If the 'Path....' Is set for '1', then the Certificate Authority above will be checked. However, if the browser checks and finds five Certificate Authority's, but 'Path....' Is set for '1', then there is a mismatch. Internet Explorer will accept the error and not warn, but other browsers will check and warn of the mismatch.

It looks like they acknowledged the issue: http://community.godaddy.com/groups/community/forum/topic/ssl-certificate-fails-to-adhere-to-basic-constraints-key-usage-extensions/

I've looked at a few other SSL sellers like GeoTrust, Comodo, Thawte, and they all seem to have the same issue -- at least going through the steps above McAfee suggests to check. None of the online SSL checkers I tried report any issues.

Is this a fairly recent change / requirement that all these companies didn't get a chance to adjust to? Any idea how long it would take for something like this to get fixed? Are there any workarounds to this issue? Any way I could modify the SSL (Windows Server 2008 R2) to include this "Path Length" restriction?

Thank you!

Answer 1

The error report you link to states that the problem is in the lack of a "Key Usage" extension in a CA certificate (that is, a certificate which has been signed by an upper CA -- probably a "root certificate" -- and which is used to issue other certificates).

From the current X.509 Internet profile (this is RFC 5280, successor of RFC 3280 which itself obsoletes RFC 2459), section 4.2.1.3, the rules for that extension are the following:

• when the extension is present, it restricts possible usage of the public key to exactly those listed in the extension;
• usage of a key to validate issued certificates is called "keyCertSign" (so a CA which has a Key Usage extension must include that flag in the extension, otherwise things will not work);
• conforming CA must include that extension in all CA certificates they issue.

So the lack of Key Usage extension in a CA certificate implies that the über-CA which created that CA certificate did not follow the rules (that's the third point, which was added in RFC 3280 in April 2002, so that's not exactly new). However, an application which uses that CA certificate without Key Usage extension is not entitled to reject the certificate path on that basis. Even though the Key Usage extension is lacking, the paths which include the CA certificate should still be validated by applications such as Internet Explorer, and indeed they are validated properly.

Resolution is easy for the über-CA: it just has to reissue the same CA certificate, with the same name and key, but this time with a Key Usage extension. This is a matter of a single signature, which involves, say, 1 millisecond of CPU time. Yet, since the lack of Key Usage extension does not prevent the CA certificate from "working", there is no incentive for the über-CA to do so (otherwise they would have done it years ago).