Closed
Bug 1432181
Opened 6 years ago
Closed 5 years ago
Remove BR BRNameMatchingPolicy::FallBackToCommonName (Ignore X.509 CommonName field in favor of SubjectAlternativeName/SAN for the WebPKI)
Categories
(Core :: Security: PSM, enhancement, P3)
Core
Security: PSM
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jcj, Assigned: dipen)
References
Details
(Whiteboard: [psm-deprecation] [psm-contractor])
Chrome is disabling name matching for the CommonName field [1]. The SubjectAlternativeName field has been required in all Web PKI certificates since v1.0 of the Baseline Requirements (1 July 2012) [2], making the CommonName field a now-5.5-year-old backward compatibility mechanism. Certificates that do not include a SAN field have become very rare on the public Internet. We should remove this backward-compatibility mechanism when possible. [1] https://twitter.com/sleevi_/status/955454614354235392 [2] https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf
Reporter | ||
Comment 1•6 years ago
|
||
Correction: This should be specifically to remove the fallback logic [1] which is now stale. [1] https://searchfox.org/mozilla-central/source/security/certverifier/BRNameMatchingPolicy.cpp
Summary: Ignore X.509 CommonName field in favor of SubjectAlternativeName/SAN for the WebPKI → Remove BR BRNameMatchingPolicy::FallBackToCommonName (Ignore X.509 CommonName field in favor of SubjectAlternativeName/SAN for the WebPKI)
Comment 2•6 years ago
|
||
Right now, as you see from the code you linked to, Firefox allows CN fallback for older certs. Changing the security.pki.name_matching_mode pref to 3 enforces no fallback (the current default is set to 1). This pref does not affect imported roots which always allow fallback (see my request below). So, what you are really asking is for them to change the default from 1 to 3. Personally, I'm OK with that, particularly in the nightly and DE builds just to get some feedback. However, I have a request as well. Allow this to be enforced for imported roots as well (or at least provide a preference to enforce it). I know enterprises have been lax in following RFC 2818 and not providing SANs in their certs, but a little pain is good to get things moving (again, a toggle pref is good for this). As mentioned, Chrome is now enforcing this for imported roots, so enterprises are experiencing this issue already.
Pushed by jjones@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/644cb19702ca Revert spurious npm-shrinkwrap.json changes r=me CLOSED TREE
Reporter | ||
Comment 4•6 years ago
|
||
(In reply to Pulsebot from comment #3) > Pushed by jjones@mozilla.com: > https://hg.mozilla.org/integration/mozilla-inbound/rev/644cb19702ca > Revert spurious npm-shrinkwrap.json changes r=me CLOSED TREE Ugh, wrong bug ID in that. Oh well; marking this leave-open. For anyone coming to check out this bug from that push, that should have been for Bug 1441338.
Keywords: leave-open
Comment 5•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/644cb19702ca
Whiteboard: [psm-deprecation]
Reporter | ||
Comment 6•6 years ago
|
||
Dipen, can you add this to your to-do list?
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
status-firefox59:
affected → ---
Keywords: leave-open
Whiteboard: [psm-deprecation] → [psm-deprecation] [psm-contractor]
Assignee | ||
Comment 7•6 years ago
|
||
Currently the default for security.pki.name_matching_mode pref is set to 3 which enforces no fallback. I understand the scope to remove BRNameMatchingPolicy::FallBackToCommonName method and always assume FallBackToSearchWithinSubject::No where it was called. Do we want to go further and clean up all logic surrounding fallback to common name? For example removing fallBackToCommonName parameter to SearchNames(), SearchWithinRDN(), MatchAVA() functions.
Flags: needinfo?(jjones)
Reporter | ||
Comment 8•6 years ago
|
||
Mmmm. Probably, but keeping in mind Bug 1461370 wants to support this fallback mechanism only for imported roots (e.g., enterprise cases). I am guessing due to that bug we wouldn't want to actually remove a bunch of this code, just change how it triggers (and add a new preference). I may well be wrong though! I haven't dug into it closely.
Flags: needinfo?(jjones)
We probably don't want to remove the ability to configure this just yet, so let's wontfix this for now.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•