Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 34 users
Status: Verified
Owner:
Closed: Mar 6
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Android, Windows, Chrome, Mac
Pri: 2
Type: Launch-OWP
Launch-Accessibility: ----
Launch-Legal: ----
Launch-M-Approved: ----
Launch-M-Target: 58-Dev, 58-Beta, 58-Stable-Exp, 58-Stable
Launch-Privacy: ----
Launch-Security: ----
Launch-Status: ----
Launch-Test: ----
Launch-UI: ----
Product-Review: ----

Restricted
  • Only users with EditIssue permission may comment.


Show other hotlists

Hotlists containing this issue:
Watching
Deprecations


Sign in to add a comment
Remove support for common names in certificates; only support Subject Alt Names
Project Member Reported by rsleevi@chromium.org, Oct 17 2013 Back to list
Tracking bug for removing support for matching hostnames against common names if a certificate lacks a subjectAltName.

RFC 2818 discouraged the practice > 10 years ago, as it was only intended for legacy. The Baseline Requirements require a subjectAltName, and require that the only host-ish names in a CN must be a name also in the SAN.

We should remove support for matching commonNames - which may be confused by host-ish things - and only support matching subjectAltNames, which are explicit (dNSName / iPAddress). I would propose we do this for all CA types (publicly trusted and locally added), as the name confusion exists regardless of the CA type.
 
Project Member Comment 1 by bugdroid1@chromium.org, Oct 24 2013
------------------------------------------------------------------------
r230679 | rsleevi@chromium.org | 2013-10-24T08:14:15.520428Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/cert_verify_proc.cc?r1=230679&r2=230678&pathrev=230679
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/cert_verify_proc_android.cc?r1=230679&r2=230678&pathrev=230679
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/cert_verify_proc_mac.cc?r1=230679&r2=230678&pathrev=230679
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/spdy/spdy_session.cc?r1=230679&r2=230678&pathrev=230679
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate_unittest.cc?r1=230679&r2=230678&pathrev=230679
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/cert_verify_proc_nss.cc?r1=230679&r2=230678&pathrev=230679
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/cert_verify_proc_openssl.cc?r1=230679&r2=230678&pathrev=230679
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate.cc?r1=230679&r2=230678&pathrev=230679
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate.h?r1=230679&r2=230678&pathrev=230679
   M http://src.chromium.org/viewvc/chrome/trunk/src/tools/metrics/histograms/histograms.xml?r1=230679&r2=230678&pathrev=230679
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/cert_verify_result.cc?r1=230679&r2=230678&pathrev=230679
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/cert_verify_proc_win.cc?r1=230679&r2=230678&pathrev=230679
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/cert_verify_result.h?r1=230679&r2=230678&pathrev=230679

Add a histogram for measuring the number of times we fall back to common name matching, when a certificate lacks a subjectAltName

BUG= 308330 

Review URL: https://codereview.chromium.org/27624002
------------------------------------------------------------------------
Project Member Comment 2 by bugdroid1@chromium.org, Dec 17 2013
Labels: -M-33 MovedFrom-33 M-34
Status: Untriaged
Moving all non essential bugs to the next Milestone.
Comment 3 by dxie@chromium.org, Jan 6 2014
Owner: rsleevi@chromium.org
Status: Assigned
Comment 4 by dxie@chromium.org, Mar 3 2014
Labels: -M-34 MovedFrom-34
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
Comment 5 by Deleted ...@, Nov 19 2014
Is there any timetable for this?  It would be very convenient for us (and our customers) if this didn't happen before April 2015.
Can you explain why? Beyond multiple RFCs discouraging it, the CA/Browser Forum Baseline Requirements prohibit SAN-less certs, and have since 2012. The discussions of the security issues they cause for most validating stacks are also well known and go back for several years prior in the CA industry.

