Firefox Accepts Non-Existent Version 4 (0x03) X.509 Certificates, Contrary to RFC and Differing from Chrome's Rejection
Categories
(Core :: Security: PSM, defect)
Tracking
()
People
(Reporter: 2295456556, Unassigned)
Details
Attachments
(10 files)
|
2.08 KB,
application/x-x509-ca-cert
|
Details | |
|
1.47 KB,
application/x-x509-ca-cert
|
Details | |
|
1.13 KB,
application/x-x509-ca-cert
|
Details | |
|
1.13 KB,
application/x-x509-ca-cert
|
Details | |
|
46.83 KB,
image/png
|
Details | |
|
34.74 KB,
image/png
|
Details | |
|
72.26 KB,
image/png
|
Details | |
|
56.57 KB,
image/png
|
Details | |
|
96.52 KB,
image/png
|
Details | |
|
1.69 KB,
application/octet-stream
|
Details |
Steps to reproduce:
1.Generating a mutated digital certificate with an additional Subject Alternative Name (SAN) of "ypj.test.com", along with its corresponding root CA and private key.
2.Configuring an Nginx web server to use the mutated certificate and private key in HTTPS mode.
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.Adding the root CA to the system's trusted root certificate store using certutil.
5.Running nginx.exe. Accessing the URL "https://ypj.test.com:443" in a web browser, where the certificate's SAN matches the URL.
Actual results:
Firefox interpreted the certificate as version four (0x03) and accepted it as having passed the security verification, despite the fact that version 4 certificates do not exist in the real world. The RFC does not indicate that version 4 certificates are a real entity, whereas the Chrome browser did not accept it.
Expected results:
Firefox should reject the certificate, as in the real world, certificates only come in three versions: 1, 2, and 3.
| Reporter | ||
Comment 1•1 year ago
|
||
| Reporter | ||
Comment 2•1 year ago
|
||
| Reporter | ||
Comment 3•1 year ago
|
||
| Reporter | ||
Comment 4•1 year ago
|
||
| Reporter | ||
Comment 5•1 year ago
|
||
| Reporter | ||
Comment 6•1 year ago
|
||
| Reporter | ||
Comment 7•1 year ago
|
||
| Reporter | ||
Comment 8•1 year ago
|
||
| Reporter | ||
Comment 9•1 year ago
|
||
Comment 10•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
| Reporter | ||
Comment 11•1 year ago
|
||
firefox-version-113.0
| Reporter | ||
Comment 12•1 year ago
|
||
Certificates with a .crt extension are actually in the PEM format. The .crt naming is simply for convenience on Windows to facilitate visual inspection of their contents with the naked eye.
Comment 13•1 year ago
|
||
We have historically accepted v4 as being equivalent to v3 as a workaround for some enterprise consumers (Bug 1047177). I don't think there's a good reason to change this at the moment.
| Reporter | ||
Comment 14•1 year ago
|
||
If there were versions like v5, v6, ..., v10, would they all be treated as equivalent to v3 as a workaround? How do you define the boundary for this?
Comment 15•1 year ago
|
||
No, those are all errors---v4 is the only exception. Some private CAs were confused by the fact that v3 is encoded as 0x02 in the DER, and they mistakenly encoded v3 as 0x03.
Description
•