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][1] (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).


  [1]: http://tools.ietf.org/html/rfc5280