New issue
Advanced search Search tips
Starred by 44 users
Status: WontFix
Owner: ----
Closed: Mar 2017
Cc:
Components:
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 eroman@chromium.org, Mar 11 2017 Back to list
Chromium removed support for matching common name in certificates in M58:
 * Feature bug (including motivation):  Issue 308330 
 * https://www.chromestatus.com/features/4981025180483584

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

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: https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors

--- OpenSSL ---

Pointers on how to re-generate the certificate using OpenSSL:
See https://bugs.chromium.org/p/chromium/issues/detail?id=700235#c10

--- Windows ---

Pointers on how to regenerate the certificate on Windows:
https://bugs.chromium.org/p/chromium/issues/detail?id=700354#c7
 
Comment 1 by eroman@chromium.org, Mar 11 2017
Cc: rsleevi@chromium.org
 Issue 700415  has been merged into this issue.
Comment 2 by eroman@chromium.org, Mar 11 2017
 Issue 700354  has been merged into this issue.
Comment 3 by eroman@chromium.org, Mar 11 2017
Cc: elawre...@chromium.org
 Issue 700235  has been merged into this issue.
Comment 4 by eroman@chromium.org, 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.

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.
Comment 9 by mattm@chromium.org, 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? 

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.
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. 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.
Cc: davidben@chromium.org
 Issue 713220  has been merged into this issue.
Comment 20 by honz...@gmail.com, 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: 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.
Comment 27 by iab...@wayfair.com, 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 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.
Comment 32 by term...@gmail.com, 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:
https://textslashplain.com/2017/03/10/chrome-deprecates-subject-cn-matching/

Comment 33 Deleted
Comment 34 by jbyo...@gmail.com, Apr 25 2017
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.
Cc: krajshree@chromium.org rbasuvula@chromium.org ligim...@chromium.org
 Issue 717209  has been merged into this issue.
Cc: sandeepkumars@chromium.org
 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.
Chrome_Not_Safe_Error.JPG
172 KB View Download
Same_ASUS_Site_On_Edge_Same_PC.JPG
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.
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.
Comment 54 Deleted
Sign in to add a comment