Closed Bug 1432181 Opened 2 years ago Closed 10 months ago
Remove BR BRName
Matching Policy::Fall Back To Common Name (Ignore X .509 Common Name field in favor of Subject Alternative Name/SAN for the Web PKI)
Chrome is disabling name matching for the CommonName field . The SubjectAlternativeName field has been required in all Web PKI certificates since v1.0 of the Baseline Requirements (1 July 2012) , 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.  https://twitter.com/sleevi_/status/955454614354235392  https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf
Correction: This should be specifically to remove the fallback logic  which is now stale.  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)
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 firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/644cb19702ca Revert spurious npm-shrinkwrap.json changes r=me CLOSED TREE
(In reply to Pulsebot from comment #3) > Pushed by email@example.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.
Dipen, can you add this to your to-do list?
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.
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.
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.