Google Chrome 58.0.3029.81 not working with DWP Client 5.1.025

  • 25 April 2017
  • 8 replies
  • 73 views

Userlevel 1
Webroot no longer works since moving to chrome Version 58.0.3029.81
Is there any fix or time frame on when this will be fixed?
 
You get the following error:
 
Your connection is not private
Attackers might be trying to steal your information from www.google.ca (for example, passwords, messages, or credit cards).
NET::ERR_CERT_COMMON_NAME_INVALID   

8 replies

Userlevel 7
Badge +56
Hello and Welcome to the Webroot Community!
 
I don't see any issue's with my Chrome Browser so I would suggest that you Submit a Support Ticket and ask them to look into it for you!
 
Thanks,
 
Daniel 😉
Userlevel 7
Badge +56
@ Also your Browsers are protected by WSA and WSA's Identity Shield! http://live.webrootanywhere.com/content/608/Managing-Identity-Protection
 


 
 
 
 
Userlevel 1
I have a ticket in with webroot Case #: 00081620 since friday.
They have replicated the issue.
if I disable the webroot proxy (DWP Client 5.1.25.24990) it works. I don't think WSA (Webroot SecureAnywhere Endpoint Protection v9.0.15.50) is the issue.

I may be in the wrong part of the forum.
Userlevel 7
Badge +56
@ wrote:
I have a ticket in with webroot Case #: 00081620 since friday.
They have replicated the issue.
if I disable the webroot proxy (DWP Client 5.1.25.24990) it works. I don't think WSA (Webroot SecureAnywhere Endpoint Protection v9.0.15.50) is the issue.

I may be in the wrong part of the forum.
Yes you are in the Consumer section I will ask one of the admins to move your posts to the correct forum, but keep in contact with support so they can correct your issue. @ @
 
Thanks,
-Daniel
Got the same issue, thankfully not too many users use Chrome fulltime.
 
My ticket is 81846...
 
It's definitely the SSL inspection certificate causing the issue.
 
Oddly enough, google.com was blocked, but when we changed the URL to google.com.au, it would let us through...  But other non-Google domains are affected as well.
 
Userlevel 4
This is a workaround that I found which might work for this issue in the sort term: As a workaround, a Windows registry key can be created to allow Google Chrome to 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.
  • Data type: Boolean [Windows:REG_DWORD]
  • Windows registry location: HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChrome
  • Windows/Mac/Linux/Android preference name: EnableCommonNameFallbackForLocalAnchors
  • Value: 0x00000001 (Windows), true(Linux), true (Android), <true /> (Mac)
To create a Windows registry key, simply follow these steps:
  1. Open Notepad
  2. Copy and paste the following content into notepadWindows Registry Editor Version 5.00[HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChrome]"EnableCommonNameFallbackForLocalAnchors"=dword:00000001
  3. Go to File > Save as Filename: any_filename.reg Save as type: All Files
  4. Select a preferred location for the file
  5. Click on Save
  6. Double click on the saved file to run
  7. Click on Yes on the Registry Editor warning
It is recommended to back up your registry in Windows before making any changes. See the following Microsoft KB article on how to back up and restore the registry in Windows.
Note: This registry key change can be deployed to all users via group policy management console in Windows server operating systems.
A Registry hack for a security bypass that should only be used until an issue is fixed is not really recommended, though. At that point, you may as well disable SSL inspection, at least that setting can be flicked back on in a short time without having to modify a group policy and waiting for that to apply.
I am using chrome while doing all of this and I also have webroot installed, and I haven't had a single problem nor has an error message like that ever popped up telling me that.

Reply