Can you explain why/how you have certificates without the name in the CN in the SAN, what CA issued them, when, and why April 2015 represents a viable date?
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner may be inactive (i.e. hasn't fixed an issue in the last 30 days or commented in this particular issue in the last 90 days).  Thanks for helping out!

-Anthony
Cc: mattm@chromium.org
Labels: -MovedFrom-33 -MovedFrom-34 -Hotlist-Recharge Cr-Security-UX
felt: What are your thoughts on deprecating this?

For publicly trusted certificates, we are at less than .01% of verifications relying on this (in the past 28 days)

For both publicly trusted and internal verifications, we're at .23%.

Within just the non-publicly-trusted (but still trusted) certificates - that is, internal CAs only - this accounts for approximately 2.26% of the certificates we see do not have a subjectAltName.

I don't have logs access to be able to tell you what the user-count splits are for how many users may fall into these buckets in a given day (thus, be affected). However, it would significantly simplify the work we're doing with the PKI library not to have to consider the arbitrary format of common names when evaluating nameConstraints.
The usual  enterprise question: Do common MitM proxies still rely on common name in places we might not have UMA? 2.26% sounds non-trivial already, although I trust the network team with that judgment.

But since we should probably do it sooner rather than later: What would this failure look like? A generic COMMON_NAME_INVALID error (heh) or something specific to this deprecation? The latter would save us some headache, because we could place a more targeted explanation in the error.
re: error messages - we can do either.

re: MITM proxies - possibly, but unlikely. Most MITM proxies copy the cert fields directly (yes, I know, citation needed - mostly, it's the bugs we get when they copy the fields *incorrectly* that we know they're copying them directly, and they're the major vendors in the space). Note in the original bug itself, CN has been deprecated for 12 years, so there's also an argument that "uh, yeah, don't do that".

And that's 2.26% of certificates from an enterprise, not 2.26% overall.
Cc: rachelis@chromium.org edwardjung@chromium.org
If you can reasonably easily make it a separate error, I think we should get rid of this, and make sure to have a distinct net error that provides a solid explanation of possible causes. Based on the Diffie-Hellman fallout, that seems important for the first few releases.

Looping in Edward and Rachel (net error string folks) to put this on their radar.
Comment 12 by bay...@gmail.com, Oct 3 2015
FWIW, the default certificate generator in Fiddler/FiddlerCore is based on Microsoft makecert.exe, which doesn't support subjectAltNames and as a consequence would cause Chrome to fail uniquely. 
FWIW, makecert has been deprecated since 2012 ;)

http://blogs.technet.com/b/askds/archive/2012/08/14/rsa-key-blocking-is-here.aspx

It'd be great if Fiddler/FiddlerCore used certreq or *cough* a better tool ;)
Or https://gallery.technet.microsoft.com/scriptcenter/Self-signed-certificate-5920a7c6 (just documenting options now)

I'm somewhat torn on how sympathetic to be for the individual tools (MakeCert on Windows, "openssl" on other platforms), given that it's possible to hold them right (CertReq on Windows, making sure to specify a ca.cnf on OpenSSL that defines a SAN section).

Supporting Common Names is itself full of complexity (e.g. whether the RDN is a hierarchal sequence or an aggregate set of AttributeTypeAndValues) and security risks (the application of nameConstraints). At a minimum, we'd fully remove support for CA-trusted certificates, and declare 'caveat user' for the security aspects of the latter, but it'd be far more likely to remove support in the latter to avoid the ongoing maintenance cost of something we know to be insecure.
Comment 15 by bay...@gmail.com, Oct 4 2015
makecert has been "deprecated" in the wishful thinking of Microsoft since long before 2012, although that has had limited practical impact. The blog post in question concerns using makecert for a particular use case, not the case of building a self-signed root and descendants signed by it. But makecert has many limitations (very limited control of attributes, uses old OIDs that Mozilla periodically breaks, etc).

As of today, Fiddler will add a SAN to certificates if the user uses the CertEnroll, BouncyCastle, or CNG Generators; we'll try to find a way to move users off of using makecert by default although there are some interesting migration challenges there.
Cc: awhalley@chromium.org
Labels: M-52
Mozilla has done something different, but similar, in https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 . I'd like to take action for this for M-52, so that they're not unduly suffering the first-mover penalty.

From our 7 day aggregate metrics for Net.CertCommonNameFallback (which covers all fallbacks), and Net.CertCommonNameFallbackPrivateCA (which is for non-public CAs, but also reports in the first metric), the difference (that is, fallbacks that were to public CAs) is .0059%

That seems to be within the bounding window of deprecation. As such, I plan to send an Intent to Deprecate out, to deprecate the fallback for public CAs. Mozilla is setting a very generous date - certificates issued after 2015-08-01 - but that's inconsistent with our past actions of enforcing the BRs (which forbid this practice of CN-only), which have all taken effect immediately.

Given the percentages, there's two populations of servers affected
1) CAs who were or are not compliant with the BRs after the effective date (e.g. that delayed until 2014 or 2015 to follow the BRs passed in 22-Nov-11 and effective 01-Jul-12)
2) CAs who were issuing Very Long Certificates before the BRs came into effect (5 year certs or longer)

Sites in Bucket #2 tend to have the SHA-1 problem, and are already causing (soft) warnings, and in 2017-1-1, will begin to fail anyways. This seems to be the majority of sites from random sampling. Sites in Bucket #1 are... less defensible, and past changes have not considered them valid.

https://tlscanary.mozilla.org/runs/2016-04-04-10-56-25/index.htm contains a list from Mozilla populated by Alexa Top sites, that would break with the logic I'm proposing. I still believe it's the right thing though.
Cc: elawre...@chromium.org
Project Member Comment 18 by sheriffbot@chromium.org, Jun 1 2016
Labels: -M-52 M-53 MovedFrom-52
Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Components: -Internals>Network>SSL Internals>Network>Certificate
Project Member Comment 20 by sheriffbot@chromium.org, Jul 19 2016
Labels: -M-53 MovedFrom-53
This issue has been moved once and is lower than Pri-1. Removing the milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Components: -Security>UX
Labels: Team-Security-UX
Labels: -Type-Bug -OS-All -MovedFrom-52 -MovedFrom-53 M-58 OS-Android OS-Chrome OS-iOS OS-Mac OS-Windows Type-Launch-OWP
Labels: -OS-iOS Launch-M-Target-58-Dev Launch-M-Target-58-Beta Launch-M-Target-58-Stable-Exp Launch-M-Target-58-Stable OS-Linux
For the Test Folks:
- Automated testing will handle the enteprise policy being set and taking effect (and propagating). It will also cover making sure that the behaviour is correct (the commonName is ignored for the cert when not set).

For the UI Folks:
- The behaviour of certs that run afoul of this (that only have a common name) will be the standard name mismatch error (ERR_CERT_COMMON_NAME_INVALID) 

For the Security folks:
- This is a net-positive for security, but does not affect any Chrome platforms not using prefs as an escape hatch for local policy.

For the Android folks:
- For Chrome on Android, which has prefs/policy, this disables it. For Android WebView, this does not. The ETA for that deprecation is roughly 1 year from now.

For the Enterprise folks:
- As discussed, we've set a sunset on this policy 1 year out, and won't set the Future: true flag since we'd have to respin the .admx
Cc: -palmer@chromium.org
Project Member Comment 25 by bugdroid1@chromium.org, Feb 28 2017
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4

commit b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4
Author: rsleevi <rsleevi@chromium.org>
Date: Tue Feb 28 23:19:24 2017

Move name matching into the shared certificate validator

In the way-old times, Chrome used to rely on the underlying OS to
perform certificate name matching. Unfortunately, this meant that
certificates that worked in Chrome on one platform wouldn't work
in Chrome on another platform. As a result, a long time ago (e.g.
more than two years ago), Chrome moved to a common name validator,
which ensured that IPv6 was handled correctly, as were things like
trailing dots in the hostname (used to bypass DNS suffix search).

This cleans up the historical remants of that, by moving name
matching for certificates into a single place, in
CertVerifyProc::Verify, rather than the per-platform implementations
in CertVerifyProc::VerifyInternal.

The upside is this reduces code duplication.
The downside is this means that MockCertVerifyProc's now need to
supply certificates that *really* match their intended hostname, and
can no longer fake it til they make it.

BUG= 308330 

Review-Url: https://codereview.chromium.org/2725683002
Cr-Commit-Position: refs/heads/master@{#453735}

[modify] https://crrev.com/b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4/net/cert/cert_verify_proc.cc
[modify] https://crrev.com/b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4/net/cert/cert_verify_proc_android.cc
[modify] https://crrev.com/b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4/net/cert/cert_verify_proc_ios.cc
[modify] https://crrev.com/b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4/net/cert/cert_verify_proc_mac.cc
[modify] https://crrev.com/b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4/net/cert/cert_verify_proc_nss.cc
[modify] https://crrev.com/b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4/net/cert/cert_verify_proc_openssl.cc
[modify] https://crrev.com/b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4/net/cert/cert_verify_proc_unittest.cc
[modify] https://crrev.com/b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4/net/cert/cert_verify_proc_win.cc
[modify] https://crrev.com/b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4/net/data/ssl/certificates/reject_intranet_hosts.pem
[modify] https://crrev.com/b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4/net/data/ssl/scripts/ee.cnf
[modify] https://crrev.com/b88c4386cdc3ea8c18d1bfd9cbaf5017141e83f4/net/data/ssl/scripts/generate-test-certs.sh

Project Member Comment 26 by bugdroid1@chromium.org, Mar 4
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0f9bfb00c432d594504502728b8a1405a0ff2cf1

commit 0f9bfb00c432d594504502728b8a1405a0ff2cf1
Author: rsleevi <rsleevi@chromium.org>
Date: Sat Mar 04 03:07:20 2017

Disable commonName matching for certificates

Matching the commonName has been deprecated for
nearly 20 years, as it's a fallback path for
certificates that don't have a subjectAltName.

Disable the matching by default, but introduce an
enterprise policy that allows it to be enabled for
certificates that chain to local trust anchors.
This policy is similar to the SHA-1 deprecation
policy, and is named
EnableCommonNameFallbackForLocalAnchors.

For systems without enterprise policies (meaning
they aren't using SSLConfigManagerPref), the
default is to keep the insecure behaviour, which
is most compatible with legacy, but is not secure.

BUG= 308330 

Review-Url: https://codereview.chromium.org/2719273002
Cr-Commit-Position: refs/heads/master@{#454752}

[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/chrome/browser/chromeos/login/test/https_forwarder.py
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/chrome/browser/policy/configuration_policy_handler_list_factory.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/chrome/test/data/extensions/api_test/platform_keys/ca.cnf
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/chrome/test/data/extensions/api_test/platform_keys/l1_interm.der
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/chrome/test/data/extensions/api_test/platform_keys/l1_leaf.der
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/chrome/test/data/extensions/api_test/platform_keys/l2_leaf.der
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/chrome/test/data/extensions/api_test/platform_keys/root.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/chrome/test/data/policy/policy_test_cases.json
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/components/policy/resources/policy_templates.json
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/components/ssl_config/ssl_config_prefs.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/components/ssl_config/ssl_config_prefs.h
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/components/ssl_config/ssl_config_service_manager_pref.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/cert/cert_verifier.h
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/cert/cert_verify_proc.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/cert/cert_verify_proc_android.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/cert/cert_verify_proc_ios.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/cert/cert_verify_proc_mac.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/cert/cert_verify_proc_openssl.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/cert/cert_verify_proc_unittest.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/cert/internal/path_builder_unittest.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/cert/x509_certificate.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/cert/x509_certificate.h
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/cert/x509_certificate_unittest.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/generate-certs.py
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/i.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/i2.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/i3.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/root.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/target_file_aia.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/target_file_and_http_aia.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/target_invalid_and_http_aia.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/target_invalid_url_aia.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/target_no_aia.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/target_one_aia.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/target_six_aia.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/target_three_aia.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/cert_issuer_source_aia_unittest/target_two_aia.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/aia-cert.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/aia-intermediate.der
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/aia-root.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/explicit-policy-chain.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-A-by-B.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-B-by-C.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-B-by-F.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-BFE.keychain
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-C-by-D.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-C-by-E.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-D-by-D.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-E-by-E.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-F-by-E.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-chain1.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-chain2.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-crlset-C.raw
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-crlset-CD-and-FE.raw
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-crlset-D-and-E.raw
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-crlset-E.raw
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root-crlset-unrelated.raw
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/multi-root.keychain
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/certificates/reject_intranet_hosts.pem
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/scripts/aia-test.cnf
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/scripts/ee.cnf
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/scripts/generate-aia-certs.sh
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/scripts/generate-policy-certs.sh
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/scripts/generate-test-certs.sh
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/scripts/policy.cnf
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/data/ssl/scripts/redundant-ca.cnf
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/quic/chromium/quic_network_transaction_unittest.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/quic/chromium/quic_stream_factory_test.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/quic/test_tools/mock_crypto_client_stream.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/spdy/spdy_session.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/ssl/ssl_config.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/ssl/ssl_config.h
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/ssl/ssl_config_service.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/ssl/ssl_config_service_unittest.cc
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/net/tools/testserver/minica.py
[modify] https://crrev.com/0f9bfb00c432d594504502728b8a1405a0ff2cf1/tools/metrics/histograms/histograms.xml

Labels: Merge-Request-58
Setting M-R to 58, since that's when the I2D was targeted, but if we need to punt this to 59, let me know so I can update the policy config (as it currently states it applies to 58)

This ended up landing just after branch due to various unrelated unittests having interdependencies that took longer than expected to sort out. From a Web Compat standpoint, Mozilla's already launched this.
Project Member Comment 28 by sheriffbot@chromium.org, Mar 6
Labels: -Merge-Request-58 Hotlist-Merge-Approved Merge-Approved-58
Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), bhthompson@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 29 by bugdroid1@chromium.org, Mar 6
Labels: -merge-approved-58 merge-merged-3029
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144

commit b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144
Author: Ryan Sleevi <rsleevi@chromium.org>
Date: Mon Mar 06 19:19:31 2017

Disable commonName matching for certificates

Matching the commonName has been deprecated for
nearly 20 years, as it's a fallback path for
certificates that don't have a subjectAltName.

Disable the matching by default, but introduce an
enterprise policy that allows it to be enabled for
certificates that chain to local trust anchors.
This policy is similar to the SHA-1 deprecation
policy, and is named
EnableCommonNameFallbackForLocalAnchors.

For systems without enterprise policies (meaning
they aren't using SSLConfigManagerPref), the
default is to keep the insecure behaviour, which
is most compatible with legacy, but is not secure.

BUG= 308330 

Review-Url: https://codereview.chromium.org/2719273002
Cr-Commit-Position: refs/heads/master@{#454752}
(cherry picked from commit 0f9bfb00c432d594504502728b8a1405a0ff2cf1)

Review-Url: https://codereview.chromium.org/2735733003 .
Cr-Commit-Position: refs/branch-heads/3029@{#23}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/chrome/browser/chromeos/login/test/https_forwarder.py
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/chrome/browser/policy/configuration_policy_handler_list_factory.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/chrome/test/data/extensions/api_test/platform_keys/ca.cnf
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/chrome/test/data/extensions/api_test/platform_keys/l1_interm.der
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/chrome/test/data/extensions/api_test/platform_keys/l1_leaf.der
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/chrome/test/data/extensions/api_test/platform_keys/l2_leaf.der
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/chrome/test/data/extensions/api_test/platform_keys/root.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/chrome/test/data/policy/policy_test_cases.json
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/components/policy/resources/policy_templates.json
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/components/ssl_config/ssl_config_prefs.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/components/ssl_config/ssl_config_prefs.h
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/components/ssl_config/ssl_config_service_manager_pref.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/cert/cert_verifier.h
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/cert/cert_verify_proc.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/cert/cert_verify_proc_android.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/cert/cert_verify_proc_ios.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/cert/cert_verify_proc_mac.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/cert/cert_verify_proc_openssl.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/cert/cert_verify_proc_unittest.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/cert/internal/path_builder_unittest.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/cert/x509_certificate.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/cert/x509_certificate.h
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/cert/x509_certificate_unittest.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/generate-certs.py
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/i.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/i2.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/i3.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/root.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/target_file_aia.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/target_file_and_http_aia.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/target_invalid_and_http_aia.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/target_invalid_url_aia.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/target_no_aia.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/target_one_aia.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/target_six_aia.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/target_three_aia.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/cert_issuer_source_aia_unittest/target_two_aia.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/aia-cert.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/aia-intermediate.der
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/aia-root.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/explicit-policy-chain.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-A-by-B.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-B-by-C.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-B-by-F.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-BFE.keychain
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-C-by-D.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-C-by-E.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-D-by-D.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-E-by-E.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-F-by-E.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-chain1.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-chain2.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-crlset-C.raw
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-crlset-CD-and-FE.raw
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-crlset-D-and-E.raw
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-crlset-E.raw
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root-crlset-unrelated.raw
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/multi-root.keychain
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/certificates/reject_intranet_hosts.pem
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/scripts/aia-test.cnf
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/scripts/ee.cnf
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/scripts/generate-aia-certs.sh
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/scripts/generate-policy-certs.sh
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/scripts/generate-test-certs.sh
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/scripts/policy.cnf
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/data/ssl/scripts/redundant-ca.cnf
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/quic/chromium/quic_network_transaction_unittest.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/quic/chromium/quic_stream_factory_test.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/quic/test_tools/mock_crypto_client_stream.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/spdy/spdy_session.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/ssl/ssl_config.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/ssl/ssl_config.h
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/ssl/ssl_config_service.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/ssl/ssl_config_service_unittest.cc
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/net/tools/testserver/minica.py
[modify] https://crrev.com/b166233e0fb8edd9fd4e67bc4a6bfb8e35b79144/tools/metrics/histograms/histograms.xml

Status: Verified
This change causes Chromium to fall out of compliance with RFC 2818.

From RFC 2818:

  If a subjectAltName extension of type dNSName is present, that MUST
  be used as the identity. Otherwise, the (most specific) Common Name
  field in the Subject field of the certificate MUST be used. Although
  the use of the Common Name is existing practice, it is deprecated and
  Certification Authorities are encouraged to use the dNSName instead.

Special note to where MUST is used with respect to the Common Name field being used to match the identity.

References to deprecation in this context are non-normative while the specification that the Common Name field in the Subject field of the Certificate MUST be used is normative of HTTPS.

With this change, Chromium is broken with respect to HTTPS as defined in RFC 2818.
See https://tools.ietf.org/html/rfc6125#section-6.4.4

   Therefore, if and only if the presented identifiers do not include a
   DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
   supported by the client, then the client MAY as a last resort check
   for a string whose form matches that of a fully qualified DNS domain
   name in a Common Name field of the subject field (i.e., a CN-ID).
Thank you for your feedback. As captured in RFC 6125 and the CA/Browser Forum Baseline Requirements, the use of this specific clause is discouraged (RFC 6125 - 2011) or explicitly forbidden (CA/Browser Forum Baseline Requirements - 2011). Support for this clause is also problematic, as has been shown by the fact that "(most specific)" has been widely seen as ambiguous.

However, we have evaluated the compatibility risk consistent with the Blink Process ( http://www.chromium.org/blink#new-features ) and found that the compatibility risk is low, the change moves the web forward by better security (as commonNames represent a real security risk), and is thus appropriate to make. We fully support future revisions to RFC 2818, should that help clarify by better documenting client support - or lack - for those aspects of RFC 2818. This is much like how RFC 5785 and RFC 7230 have replaced or superseded other aspects of 2818, and for which 6125 - a BCP-track document - provides guidance.
RFC 6125 (indicates that this feature MAY be used and RFC 2818 (HTTP over TLS, HTTPS) indicates that it MUST be supported.  RFC 6125 indicates that it DOES NOT supercede RFCs published before it but acts only as a guide for RFCs written after it.

RFC 6125 also includes this same wording to indicate that it is indeed still required to be supported.

RFC 6125 Section 1.4 (Applicability) Normatively states:
   This document also does not supersede the rules for verifying service
   identity provided in specifications for existing application
   protocols published prior to this document, such as those excerpted
   under Appendix B.

RFC 6125 Section B.2 (2000 HTTP-TLS, RFC 2818) Informative restates:
   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity.  Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used.  Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.
The CA/Browser Forum Baseline Requirements refer to the creation of certificates in this manner.  RFC 2818, which to my knowledge has no superseding documents, specifies that checking the Common Name field of the Subject field of the Certificate if there "an absolute requirement of the specification" (in the given cases) for software implementing HTTP-over-TLS/HTTPS.

RFC 6125 normatively states that it DOES NOT supersede ANY rules for verifying service identity information in specifications for existing applications such as RFC 2818, which it explicitly includes as an informative reference, including the requirement that the Common Name field in the Subject field of the Certificate be used to verify the service identity information in some cases.

I can appreciate that this change to break adherence to HTTPS causes very little measured change but it cannot be argued that Chromium retains compliance with RFC 2818 (HTTP-over-TLS/HTTPS) with this change since the standards are explicit on the matter.
For what it's worth, on a number of dimensions, it cannot be argued that Chromium was ever in compliance with RFC 2818.
In this specific case this is a change that will explicitly and intentionally break an absolute requirement of the HTTPS specification as the primary goal with no other side-effects and not due to lack of work since it requires work to make the change.
Thank you for your feedback. As the security benefits significantly outweigh the risk, and compliance with RFCs is not an absolute goal relative to delivering an interoperable and secure browser, this is an acceptable tradeoff. While there is work involved in removing this code, the result will be significantly simpler, more secure code.
Does the previous comment indicate that we are now all in agreement that this change is not supported by RFC 6125 and also that it directly contravenes absolute requirements of RFC 2818 (HTTP-over-TLS/HTTPS) ?
As someone who just spent several hours trying to track down the cause of this issue, may I suggest that you please fix the now-incorrect error code "net::ERR_CERT_COMMON_NAME_INVALID" (my commonName was perfectly valid, tyvm, it's the subjectAltName that was missing/invalid)?

The explanation text under "Advanced" is also frustratingly circular and misleading:

"This server could not prove that it is foo.example.com; its security certificate is from foo.example.com."

Otherwise you're going to have a lot of frustrated, unhappy developers/admins who use self-signed certs and internal CAs created using hacked together tools and openssl scripts, which have long followed the (agreeably incorrect) practice of not using subjectAltName for single-host certs.
#40: Agreed, I wrote about the confusing error message too: https://bugs.chromium.org/p/chromium/issues/detail?id=700235#c6

Surprised there isn't a user-facing deprecation [to warn in DevTools or change the address bar security indicator to Not Secure] like the SHA1 deprecation. 
Re #40: We may want to update the logic in ErrorInfo::CreateError to reflect the new deprecation, as it's now pretty misleading. https://cs.chromium.org/chromium/src/components/ssl_errors/error_info.cc?type=cs&q=IDS_CERT_ERROR_COMMON_NAME_INVALID_DETAILS&l=35

Re #41: We could probably add this information to the Security tab of the Developer Tools. My question is: Would you have looked there?
@42: Has DevTools changed since the SHA-1 deprecation? At that time, because of the way interstitials were setup, it was not possible to inject messages related to cert errors.

I agree, replacing it to not use the "common name" (since we'll never match that portion) is probably the correct answer, if I understood your proposal correctly.
@43: The DevTools' Security tab shows a specific warning when visiting a page containing a SHA-1 certificate in the chain (see https://sha1-2017.badssl.com/); the warning appears both on the Interstitial and the resulting page. We can likely do the same for this case; it would be easy to warn specifically if a certificate contains no SubjectAltNames. If you agree that makes sense, I can fork a bug.

With regard to ErrorInfo::CreateError, my proposal would be to exclude the SubjectCN from the list of names (either by dropping it from GetDNSNames entirely, or by changing that function to have a flag that prevents fallback). We could keep the existing SubjectCN matching within the CreateError function itself (under the theory that if a cert has both a SubjectCN and a matching SubjectAltName, that is the "primary" DNSName for the certificate). If you agree that makes sense, I can fork a bug.
@Comment 44: Yeah, if we have the logic to surface to DevTools, lets to both.
@42 - I'll chime in that I, too, spent hours tracking this down and, yes, the Security tab was the first thing I looked at - the error message as it stands is totally unhelpful.
Thanks, all!

I've filed two new issues:

 Issue 703616  for adding a Security Tab warning
 Issue 703614  for updating the Certificate Error page logic
@42: Chiming in a bit late, but yes having a more specific message in the DevTools would have been quite helpful. Thanks for listening.
 Issue 704905  has been merged into this issue.
 Issue 705906  has been merged into this issue.
Can someone kindly advise when will the policy templates be updated to include this setting please. Many thanks in advance.
Cc: dskaram@chromium.org
dskaram: See Question 51 about when the policy templates are updated. My understanding was with the Stable release, but could you confirm?
 Issue 708864  has been merged into this issue.
I'm wondering about thoughts on pushing this publicly first, and then rolling out the changes to privately trusted certs sometime after. I know that we were blindsided by this, and we'll be halting upgrades until we can catch up internally.

related:https://bugs.chromium.org/p/chromium/issues/detail?id=710440
@Comment 54: This has been required for publicly trusted certs since 2012. I'm curious what you're proposing would be different or change, since the same issues would exist regardless of when it was done, given the past five years.

In general, the only difference people report is the UX:
- Should the lock icon be degraded first (prior to the deprecation) or not?
  - Current data suggests it doesn't make the right balance between user confusion and server remediation
- Should there be a console warning first (prior to the deprecation) or not?
  - Unless accompanied with a UI change, the answer is that no one looks. With this, there's a Security Panel explanation for this.
- Should there be a coordinated flag day
  - Firefox already disabled this
- Should there be a big PR push for this
  - The effectiveness of such campaigns is marginal. TLS 1.3, which has had a tremendous amount of PR behind it talking about it coming, and active involvement of a wide variety of vendors, is still finding the same security products affected by this are breaking it. So we can conclude that such products are not responsive to changes.

At some point, there is pain introduced. The question is whether that pain is within the thresholds for making progress. So far, the metrics have suggested that while it has been disruptive individually for a few organizations, for the totality of users, it has not seen a meaningful increase in the error rate.
@55: Re Firefox already disabled this. 

They haven't fully disabled this. The suggestion that @54 made was how Firefox deals with this. Only 'new' certs, and only certs signed by publicly trusted CA's will throw a warning if they don't contain a SAN; any privately trusted CA's will show as secured for the time being. 

A staged deprecation is welcome. 

Source: https://bugzilla.mozilla.org/show_bug.cgi?id=1245280
 Issue 713199  has been merged into this issue.
Request to rename this issue: "Remove default support for Microsoft Certificate Services and self-signed certificates" so business users know they need to uninstall Chrome and install another browser instead.

I am not looking forward to replacing several hundred certificates...
Re Comment #58: That's simply not an accurate summary. Chrome supports both self-signed certificates and certificates generated by Microsoft tools, so long as they are generated properly.
Labels: Restrict-AddIssueComment-EditIssue
And if there is time needed for transition, in Enterprise scenarios, then EnableCommonNameFallbackForLocalAnchors exists as a flag - see https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors and https://support.google.com/chrome/a/answer/187202?hl=en

I'm going to mark this bug Restrict-Edit-AddIssueComment, given the large launch bug. We can take specific issues, if any exist beyond the above, as new issues.
 Issue 719373  has been merged into this issue.
Sign in to add a comment