Closed Bug 1049176 Opened 10 years ago Closed 10 years ago

mozilla::pkix gives SEC_ERROR_INADEQUATE_CERT_TYPE when root CA cert has extendedKeyUsage set

Categories

(Core :: Security, defect)

31 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: dkg, Unassigned)

Details

Attachments

(1 file)

Attached file example certs and keys
When a private root CA has an extendedKeyUsage extension set it its certificate, firefox 31 will refuse to talk to servers certified by it, even if the root CA's cert has been explicitly loaded and trusted as an authority for "identifying web sites".  The error is SEC_ERROR_INADEQUATE_CERT_TYPE.

I believe this is an overzealous interpretation of the CA/B Baseline Requirements.

https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_8.pdf

says clearly that the root CA MUST NOT have the eKU extension (appendix B, §1.D), but this requirement may only make sense for root CAs that ship with browsers -- is there a reason to preclude a privately-trusted root CA that has an eKU?

I've made two different certificate authorities that are otherwise identical, differing only in their secret key material and in the presence of an eKU marked with the OCSPSigning OID.  the first is named "Test CA", and the other is "Test CA no OCSP".

I've also made a secret key for a server named "monkeys.example", and produced two x.509 certificates for it, one from each CA.

If you fetch the tarball, unpack it, import the roots into your firefox profile, and then run a webserver process from it using one cert or the other, you'll get either SEC_ERROR_INADEQUATE_CERT_TYPE (with the cert from "Test CA") or a successful connection (with the cert from "Test CA no OCSP")


a test run would look something like:

 tar xzf pkix-root-eku-test.tgz
 ## use Firefox to trust these CAs:
 ##  pkix-root-eku-test/ca-with-eku/ca-cert.pem
 ##  pkix-root-eku-test/ca-without-eku/ca-cert.pem

 ## update /etc/hosts so that monkeys.example
 ## points to a local IP address
 cd pkix-root-eku-test/server
 gnutls-serv --x509certfile from-ca-without-eku.pem \
             --x509keyfile secret.key
 ## try https://monkeys.example:5556/-- success!

 gnutls-serv --x509certfile from-ca-with-eku.pem \
             --x509keyfile secret.key
 ## try again -- SEC_ERROR_INADEQUATE_CERT_TYPE!

 ## delete these CAs from firefox's trust anchors,
 ## since the secret keys are published.


Note that CA/B Baseline Requirements 1.1.8 *also* prohibits root CAs from directly issuing end-entity certificates (§12), but mozilla::pkix sensibly doesn't enforce that rule (at least here for privately-trusted CAs, i haven't tested against built-in CAs).  I think mozilla::pkix should relax the ban on eKU in root CA certificates for the same reason.
From rfc 5280, section 4.2.1.12: (Extended Key Usage)

   If the extension is present, then the certificate MUST only be used
   for one of the purposes indicated.

If the only purpose indicated in the certificate with the extension is OCSPSigning, then it can't be used for anything other than signing OCSP responses. In particular, it can't be used to issue certificates.
the only eKU is OCSP signing, but (for both root CA certificates in the example bundle) the KU has Certificate Signing and CRL Signing, and the Basic Constraints say "Certificate Authority: TRUE".

Are you saying tha the presence of the extendedKeyUsage extension effectively overrides or nullifies the keyUsage and basicConstraints extensions in an X.509v3 cert?
Hm, re-reading that section of the RFC, i think you're right.  Even though it says:

   This extension indicates one or more purposes for which the certified
   public key may be used, in addition to or in place of the basic
   purposes indicated in the key usage extension.

It then goes on to say:

   If a certificate contains both a key usage extension and an extended
   key usage extension, then both extensions MUST be processed
   independently and the certificate MUST only be used for a purpose
   consistent with both extensions.  If there is no purpose consistent
   with both extensions, then the certificate MUST NOT be used for any
   purpose.

So the "in addition to" in the first clause apparently means additional constraints, not additional acceptable usages.

I confess i'm surprised at this, as i'd always thought that kU and eKU were additive usages, and not additive constraints, but it looks like i was mistaken.

I guess we can chalk this report up as INVALID, and consider it a proper alignment with the standard.

Thanks for your prompt response, David.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Right - it's a bit unfortunate that those two sections say slightly different things. Thanks for filing the bug, though, and definitely feel free to file more bugs if there are other areas where either the spec is confusing or the implementation doesn't follow the spec (although unfortunately in some cases we have had to deviate from the spec due to a few widespread mistakes - see https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix ).
I can't believe I was on the verge of posting a new bug when this bug report was listed in the search results. I can also confirm that this error was a result of the CA having the extended key usage field in similar circumstances, different OS (windows 7). Firefox Really needs to generate more comprehensive errors.

Related Support Query: https://support.mozilla.org/en-US/questions/1019364
I don't understand, what eKU allows for SSL then?
My CA has the following extensions:

```
X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Data Encipherment, Key Agreement, Certificate Sign
            X509v3 Extended Key Usage: critical
                2.5.29.37.0
```

Shouldn't this allow SSL certificate signing?
My SSL certificate has the following extensions:

```
X509v3 extensions:
    X509v3 Key Usage: critical
        Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
    X509v3 Extended Key Usage: critical
        E-mail Protection, TLS Web Server Authentication, Code Signing, 1.3.6.1.5.2.3.5, Any Extended Key Usage
```

This all works fine in Webkit (Chrome/Safari).
Flags: needinfo?(dkg)
(In reply to Paul Eipper from comment #6)
> I don't understand, what eKU allows for SSL then?
> My CA has the following extensions:
> 
> ```
> X509v3 extensions:
>             X509v3 Basic Constraints: critical
>                 CA:TRUE, pathlen:0
>             X509v3 Key Usage: critical
>                 Digital Signature, Key Encipherment, Data Encipherment, Key
> Agreement, Certificate Sign
>             X509v3 Extended Key Usage: critical
>                 2.5.29.37.0
> ```
> 
> Shouldn't this allow SSL certificate signing?
> My SSL certificate has the following extensions:
> 
> ```
> X509v3 extensions:
>     X509v3 Key Usage: critical
>         Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
>     X509v3 Extended Key Usage: critical
>         E-mail Protection, TLS Web Server Authentication, Code Signing,
> 1.3.6.1.5.2.3.5, Any Extended Key Usage
> ```
> 
> This all works fine in Webkit (Chrome/Safari).

The "Root" CA Cert can not have EKU on it, if I'm understanding from this thread correctly. I'm not 100% sure on the Intermediate CA's, but all the Root CA can be used for, is to sign certificates. Examining my Root CA Cert, all it has is [ Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing (86)], with no EKU. My SSL Cert only has the following EKU [TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)].
From the RFC:

   If a CA includes extended key usages to satisfy such applications,
   but does not wish to restrict usages of the key, the CA can include
   the special keyPurposeID anyExtendedKeyUsage.  If the
   anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT
   be critical.

Doesn't it mean that the CA can still be used to sign certificates if the anyExtendedKeyUsage is present? Even if it is critical (note the SHOULD, not MUST).
Flags: needinfo?(dkg)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: