Open Bug 1942442 Opened 20 days ago Updated 16 days ago

Firefox rejects certificates with anyExtendedKeyUsage EKU and not id-kp-serverAuth

Categories

(Core :: Security: PSM, defect, P5)

Firefox 132
defect

Tracking

()

UNCONFIRMED

People

(Reporter: 2295456556, Unassigned)

Details

(Whiteboard: [psm-waiting])

Attachments

(4 files)

1.69 KB, application/x-x509-ca-cert
Details
3.39 KB, application/x-x509-ca-cert
Details
1.27 KB, application/x-x509-ca-cert
Details
3.24 KB, application/x-x509-ca-cert
Details
Attached file server_key.pem

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 Edg/131.0.0.0

Steps to reproduce:

  1. Adding the root CA cert and the intermediate CA cert to the certificate store using certutil.
  2. Using Nginx with a certificate file named end.crt and a file named server_key.pem.
  3. Setting up the local machine (127.0.0.1) as the server and mapping "ypj.test.com" to 127.0.0.1 in the hosts file.
  4. Running nginx.exe and accessing the URL "https://ypj.test.com:443" in a web browser, where the certificate's SAN matches the URL.

Actual results:

I have encountered a discrepancy in certificate validation between Firefox and Chrome browsers. I created a certificate chain [end, inner, root], where the intermediate certificate ("inner") includes the ANY_EXTENDED_KEY_USAGE extension but omits serverAuth and clientAuth from its EKU field.

Firefox rejects the certificate chain due to the missing serverAuth in the EKU field, despite the presence of ANY_EXTENDED_KEY_USAGE.

Expected results:

According to RFC 5280, a certificate with ANY_EXTENDED_KEY_USAGE should be valid for all purposes, including serverAuth. Chrome validates this certificate chain successfully.

This inconsistency can lead to interoperability issues between Firefox and other browsers or clients

Attached file root.der
Attached file inner.der
Attached file end.crt

RFC 5280 also says:

   Applications that require the presence of a
   particular purpose MAY reject certificates that include the
   anyExtendedKeyUsage OID but not the particular OID expected for the
   application.

We're looking into why the BRs allow certificates with only the anyExtendedKeyUsage OID and not id-kp-serverAuth in that one case (id-kp-serverAuth is required in all other cases, as far as I understand).

Severity: -- → S4
Priority: -- → P5
Summary: Firefox rejects certificates with ANY_EXTENDED_KEY_USAGE EKU → Firefox rejects certificates with anyExtendedKeyUsage EKU and not id-kp-serverAuth
Whiteboard: [psm-waiting]

I have searched for any trusted CA in both CCADB and censys.io, and I have not found a single one with the anyEKU EKU.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: