April 2018 update broke Chrome browser (Cryptographic Services bug)

Matthew:

I wonder if home users who are affected possibly upgraded from an earlier build ie 1709 or 1703? I simply installed from an iso downloaded using the windows 10 media creation tool. This turned out to be 1809 edition. I couldn't find an earlier build to download and our school is only licensed for edu and professional through VLSC..

Yes, the problem often shows up after an update to 1803 (or now 1809), often associated with a Windows re-install and subsequent update.  It may be triggered by the monthly Windows updates, but I'm less clear on that.  It looks like, in isolated situations, the 1803 (or 1809) updates mis-configures ProtectedRoots permissions when merging the existing user data with the new Windows 18xx image.

In your .reg file, is the PeerUsages data for 'Allow peers' checked or unchecked?  If its for checked, what is the unchecked value?

After applying the dis-allow user CAs policy, is the user HKCU...ProtectedRoots still present?  If it's manually deleted,  does it now stay deleted?

If you have a user with previous Certificates under HKCU..Root\Certificates, that would be another variation to check, since those user CAs are now blocked. 

This is not a frequent usecase and occurs only when there are partners you want to trust that do not derive from the builtin Windows AuthRoot list.  If you want to play this thru, there is a US Military root CA that can be added at the user level.  (chuckle ;-) I seriously doubt if the US-Mil scenario would ever show up on your side of the pond...

Again, thanks for the feedback.  I've begun circulating the .reg update to other threads: CR838707 and the main Chrome help forum thread..

Matthew:  Picked up  the dropbox .reg file.  Imports OK, but since my Chrome never had the CryptSvc problem, I can't verify the fix.

FYI/Details

On my Win10 Home machine, before importing

  HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots

did not exist.

I assume the .reg file is the gpedit equiv of your earlier GPO post:

for Certification Path Validation Settings

  dis-allow User Trusted Root CAs

  allow (default) user trusted peer certificates

Since for policies, when a policy registry entry is not present, in general the default behavior applies, and the main reason for setting PeerUsages was to retain the default behavior, it might be cleaner to not set PeerUsages at all.  Just a thought.

To backout the registry update, the user can either 

  -delete ProtectedRoots or

  -rename it

TBD if a logout or restart is required to make the change effective.  Hope we get some feedback soon.

Did you mean Procman or Procmon?

Thanks again.  This is real progress

Yes that was the reg key created by both gpedit and GPO.

I used Procmon available here from MS

Brilliant tool but takes some getting used to (at least it did for me!)

I had the same problem with Windows home as chrome worked fine without any intervention so had no way of confirming if the registry change made a difference. However it definately does work for Education and Professional versions of win 10 1803 and 1809  using the reg file in my previus post P6/7.

I still haven't found any side affects from issuing the registry change. Updates, sophos, itunes, windows store all function as intended and if I am honest I prefer this solution to editing the permissions to the registry and cryptographic services as suggested numerous times by other members of this forum.

I wonder if home users who are affected possibly upgraded from an earlier build ie 1709 or 1703? I simply installed from an iso downloaded using the windows 10 media creation tool. This turned out to be 1809 edition. I couldn't find an earlier build to download and our school is only licensed for edu and professional through VLSC..

Hopefully somebody with Win 10 home who have the chrome problem feedback to confirm if we are any closer to finding a solution.

Matthew:  Picked up  the dropbox .reg file.  Imports OK, but since my Chrome never had the CryptSvc problem, I can't verify the fix.

FYI/Details

On my Win10 Home machine, before importing

  HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots

did not exist.

I assume the .reg file is the gpedit equiv of your earlier GPO post:

for Certification Path Validation Settings

  dis-allow User Trusted Root CAs

  allow (default) user trusted peer certificates

Since for policies, when a policy registry entry is not present, in general the default behavior applies, and the main reason for setting PeerUsages was to retain the default behavior, it might be cleaner to not set PeerUsages at all.  Just a thought.

To backout the registry update, the user can either 

  -delete ProtectedRoots or

  -rename it

TBD if a logout or restart is required to make the change effective.  Hope we get some feedback soon.

Did you mean Procman or Procmon?

Thanks again.  This is real progress

Matthew: Looks like the PeerUsages value was lost in translation - cut&paste conversion, web display...

Group Policy Registry Info - This is a Microsoft Win10 1803 spreadsheet of GPO items and registry values, but didn't contain Certification Path Validation Settings..

Thanks Larry I have uploaded to my dropbox shared directory because even when I type the registry key in manually it gets removed by the forum. Hopefully this will be of use. I also checked the permissions on the GPO dis-allowed key but they were identical both before and after the GPO was issued.

I  used Procman to locate the registry key which turned out to be in the HKLM policies folder as detailed in my previous post.

Thanks for the heads up.

All the best

Hopefully it won't.  I did a Windows Update and got the updates that were waiting and it installed them OK.  I will keep it in the back of my mind if things start acting up and put it back on Network.