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!

1 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, 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).

  • 1
    Wouldn't the incentive be that the SSL cert would not be PCI compliant? So, if I understand you correctly, this should be a trivial change on the CA's part, and only the CA can make this change, right? Thanks.
    – pbz
    Commented Oct 29, 2011 at 20:30
  • Here's something else they said: "PCI raised the severity for 'SSL Certificate Fails to Adhere to Basic Constraints / Key Usage Extensions' to 3.This is now 'Critical'. McAfee does not rate or rank PCI vulnerabilities. The PCI Council using the industry standard CVSS2 rates and ranks all vulnerabilities as they pertain to PCI. This is a 'Man in the Middle' (MitM). This vulnerability only affects 'Internet Explorer' (IE) and some minor browsers. This vulnerability does not affect Mozilla, Chrome, or Safari at this time."
    – pbz
    Commented Oct 29, 2011 at 20:55
  • 2
    Only the CA of the CA can make this change (but this is the same entity anyway). Any change in the contents of a certificate invalidates the signature on that certificate, which must be recomputed, necessarily by the CA "just above". Commented Oct 29, 2011 at 21:41
  • This may be a stupid question as I don't think I properly understand how it works, but if this is the case wouldn't all the browsers out there need to update their trusted certs? Wouldn't this take a long time? Thanks.
    – pbz
    Commented Oct 29, 2011 at 21:48
  • 1
    As I read it, the CA which has the "problem" is not the trust anchor (aka "root certificate", the one embedded in all browsers) but one below (it has been signed by the root cert, but it is not known a priori by the browsers; the Web server sends that intermediate CA certificate along with the server certificate). Commented Oct 29, 2011 at 23:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .