Re: [squid-users] ssl bump and chrome 58
Exactly. 03.05.2017 16:32, Rafael Akchurin пишет: And on 3.5 too? -Original Message- From: Yuri [mailto:yvoi...@gmail.com] Sent: Wednesday, May 3, 2017 12:30 PM To: Rafael Akchurin <rafael.akchu...@diladele.com>; Flashdown <flashd...@data-core.org> Cc: squid-users@lists.squid-cache.org Subject: Re: [squid-users] ssl bump and chrome 58 Mountain brake, Raf :-) Fixed yesterday, already running on productions (on my side) ;-) 03.05.2017 15:05, Rafael Akchurin пишет: Sorry disregard - should practice my google fu better - see http://bugs.squid-cache.org/show_bug.cgi?id=4711 -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Rafael Akchurin Sent: Wednesday, May 3, 2017 10:48 AM To: Flashdown <flashd...@data-core.org>; Yuri Voinov <yvoi...@gmail.com> Cc: squid-users@lists.squid-cache.org Subject: Re: [squid-users] ssl bump and chrome 58 [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] Hello all, The following steps give in Chrome 58 the "Your connection is not private" error with "NET::ERR_CERT_COMMON_NAME_INVALID" and "missing_subjectAltName" error: (peek-an-splice bumping squid 3.5.23_1 as in https://docs.diladele.com/howtos/build_squid_ubuntu16/index.html) 1. Open Chrome 58+ 2. Type some non existing domain name like "https://www.asdlajsdfl.com; (note the httpS:// schema) 3. See the missing_subjectAltName error. Correct behavior would be Squid generating faked certificate for the domain name "www.asdlajsdfl.com" *with* subjectAltName extension set to "www.asdlajsdfl.com". So question is - does anyone know if this is already existing bug or shall I file one? May be it is a feature? Best regards, Rafael -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Flashdown Sent: Thursday, April 27, 2017 6:42 PM To: Yuri Voinov <yvoi...@gmail.com> Cc: squid-users@lists.squid-cache.org Subject: Re: [squid-users] ssl bump and chrome 58 I've tested the registry setting and it worked out. You can copy the below lines in a .reg file and execute it. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] "EnableCommonNameFallbackForLocalAnchors"=dword:0001 Best regards, Flashdown Am 2017-04-27 18:34, schrieb Flashdown: Hello together, here is a workaround that you could use in the meanwhile. https://www.chromium.org/administrators/policy-list-3#EnableCommonNam e FallbackForLocalAnchors Source: https://www.chromium.org/administrators/policy-list-3#EnableCommonNam e FallbackForLocalAnchors BEGIN EnableCommonNameFallbackForLocalAnchors Whether to allow certificates issued by local trust anchors that are missing the subjectAlternativeName extension Data type: Boolean [Windows:REG_DWORD] Windows registry location: Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAncho r s Mac/Linux preference name: EnableCommonNameFallbackForLocalAnchors Android restriction name: EnableCommonNameFallbackForLocalAnchors Supported on: Google Chrome (Linux, Mac, Windows) since version 58 until version 65 Google Chrome OS (Google Chrome OS) since version 58 until version 65 Google Chrome (Android) since version 58 until version 65 Supported features: Dynamic Policy Refresh: Yes, Per Profile: No Description: When this setting is enabled, Google Chrome will use the commonName of a server certificate to match a hostname if the certificate is missing a subjectAlternativeName extension, as long as it successfully validates and chains to a locally-installed CA certificates. Note that this is not recommended, as this may allow bypassing the nameConstraints extension that restricts the hostnames that a given certificate can be authorized for. If this policy is not set, or is set to false, server certificates that lack a subjectAlternativeName extension containing either a DNS name or IP address will not be trusted. Example value: 0x (Windows), false (Linux), false (Android), (Mac) <<<<<<<<<<<< END Am 2017-04-27 18:16, schrieb Flashdown: Hello together, Suddenly I am facing the same issue when users Chrome has been updated to V58. I am running Squid 3.5.23. This is the reason: https://www.thesslstore.com/blog/security-changes-in-chrome-58/ Short: Common Name Support Removed in Chrome 58 and Squid does not create certs with DNS-Alternatives names in it. Because of that it fails. Chrome says: 1. Subject Alternative Name Missing - The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address. 2. Certificate Error - There are issues with the site's certificate chain
Re: [squid-users] ssl bump and chrome 58
And on 3.5 too? -Original Message- From: Yuri [mailto:yvoi...@gmail.com] Sent: Wednesday, May 3, 2017 12:30 PM To: Rafael Akchurin <rafael.akchu...@diladele.com>; Flashdown <flashd...@data-core.org> Cc: squid-users@lists.squid-cache.org Subject: Re: [squid-users] ssl bump and chrome 58 Mountain brake, Raf :-) Fixed yesterday, already running on productions (on my side) ;-) 03.05.2017 15:05, Rafael Akchurin пишет: > Sorry disregard - should practice my google fu better - see > http://bugs.squid-cache.org/show_bug.cgi?id=4711 > > -Original Message- > From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] > On Behalf Of Rafael Akchurin > Sent: Wednesday, May 3, 2017 10:48 AM > To: Flashdown <flashd...@data-core.org>; Yuri Voinov > <yvoi...@gmail.com> > Cc: squid-users@lists.squid-cache.org > Subject: Re: [squid-users] ssl bump and chrome 58 > > [This sender failed our fraud detection checks and may not be who they > appear to be. Learn about spoofing at > http://aka.ms/LearnAboutSpoofing] > > Hello all, > > The following steps give in Chrome 58 the "Your connection is not private" > error with "NET::ERR_CERT_COMMON_NAME_INVALID" and "missing_subjectAltName" > error: > > (peek-an-splice bumping squid 3.5.23_1 as in > https://docs.diladele.com/howtos/build_squid_ubuntu16/index.html) > > 1. Open Chrome 58+ > 2. Type some non existing domain name like "https://www.asdlajsdfl.com; (note > the httpS:// schema) 3. See the missing_subjectAltName error. > > Correct behavior would be Squid generating faked certificate for the domain > name "www.asdlajsdfl.com" *with* subjectAltName extension set to > "www.asdlajsdfl.com". > > So question is - does anyone know if this is already existing bug or shall I > file one? > May be it is a feature? > > Best regards, > Rafael > > > -Original Message- > From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] > On Behalf Of Flashdown > Sent: Thursday, April 27, 2017 6:42 PM > To: Yuri Voinov <yvoi...@gmail.com> > Cc: squid-users@lists.squid-cache.org > Subject: Re: [squid-users] ssl bump and chrome 58 > > I've tested the registry setting and it worked out. You can copy the below > lines in a .reg file and execute it. > > Windows Registry Editor Version 5.00 > > [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] > "EnableCommonNameFallbackForLocalAnchors"=dword:0001 > > > Best regards, > Flashdown > > Am 2017-04-27 18:34, schrieb Flashdown: >> Hello together, >> >> here is a workaround that you could use in the meanwhile. >> >> https://www.chromium.org/administrators/policy-list-3#EnableCommonNam >> e >> FallbackForLocalAnchors >> >> Source: >> https://www.chromium.org/administrators/policy-list-3#EnableCommonNam >> e >> FallbackForLocalAnchors >>>>>>> BEGIN >> EnableCommonNameFallbackForLocalAnchors >> Whether to allow certificates issued by local trust anchors that are >> missing the subjectAlternativeName extension >> >> Data type: >> Boolean [Windows:REG_DWORD] >> Windows registry location: >> >> Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAncho >> r >> s >> Mac/Linux preference name: >> EnableCommonNameFallbackForLocalAnchors >> Android restriction name: >> EnableCommonNameFallbackForLocalAnchors >> Supported on: >> >> Google Chrome (Linux, Mac, Windows) since version 58 until >> version 65 >> Google Chrome OS (Google Chrome OS) since version 58 until >> version 65 >> Google Chrome (Android) since version 58 until version 65 >> >> Supported features: >> Dynamic Policy Refresh: Yes, Per Profile: No >> Description: >> >> When this setting is enabled, Google Chrome will use the >> commonName of a server certificate to match a hostname if the >> certificate is missing a subjectAlternativeName extension, as long as >> it successfully validates and chains to a locally-installed CA >> certificates. >> >> Note that this is not recommended, as this may allow bypassing >> the nameConstraints extension that restricts the hostnames that a >> given certificate can be authorized for. >> >> If this policy is not set, or is set to false, server >> certificates that lack a subjectAlternativeName extension containing >> either a DNS name or IP address will not be trusted. >> Example value: >> 0x (Wi
Re: [squid-users] ssl bump and chrome 58
Mountain brake, Raf :-) Fixed yesterday, already running on productions (on my side) ;-) 03.05.2017 15:05, Rafael Akchurin пишет: Sorry disregard - should practice my google fu better - see http://bugs.squid-cache.org/show_bug.cgi?id=4711 -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Rafael Akchurin Sent: Wednesday, May 3, 2017 10:48 AM To: Flashdown <flashd...@data-core.org>; Yuri Voinov <yvoi...@gmail.com> Cc: squid-users@lists.squid-cache.org Subject: Re: [squid-users] ssl bump and chrome 58 [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] Hello all, The following steps give in Chrome 58 the "Your connection is not private" error with "NET::ERR_CERT_COMMON_NAME_INVALID" and "missing_subjectAltName" error: (peek-an-splice bumping squid 3.5.23_1 as in https://docs.diladele.com/howtos/build_squid_ubuntu16/index.html) 1. Open Chrome 58+ 2. Type some non existing domain name like "https://www.asdlajsdfl.com; (note the httpS:// schema) 3. See the missing_subjectAltName error. Correct behavior would be Squid generating faked certificate for the domain name "www.asdlajsdfl.com" *with* subjectAltName extension set to "www.asdlajsdfl.com". So question is - does anyone know if this is already existing bug or shall I file one? May be it is a feature? Best regards, Rafael -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Flashdown Sent: Thursday, April 27, 2017 6:42 PM To: Yuri Voinov <yvoi...@gmail.com> Cc: squid-users@lists.squid-cache.org Subject: Re: [squid-users] ssl bump and chrome 58 I've tested the registry setting and it worked out. You can copy the below lines in a .reg file and execute it. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] "EnableCommonNameFallbackForLocalAnchors"=dword:0001 Best regards, Flashdown Am 2017-04-27 18:34, schrieb Flashdown: Hello together, here is a workaround that you could use in the meanwhile. https://www.chromium.org/administrators/policy-list-3#EnableCommonName FallbackForLocalAnchors Source: https://www.chromium.org/administrators/policy-list-3#EnableCommonName FallbackForLocalAnchors BEGIN EnableCommonNameFallbackForLocalAnchors Whether to allow certificates issued by local trust anchors that are missing the subjectAlternativeName extension Data type: Boolean [Windows:REG_DWORD] Windows registry location: Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchor s Mac/Linux preference name: EnableCommonNameFallbackForLocalAnchors Android restriction name: EnableCommonNameFallbackForLocalAnchors Supported on: Google Chrome (Linux, Mac, Windows) since version 58 until version 65 Google Chrome OS (Google Chrome OS) since version 58 until version 65 Google Chrome (Android) since version 58 until version 65 Supported features: Dynamic Policy Refresh: Yes, Per Profile: No Description: When this setting is enabled, Google Chrome will use the commonName of a server certificate to match a hostname if the certificate is missing a subjectAlternativeName extension, as long as it successfully validates and chains to a locally-installed CA certificates. Note that this is not recommended, as this may allow bypassing the nameConstraints extension that restricts the hostnames that a given certificate can be authorized for. If this policy is not set, or is set to false, server certificates that lack a subjectAlternativeName extension containing either a DNS name or IP address will not be trusted. Example value: 0x (Windows), false (Linux), false (Android), (Mac) <<<<<<<<<<<< END Am 2017-04-27 18:16, schrieb Flashdown: Hello together, Suddenly I am facing the same issue when users Chrome has been updated to V58. I am running Squid 3.5.23. This is the reason: https://www.thesslstore.com/blog/security-changes-in-chrome-58/ Short: Common Name Support Removed in Chrome 58 and Squid does not create certs with DNS-Alternatives names in it. Because of that it fails. Chrome says: 1. Subject Alternative Name Missing - The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address. 2. Certificate Error - There are issues with the site's certificate chain (net::ERR_CERT_COMMON_NAME_INVALID). Can we get Squid to add the DNS-Alternative Name to the generated certs? Since this is what I believe is now required in Chrome 58+ Best regards, Enrico Am 2017-04-21 15:35, schrieb Yuri Voinov: I see no problem with it on all five SSL Bump-aware servers with new Chrome. So fare so good. 21.04.2017 18:29, Marko Cupać пишет: Hi,
Re: [squid-users] ssl bump and chrome 58
Sorry disregard - should practice my google fu better - see http://bugs.squid-cache.org/show_bug.cgi?id=4711 -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Rafael Akchurin Sent: Wednesday, May 3, 2017 10:48 AM To: Flashdown <flashd...@data-core.org>; Yuri Voinov <yvoi...@gmail.com> Cc: squid-users@lists.squid-cache.org Subject: Re: [squid-users] ssl bump and chrome 58 [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] Hello all, The following steps give in Chrome 58 the "Your connection is not private" error with "NET::ERR_CERT_COMMON_NAME_INVALID" and "missing_subjectAltName" error: (peek-an-splice bumping squid 3.5.23_1 as in https://docs.diladele.com/howtos/build_squid_ubuntu16/index.html) 1. Open Chrome 58+ 2. Type some non existing domain name like "https://www.asdlajsdfl.com; (note the httpS:// schema) 3. See the missing_subjectAltName error. Correct behavior would be Squid generating faked certificate for the domain name "www.asdlajsdfl.com" *with* subjectAltName extension set to "www.asdlajsdfl.com". So question is - does anyone know if this is already existing bug or shall I file one? May be it is a feature? Best regards, Rafael -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Flashdown Sent: Thursday, April 27, 2017 6:42 PM To: Yuri Voinov <yvoi...@gmail.com> Cc: squid-users@lists.squid-cache.org Subject: Re: [squid-users] ssl bump and chrome 58 I've tested the registry setting and it worked out. You can copy the below lines in a .reg file and execute it. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] "EnableCommonNameFallbackForLocalAnchors"=dword:0001 Best regards, Flashdown Am 2017-04-27 18:34, schrieb Flashdown: > Hello together, > > here is a workaround that you could use in the meanwhile. > > https://www.chromium.org/administrators/policy-list-3#EnableCommonName > FallbackForLocalAnchors > > Source: > https://www.chromium.org/administrators/policy-list-3#EnableCommonName > FallbackForLocalAnchors >>>>>> BEGIN > EnableCommonNameFallbackForLocalAnchors > Whether to allow certificates issued by local trust anchors that are > missing the subjectAlternativeName extension > > Data type: > Boolean [Windows:REG_DWORD] > Windows registry location: > > Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchor > s > Mac/Linux preference name: > EnableCommonNameFallbackForLocalAnchors > Android restriction name: > EnableCommonNameFallbackForLocalAnchors > Supported on: > > Google Chrome (Linux, Mac, Windows) since version 58 until > version 65 > Google Chrome OS (Google Chrome OS) since version 58 until > version 65 > Google Chrome (Android) since version 58 until version 65 > > Supported features: > Dynamic Policy Refresh: Yes, Per Profile: No > Description: > > When this setting is enabled, Google Chrome will use the > commonName of a server certificate to match a hostname if the > certificate is missing a subjectAlternativeName extension, as long as > it successfully validates and chains to a locally-installed CA > certificates. > > Note that this is not recommended, as this may allow bypassing the > nameConstraints extension that restricts the hostnames that a given > certificate can be authorized for. > > If this policy is not set, or is set to false, server certificates > that lack a subjectAlternativeName extension containing either a DNS > name or IP address will not be trusted. > Example value: > 0x (Windows), false (Linux), false (Android), > (Mac) > <<<<<<<<<<<< END > > > > Am 2017-04-27 18:16, schrieb Flashdown: >> Hello together, >> >> Suddenly I am facing the same issue when users Chrome has been >> updated to V58. I am running Squid 3.5.23. >> >> This is the reason: >> https://www.thesslstore.com/blog/security-changes-in-chrome-58/ >> Short: Common Name Support Removed in Chrome 58 and Squid does not >> create certs with DNS-Alternatives names in it. Because of that it >> fails. >> >> Chrome says: >> 1. Subject Alternative Name Missing - The certificate for this site >> does not contain a Subject Alternative Name extension containing a >> domain name or IP address. >> 2. Certificate Error - There are issues with the site's certificate >> chain (net::ERR_CERT_COMMON_NAME_INVALID). >> >> Can
Re: [squid-users] ssl bump and chrome 58
Hello all, The following steps give in Chrome 58 the "Your connection is not private" error with "NET::ERR_CERT_COMMON_NAME_INVALID" and "missing_subjectAltName" error: (peek-an-splice bumping squid 3.5.23_1 as in https://docs.diladele.com/howtos/build_squid_ubuntu16/index.html) 1. Open Chrome 58+ 2. Type some non existing domain name like "https://www.asdlajsdfl.com; (note the httpS:// schema) 3. See the missing_subjectAltName error. Correct behavior would be Squid generating faked certificate for the domain name "www.asdlajsdfl.com" *with* subjectAltName extension set to "www.asdlajsdfl.com". So question is - does anyone know if this is already existing bug or shall I file one? May be it is a feature? Best regards, Rafael -Original Message- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Flashdown Sent: Thursday, April 27, 2017 6:42 PM To: Yuri Voinov <yvoi...@gmail.com> Cc: squid-users@lists.squid-cache.org Subject: Re: [squid-users] ssl bump and chrome 58 I've tested the registry setting and it worked out. You can copy the below lines in a .reg file and execute it. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] "EnableCommonNameFallbackForLocalAnchors"=dword:0001 Best regards, Flashdown Am 2017-04-27 18:34, schrieb Flashdown: > Hello together, > > here is a workaround that you could use in the meanwhile. > > https://www.chromium.org/administrators/policy-list-3#EnableCommonName > FallbackForLocalAnchors > > Source: > https://www.chromium.org/administrators/policy-list-3#EnableCommonName > FallbackForLocalAnchors >>>>>> BEGIN > EnableCommonNameFallbackForLocalAnchors > Whether to allow certificates issued by local trust anchors that are > missing the subjectAlternativeName extension > > Data type: > Boolean [Windows:REG_DWORD] > Windows registry location: > > Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchor > s > Mac/Linux preference name: > EnableCommonNameFallbackForLocalAnchors > Android restriction name: > EnableCommonNameFallbackForLocalAnchors > Supported on: > > Google Chrome (Linux, Mac, Windows) since version 58 until > version 65 > Google Chrome OS (Google Chrome OS) since version 58 until > version 65 > Google Chrome (Android) since version 58 until version 65 > > Supported features: > Dynamic Policy Refresh: Yes, Per Profile: No > Description: > > When this setting is enabled, Google Chrome will use the > commonName of a server certificate to match a hostname if the > certificate is missing a subjectAlternativeName extension, as long as > it successfully validates and chains to a locally-installed CA > certificates. > > Note that this is not recommended, as this may allow bypassing the > nameConstraints extension that restricts the hostnames that a given > certificate can be authorized for. > > If this policy is not set, or is set to false, server certificates > that lack a subjectAlternativeName extension containing either a DNS > name or IP address will not be trusted. > Example value: > 0x (Windows), false (Linux), false (Android), > (Mac) > <<<<<<<<<<<< END > > > > Am 2017-04-27 18:16, schrieb Flashdown: >> Hello together, >> >> Suddenly I am facing the same issue when users Chrome has been >> updated to V58. I am running Squid 3.5.23. >> >> This is the reason: >> https://www.thesslstore.com/blog/security-changes-in-chrome-58/ >> Short: Common Name Support Removed in Chrome 58 and Squid does not >> create certs with DNS-Alternatives names in it. Because of that it >> fails. >> >> Chrome says: >> 1. Subject Alternative Name Missing - The certificate for this site >> does not contain a Subject Alternative Name extension containing a >> domain name or IP address. >> 2. Certificate Error - There are issues with the site's certificate >> chain (net::ERR_CERT_COMMON_NAME_INVALID). >> >> Can we get Squid to add the DNS-Alternative Name to the generated >> certs? Since this is what I believe is now required in Chrome 58+ >> >> Best regards, >> Enrico >> >> >> Am 2017-04-21 15:35, schrieb Yuri Voinov: >>> I see no problem with it on all five SSL Bump-aware servers with new >>> Chrome. So fare so good. >>> >>> >>> 21.04.2017 18:29, Marko Cupać пишет: >>>> Hi, >>>> >>>> I have squid setup
Re: [squid-users] ssl bump and chrome 58
3.5 and above have "server-first" only for backward compatibility. 27.04.2017 22:50, William Lima пишет: > Hi, > > The problem occurs due to some ssl_bump directive actions, so Squid cannot > get all information (X.509 v3 extensions) to mimic. "ssl_bump server-first > all" should work. > > William Lima > > - Original Message - > From: "Flashdown" <flashd...@data-core.org> > To: "Yuri Voinov" <yvoi...@gmail.com> > Cc: squid-users@lists.squid-cache.org > Sent: Thursday, April 27, 2017 1:41:48 PM > Subject: Re: [squid-users] ssl bump and chrome 58 > > I've tested the registry setting and it worked out. You can copy the > below lines in a .reg file and execute it. > > Windows Registry Editor Version 5.00 > > [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] > "EnableCommonNameFallbackForLocalAnchors"=dword:0001 > > > Best regards, > Flashdown > > Am 2017-04-27 18:34, schrieb Flashdown: >> Hello together, >> >> here is a workaround that you could use in the meanwhile. >> >> https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors >> >> Source: >> https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors >>>>>>> BEGIN >> EnableCommonNameFallbackForLocalAnchors >> Whether to allow certificates issued by local trust anchors that are >> missing the subjectAlternativeName extension >> >> Data type: >> Boolean [Windows:REG_DWORD] >> Windows registry location: >> >> Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchors >> Mac/Linux preference name: >> EnableCommonNameFallbackForLocalAnchors >> Android restriction name: >> EnableCommonNameFallbackForLocalAnchors >> Supported on: >> >> Google Chrome (Linux, Mac, Windows) since version 58 until >> version 65 >> Google Chrome OS (Google Chrome OS) since version 58 until >> version 65 >> Google Chrome (Android) since version 58 until version 65 >> >> Supported features: >> Dynamic Policy Refresh: Yes, Per Profile: No >> Description: >> >> When this setting is enabled, Google Chrome will use the >> commonName of a server certificate to match a hostname if the >> certificate is missing a subjectAlternativeName extension, as long as >> it successfully validates and chains to a locally-installed CA >> certificates. >> >> Note that this is not recommended, as this may allow bypassing the >> nameConstraints extension that restricts the hostnames that a given >> certificate can be authorized for. >> >> If this policy is not set, or is set to false, server certificates >> that lack a subjectAlternativeName extension containing either a DNS >> name or IP address will not be trusted. >> Example value: >> 0x (Windows), false (Linux), false (Android), >> (Mac) >> <<<<<<<<<<<< END >> >> >> >> Am 2017-04-27 18:16, schrieb Flashdown: >>> Hello together, >>> >>> Suddenly I am facing the same issue when users Chrome has been updated >>> to V58. I am running Squid 3.5.23. >>> >>> This is the reason: >>> https://www.thesslstore.com/blog/security-changes-in-chrome-58/ >>> Short: Common Name Support Removed in Chrome 58 and Squid does not >>> create certs with DNS-Alternatives names in it. Because of that it >>> fails. >>> >>> Chrome says: >>> 1. Subject Alternative Name Missing - The certificate for this site >>> does not contain a Subject Alternative Name extension containing a >>> domain name or IP address. >>> 2. Certificate Error - There are issues with the site's certificate >>> chain (net::ERR_CERT_COMMON_NAME_INVALID). >>> >>> Can we get Squid to add the DNS-Alternative Name to the generated >>> certs? Since this is what I believe is now required in Chrome 58+ >>> >>> Best regards, >>> Enrico >>> >>> >>> Am 2017-04-21 15:35, schrieb Yuri Voinov: >>>> I see no problem with it on all five SSL Bump-aware servers with new >>>> Chrome. So fare so good. >>>> >>>> >>>> 21.04.2017 18:29, Marko Cupać пишет: >>>>> Hi, >>>>> >>>>> I have squid setup with ssl bump which worked fine, but since I >>>>> updated >>>>> chrome to 5
Re: [squid-users] ssl bump and chrome 58
Hi, The problem occurs due to some ssl_bump directive actions, so Squid cannot get all information (X.509 v3 extensions) to mimic. "ssl_bump server-first all" should work. William Lima - Original Message - From: "Flashdown" <flashd...@data-core.org> To: "Yuri Voinov" <yvoi...@gmail.com> Cc: squid-users@lists.squid-cache.org Sent: Thursday, April 27, 2017 1:41:48 PM Subject: Re: [squid-users] ssl bump and chrome 58 I've tested the registry setting and it worked out. You can copy the below lines in a .reg file and execute it. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] "EnableCommonNameFallbackForLocalAnchors"=dword:0001 Best regards, Flashdown Am 2017-04-27 18:34, schrieb Flashdown: > Hello together, > > here is a workaround that you could use in the meanwhile. > > https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors > > Source: > https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors >>>>>> BEGIN > EnableCommonNameFallbackForLocalAnchors > Whether to allow certificates issued by local trust anchors that are > missing the subjectAlternativeName extension > > Data type: > Boolean [Windows:REG_DWORD] > Windows registry location: > > Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchors > Mac/Linux preference name: > EnableCommonNameFallbackForLocalAnchors > Android restriction name: > EnableCommonNameFallbackForLocalAnchors > Supported on: > > Google Chrome (Linux, Mac, Windows) since version 58 until > version 65 > Google Chrome OS (Google Chrome OS) since version 58 until > version 65 > Google Chrome (Android) since version 58 until version 65 > > Supported features: > Dynamic Policy Refresh: Yes, Per Profile: No > Description: > > When this setting is enabled, Google Chrome will use the > commonName of a server certificate to match a hostname if the > certificate is missing a subjectAlternativeName extension, as long as > it successfully validates and chains to a locally-installed CA > certificates. > > Note that this is not recommended, as this may allow bypassing the > nameConstraints extension that restricts the hostnames that a given > certificate can be authorized for. > > If this policy is not set, or is set to false, server certificates > that lack a subjectAlternativeName extension containing either a DNS > name or IP address will not be trusted. > Example value: > 0x (Windows), false (Linux), false (Android), > (Mac) > <<<<<<<<<<<< END > > > > Am 2017-04-27 18:16, schrieb Flashdown: >> Hello together, >> >> Suddenly I am facing the same issue when users Chrome has been updated >> to V58. I am running Squid 3.5.23. >> >> This is the reason: >> https://www.thesslstore.com/blog/security-changes-in-chrome-58/ >> Short: Common Name Support Removed in Chrome 58 and Squid does not >> create certs with DNS-Alternatives names in it. Because of that it >> fails. >> >> Chrome says: >> 1. Subject Alternative Name Missing - The certificate for this site >> does not contain a Subject Alternative Name extension containing a >> domain name or IP address. >> 2. Certificate Error - There are issues with the site's certificate >> chain (net::ERR_CERT_COMMON_NAME_INVALID). >> >> Can we get Squid to add the DNS-Alternative Name to the generated >> certs? Since this is what I believe is now required in Chrome 58+ >> >> Best regards, >> Enrico >> >> >> Am 2017-04-21 15:35, schrieb Yuri Voinov: >>> I see no problem with it on all five SSL Bump-aware servers with new >>> Chrome. So fare so good. >>> >>> >>> 21.04.2017 18:29, Marko Cupać пишет: >>>> Hi, >>>> >>>> I have squid setup with ssl bump which worked fine, but since I >>>> updated >>>> chrome to 58 it won't display any https sites, throwing >>>> NTT:ERR_CERT_COMMON_NAME_INVALID. https sites still work in previous >>>> chrome version, as well as in IE. >>>> >>>> Anything I can do in squid config to get ssl-bumped sites in chrome >>>> again? >>>> >>>> Thank you in advance, >>> >>> ___ >>> squid-users mailing list >>> squid-users@lists.squid-cache.org >>> http://lists.squid-cache.org/listinfo/squid-users >> ___ >> squid-users mailing list >> squid-users@lists.squid-cache.org >> http://lists.squid-cache.org/listinfo/squid-users > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] ssl bump and chrome 58
I've tested the registry setting and it worked out. You can copy the below lines in a .reg file and execute it. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] "EnableCommonNameFallbackForLocalAnchors"=dword:0001 Best regards, Flashdown Am 2017-04-27 18:34, schrieb Flashdown: Hello together, here is a workaround that you could use in the meanwhile. https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors Source: https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors BEGIN EnableCommonNameFallbackForLocalAnchors Whether to allow certificates issued by local trust anchors that are missing the subjectAlternativeName extension Data type: Boolean [Windows:REG_DWORD] Windows registry location: Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchors Mac/Linux preference name: EnableCommonNameFallbackForLocalAnchors Android restriction name: EnableCommonNameFallbackForLocalAnchors Supported on: Google Chrome (Linux, Mac, Windows) since version 58 until version 65 Google Chrome OS (Google Chrome OS) since version 58 until version 65 Google Chrome (Android) since version 58 until version 65 Supported features: Dynamic Policy Refresh: Yes, Per Profile: No Description: When this setting is enabled, Google Chrome will use the commonName of a server certificate to match a hostname if the certificate is missing a subjectAlternativeName extension, as long as it successfully validates and chains to a locally-installed CA certificates. Note that this is not recommended, as this may allow bypassing the nameConstraints extension that restricts the hostnames that a given certificate can be authorized for. If this policy is not set, or is set to false, server certificates that lack a subjectAlternativeName extension containing either a DNS name or IP address will not be trusted. Example value: 0x (Windows), false (Linux), false (Android), (Mac) END Am 2017-04-27 18:16, schrieb Flashdown: Hello together, Suddenly I am facing the same issue when users Chrome has been updated to V58. I am running Squid 3.5.23. This is the reason: https://www.thesslstore.com/blog/security-changes-in-chrome-58/ Short: Common Name Support Removed in Chrome 58 and Squid does not create certs with DNS-Alternatives names in it. Because of that it fails. Chrome says: 1. Subject Alternative Name Missing - The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address. 2. Certificate Error - There are issues with the site's certificate chain (net::ERR_CERT_COMMON_NAME_INVALID). Can we get Squid to add the DNS-Alternative Name to the generated certs? Since this is what I believe is now required in Chrome 58+ Best regards, Enrico Am 2017-04-21 15:35, schrieb Yuri Voinov: I see no problem with it on all five SSL Bump-aware servers with new Chrome. So fare so good. 21.04.2017 18:29, Marko Cupać пишет: Hi, I have squid setup with ssl bump which worked fine, but since I updated chrome to 58 it won't display any https sites, throwing NTT:ERR_CERT_COMMON_NAME_INVALID. https sites still work in previous chrome version, as well as in IE. Anything I can do in squid config to get ssl-bumped sites in chrome again? Thank you in advance, ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] ssl bump and chrome 58
Hello together, here is a workaround that you could use in the meanwhile. https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors Source: https://www.chromium.org/administrators/policy-list-3#EnableCommonNameFallbackForLocalAnchors BEGIN EnableCommonNameFallbackForLocalAnchors Whether to allow certificates issued by local trust anchors that are missing the subjectAlternativeName extension Data type: Boolean [Windows:REG_DWORD] Windows registry location: Software\Policies\Google\Chrome\EnableCommonNameFallbackForLocalAnchors Mac/Linux preference name: EnableCommonNameFallbackForLocalAnchors Android restriction name: EnableCommonNameFallbackForLocalAnchors Supported on: Google Chrome (Linux, Mac, Windows) since version 58 until version 65 Google Chrome OS (Google Chrome OS) since version 58 until version 65 Google Chrome (Android) since version 58 until version 65 Supported features: Dynamic Policy Refresh: Yes, Per Profile: No Description: When this setting is enabled, Google Chrome will use the commonName of a server certificate to match a hostname if the certificate is missing a subjectAlternativeName extension, as long as it successfully validates and chains to a locally-installed CA certificates. Note that this is not recommended, as this may allow bypassing the nameConstraints extension that restricts the hostnames that a given certificate can be authorized for. If this policy is not set, or is set to false, server certificates that lack a subjectAlternativeName extension containing either a DNS name or IP address will not be trusted. Example value: 0x (Windows), false (Linux), false (Android), (Mac) END Am 2017-04-27 18:16, schrieb Flashdown: Hello together, Suddenly I am facing the same issue when users Chrome has been updated to V58. I am running Squid 3.5.23. This is the reason: https://www.thesslstore.com/blog/security-changes-in-chrome-58/ Short: Common Name Support Removed in Chrome 58 and Squid does not create certs with DNS-Alternatives names in it. Because of that it fails. Chrome says: 1. Subject Alternative Name Missing - The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address. 2. Certificate Error - There are issues with the site's certificate chain (net::ERR_CERT_COMMON_NAME_INVALID). Can we get Squid to add the DNS-Alternative Name to the generated certs? Since this is what I believe is now required in Chrome 58+ Best regards, Enrico Am 2017-04-21 15:35, schrieb Yuri Voinov: I see no problem with it on all five SSL Bump-aware servers with new Chrome. So fare so good. 21.04.2017 18:29, Marko Cupać пишет: Hi, I have squid setup with ssl bump which worked fine, but since I updated chrome to 58 it won't display any https sites, throwing NTT:ERR_CERT_COMMON_NAME_INVALID. https sites still work in previous chrome version, as well as in IE. Anything I can do in squid config to get ssl-bumped sites in chrome again? Thank you in advance, ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] ssl bump and chrome 58
Hello together, Suddenly I am facing the same issue when users Chrome has been updated to V58. I am running Squid 3.5.23. This is the reason: https://www.thesslstore.com/blog/security-changes-in-chrome-58/ Short: Common Name Support Removed in Chrome 58 and Squid does not create certs with DNS-Alternatives names in it. Because of that it fails. Chrome says: 1. Subject Alternative Name Missing - The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address. 2. Certificate Error - There are issues with the site's certificate chain (net::ERR_CERT_COMMON_NAME_INVALID). Can we get Squid to add the DNS-Alternative Name to the generated certs? Since this is what I believe is now required in Chrome 58+ Best regards, Enrico Am 2017-04-21 15:35, schrieb Yuri Voinov: I see no problem with it on all five SSL Bump-aware servers with new Chrome. So fare so good. 21.04.2017 18:29, Marko Cupać пишет: Hi, I have squid setup with ssl bump which worked fine, but since I updated chrome to 58 it won't display any https sites, throwing NTT:ERR_CERT_COMMON_NAME_INVALID. https sites still work in previous chrome version, as well as in IE. Anything I can do in squid config to get ssl-bumped sites in chrome again? Thank you in advance, ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] ssl bump and chrome 58
I see no problem with it on all five SSL Bump-aware servers with new Chrome. So fare so good. 21.04.2017 18:29, Marko Cupać пишет: > Hi, > > I have squid setup with ssl bump which worked fine, but since I updated > chrome to 58 it won't display any https sites, throwing > NTT:ERR_CERT_COMMON_NAME_INVALID. https sites still work in previous > chrome version, as well as in IE. > > Anything I can do in squid config to get ssl-bumped sites in chrome > again? > > Thank you in advance, -- Bugs to the Future 0x613DEC46.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
