April 2018 update broke Chrome browser (Cryptographic Services bug)

I have Windows Home 10 and am having the same problem.  I can try out the .reg fix if you want me to see if it fixes my problem and report back.  How can I get it?

Gregory:

See Matthew's Feb 7 reply above with

click here to download reg file to import

I believe you can omit the PeerUsages value.

Also available here as 2 .reg files: one for disabling user CAs, the second for PeerUsage, with an expanded summary.

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

After applying the GPO the dis-allow user CAs policy the  HKCU...ProtectedRoots still exists without permission changes etc.  

When the GPO is added the dword is changed to a "1" and when reverted via GPO returned to a "0". If the GPO is removed completely the values on the client still remain.However without first applying the GPO the HKLM path doesn't exist. It does allow it to be removed manually from HKLM without the need to stop the Cytographic Service.

I will try and remove the HKCU protected roots today with the GPO applied and test if it returns or remains deleted and also if the GPO still remains in a working state.

OK.  That is the .reg file I had.  I thought it may have been another one.  I also have the one without PeerUsages in it.

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

After applying the GPO the dis-allow user CAs policy the  HKCU...ProtectedRoots still exists without permission changes etc.  

When the GPO is added the dword is changed to a "1" and when reverted via GPO returned to a "0". If the GPO is removed completely the values on the client still remain.However without first applying the GPO the HKLM path doesn't exist. It does allow it to be removed manually from HKLM without the need to stop the Cytographic Service.

I will try and remove the HKCU protected roots today with the GPO applied and test if it returns or remains deleted and also if the GPO still remains in a working state.

After removing the Root folder from HKCU windows re- installs the root folder and sub keys automatically after a minute or two. I also tried adding the "Flags"=dword:00000001 to the ProectedRoots within HKCU but it gets removed by windows.  I had to add the logged on user with full control permissions to Roots otherwise I was unable to add the Dword Flags key even though I had opened regedit with administrative rights. I didn't have to stop the Cytographic service to add the Flags Dword once the permissions to the logged in user were Granted Full control, although this ended up fruitless due to the key being removed by windows.

I have tried the Registry key within HKLM without the PeerUsages key, so in essence just the Protected roots folder with the "Flags" dword set to 1 and it works fine for me. Again when changing  the Flags dword to a "0" renders Chrome useless until reverted back to a "1".