Issue 700415  has been merged into this issue.

 Issue 700354  has been merged into this issue.

 Issue 700235  has been merged into this issue.

 Issue 702050  has been merged into this issue.

Workaround: if fixing an affected certificate is beyond your control, the "EnableCommonNameFallbackForLocalAnchors" group policy restores the pre-58 behaviour. If your organisation doesn't maintain policies for Chrome you can manually apply this policy on Windows by creating a new registry DWORD in "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome" called "EnableCommonNameFallbackForLocalAnchors", setting it to "1", and restarting Chrome. The usual warnings about casual registry editing apply.

https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors

Two notes:
1) Setting policies that way for non-enterprise managed devices is not guaranteed.
2) This policy is temporary and will be removed no earlier than Chrome 65.

 Issue 703140  has been merged into this issue.

 Issue 704359  has been merged into this issue.

 Issue 704199  has been merged into this issue.

 Issue 706398  has been merged into this issue.

How can EnableCommonNameFallbackForLocalAnchors be enabled for ChromeOS? 

https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors -- does not provide instructions for ChromeOS.

Re #11: I believe https://support.google.com/chrome/a/answer/1289314?hl=en&ref_topic=2935995 is the relevant article.

No, that url most certainly does NOT answer my question.

I am not asking how to manage a device.

I am asking for the way to affect THIS specific policy - which does not appear to be an option in Google Admin Console.

 Issue 707267  has been merged into this issue.

 Issue 710440  has been merged into this issue.

Re #17: The Chrome restriction is quite simple-- you must include the target hostname as a SubjectAltName instead of putting it in the SubjectCN field. https://textslashplain.com/2017/03/10/chrome-deprecates-subject-cn-matching/ includes examples and links on how to generate proper certificates. 

If you're using openSSL, http://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl/27931596#27931596 is a straightforward example.

 Issue 713220  has been merged into this issue.

Are you aware that you've broken MITM SSL Proxys such as Sophos UTM, self-signed internal corporate CA and many others with this move?
We know that you hate such instalments (for a reason), but still it would have been nice to make people aware about it before rolling out a breaking change (again).

This has got to be fixed!! My users surf through a Sophos UTM buyt basically can't now since the SSL scanning is using an internal certificate authority (domain controller)

Re #20/21: Sophos is reportedly aware of the problem and working to update their code to generate compliant certificates: https://community.sophos.com/products/unified-threat-management/f/general-discussion/91085/https-scanning-web-protection-ssl-error-err_cert_common_name_invalid/330113

RE #13: The policy should be available in the web console now that M58 reached stable. Click User settings and see the last policy under the Security section.

As you are using a domain controller, you can use Chrome's support for Enterprise Policies to set the "EnableCommonNameFallbackForLocalAnchors" flag, as documented at https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors

You can find additional details on how to do so at https://support.google.com/chrome/a/answer/187202?hl=en , until Sophos is able to provide the update in Comment #22.

Yes that will work, until Chrome 65. So it certainly isn't a "fix. More so a bandaid

That's correct. Support will be removed, as it represents a security risk.

How is this a security risk though? We're leveraging a certificate attribute as it was intended to be used, in a controllable way. I've tried to think this through logically for a while now, and it still makes no sense to me.

Common Names do not unambiguously encode the name they represent (that is, other name forms can be accepted as DNS or iPAddresses, even if not intended). They're also not part of the nameConstraints processing model, which can thus result in a bypass of the critical security controls of a certificate.

If you want to test your own clients, Netflix has helpfully open-sourced a tool that demonstrates many of the issues that arise from supporting commonNames without subjectAltNames at http://techblog.netflix.com/2017/04/bettertls-name-constraints-test-suite.html

 Issue 713816  has been merged into this issue.

 Issue 714142  has been merged into this issue.

 Issue 714214  has been merged into this issue.

I had the same problem as discussed here and had to switch on EnableCommonNameFallbackForLocalAnchors. It's unfortunately not always as easy as regenerating the certificates, often a lot of it is outside my control depending where I am. So far with the key I've just tried Chrome 58.0.3029.81 and Windows 7 unmanaged and it is working.

reg add \\MACHINE_NAME_GOES_HERE\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome /v EnableCommonNameFallbackForLocalAnchors /t REG_DWORD /d 1 /f

I also noticed this is an issue for Fiddler but found an article which says it can be fixed by changing the certificate generator:
https://textslashplain.com/2017/03/10/chrome-deprecates-subject-cn-matching/

We also have this issue but only with https://www.google.com/ other https site is working.

Re #34: Google.com would only hit this error if your connection has been compromised by a man-in-the-middle. You should click the ::ERR_CERT_COMMON_NAME_INVALID text to get the diagnostic info to see what certificate has been used. https://textslashplain.com/2017/03/30/get-help-with-https-problems/

https colon slash slash my wrists

Half the things that generate CSRs don't include SANs unless required. OpenSSL doesn't include one when generating certificates unless you specifically set options in the configuration file. At least there's a workaround for this, uninstall chrome and install firefox. 

 Issue 715914  has been merged into this issue.

 Issue 716148  has been merged into this issue.

 Issue 716465  has been merged into this issue.

 Issue 717209  has been merged into this issue.

 Issue 718686  has been merged into this issue.

 Issue 720010  has been merged into this issue.

Issue 722903 has been merged into this issue.

 Issue 724162  has been merged into this issue.

I can count on one hand the number of CA certs I've seen outside of .gov that have name constraint...Comment 36 is right on the ball. I suspect that many older applications with shoddy X.509 support will end up having to use externally generated keys because they lack the ability to embed SAN in CSR.

Many CAs allow SANs to be added post-CSR or copied from CN. Doesn't that by itself say something about the woeful lack of support for SAN inclusion?

If Chrome failed BetterTLS before then it should address the bugs in name constraint enforcement rather than getting rid of non-SAN certificates.

Everyone running an home network using any of these devices: sonicwall, asus wifi routers, hp and asus printers will get the error, the vendors by default do not provide compliant certificates, asus changes the certificate every time you upgrade the firmware... This is impacting home networks maintenance, breaking every and each device in name of man in the middle attacks... Google should allow users to disable the functionality, no errors returned, errors on Asus routers render the management of teh router impossible. You are forcing people to move to edge and other browsers.

Re #46/#47: What's the URL of the configuration page, and what is shown in the Developer Tools console in the failing case? 

Typically, home routers use self-signed certificates with invalid hostnames, meaning that Chrome and all other browsers would block them anyway; the new block would just be a third source of invalidity for already-invalid certificates.

Hi,
Is there an option to enable common name fallback using command line parameters instead of using the registry key 
EnableCommonNameFallbackForLocalAnchors?

Thanks,
  

> Is there an option to enable common name fallback using command line parameters instead of using the registry key 
EnableCommonNameFallbackForLocalAnchors?

You mean command line parameters in Chrome or you just want to do it by command line? For the latter you can use the reg.exe command as seen in comment 32

Hi
I mean command line parameters in Chrome.
I want to update the common name fallback only for a single instance of chrome without change the registry. I need to check a website that uses a self sign certificate and I want to allow the common name fallback only for this website. I don't want to make any changes to registry settings. 
Thanks

No. There is not a way to do this. It would be ideal to replace the certificate on that website.

EnableCommonNameFallbackForLocalAnchors doesn't work since 66.0.3359.117 (Official Build) (64-bit). I think you should restore it for legacy sites. I don't have control over the sites. If I want to enable the option to use it I think you should let me. I don't see what is the point of getting rid of the option. Some businesses I work with move for nothing. No devices are getting upgraded. I will have to try Firefox to access the sites.

This policy was always documented as being removed in Chrome 66. This is not about Legacy sites, but about those sites using Enterprise-specific trust anchors. In those cases, replacing the certificate is the correct option, to ensure that the insecure certificates are not used.

Same issue afer updating to 66, EnableCommonNameFallbackForLocalAnchors doesn't work and local applications are now showing ERR_CERT_COMMON_NAME_INVALID error. No error using Firefox.

To reiterate, this policy was deliberately removed in Chrome 66, as announced when the policy was added to Chrome.

Yes I understand that this was planned, but I still think there should be an option for us to lessen the security if we want to. It's just not as simple as everyone upgrades their certificates. It just doesn't work that way, in my experience. But I guess by now I've said my piece :)

This is absolutely ridiculous!!!

There should be an override for this for Intranet sites.  I get not wanting to do this for Internet sites.

A lot of devices that run on https:// web management pages only use CNs, and not SANs.  They simply are not advanced enough to use SANs in their requests.

You are forcing me to abandon Chrome and move to Firefox.  What a dumb move on someone's part.  Did they not think that IT Administrators need the other functionality???  No, they simply did not think.

EnableCommonNameFallbackForLocalAnchors is ignored since v66.
The GPO says, it will be removed in January 2019.

So please fix that issue. We need more time to change certificates.

Otherwise i have to move our company (1500+) devices to firefox...

Can you provide a screenshot of the GPO saying January 2019? Both the GPO and the Chrome Web Page that provided details indicated this would be removed in Chrome 66.

Thanks, didn't see that details.

We stopped rolling out chrome immediately and will discuss about the future of chrome in our insurance company group next week.

I agree, Chrome was never an enterprise browser to begin with. I am also advising against it.

> I agree, Chrome was never an enterprise browser to begin with. I am also advising against it.

They *where* a good option for people that didn't want IE and wanted the enterprise friendly atmosphere not present in firefox. Unfortunately it looks like Google has gone away from enterprise friendly more to the force it down your throat even if its against RFCs of firefox. Our way or the highway. Unfortunately we aren't google and we don't have the clout to make our vendors change everything they do and issue brand new certs for every application... much easier to just switch browsers to IE.

I don't understand why you're complaining. If you work in an enterprise environment you'd understand the security implications for this change and why it was done. Unless "easier" is the way you usually go.