New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 700595 link

Starred by 44 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2017
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Sign in to add a comment

Chrome no longer accepts certificates that fallback to common name (ERR_CERT_COMMON_NAME_INVALID)

Project Member Reported by, Mar 11 2017

Issue description

Chromium removed support for matching common name in certificates in M58:
 * Feature bug (including motivation):  Issue 308330 

Certificates that rely on this deprecated behavior will now be rejected with:

The affected certificates are often locally generated ones for development purposes, or are part of a private PKI. The solution is to re-generate the certificates to include a Subject Alternative Name extension, or to enable an option in Chrome to allow them.

--- Enterprise Policy to restore old behavior ---

The policy EnableCommonNameFallbackForLocalAnchors will restore the old behavior, without needing to re-generate the certificates.

For more details see:

--- OpenSSL ---

Pointers on how to re-generate the certificate using OpenSSL:

--- Windows ---

Pointers on how to regenerate the certificate on Windows:

Comment 1 by, Mar 11 2017

 Issue 700415  has been merged into this issue.

Comment 2 by, Mar 11 2017

 Issue 700354  has been merged into this issue.

Comment 3 by, Mar 11 2017

 Issue 700235  has been merged into this issue.

Comment 4 by, Mar 16 2017

 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.
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.

Comment 9 by, Mar 23 2017

 Issue 704199  has been merged into this issue.
 Issue 706398  has been merged into this issue.
How can EnableCommonNameFallbackForLocalAnchors be enabled for ChromeOS? -- does not provide instructions for ChromeOS.
Re #11: I believe 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.
Description: Show this description
 Issue 710440  has been merged into this issue.

Comment 17 Deleted

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. includes examples and links on how to generate proper certificates. 

If you're using openSSL, is a straightforward example.
 Issue 713220  has been merged into this issue.

Comment 20 by, Apr 20 2017

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:
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

You can find additional details on how to do so at , 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.

Comment 27 by, Apr 20 2017

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
 Issue 713816  has been merged into this issue.
 Issue 714142  has been merged into this issue.
 Issue 714214  has been merged into this issue.

Comment 32 by, Apr 22 2017

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:

Comment 33 Deleted

Comment 34 by, Apr 25 2017

We also have this issue but only with other https site is working.
Re #34: 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 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.

Comment 45 by, Jul 28 2017

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.
172 KB View Download
292 KB View Download
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.
Is there an option to enable common name fallback using command line parameters instead of using the registry key 


Comment 51 by, Aug 21 2017

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

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
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. 
No. There is not a way to do this. It would be ideal to replace the certificate on that website.

Comment 54 Deleted

Comment 55 by, Apr 21 2018

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.

Comment 57 by, Apr 23 2018

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.

Comment 59 by, Apr 23 2018

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.

Comment 62 Deleted

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.

Sign in to add a comment