April 2018 update broke Chrome browser (Cryptographic Services bug)

Larry,

Thanks once again for the information.  This makes more sense now.  I appreciate the help.

Nick

Nick: While CryptSvc is a key security service, the impact of this particular PR:Certificates is minor.

The HKCU...SystemCertificates\Root is one of several certificate stores used by Windows, each used for one of the various control levels Windows provides, like machine, user, process, etc.  Access control and trust is a multilayered architecture.  For example, from the PowerShell ISE (console) do:

  Get-ExecutionPolicy -list

to see the scope levels:

        Scope ExecutionPolicy

        ----- ---------------

MachinePolicy     Undefined

   UserPolicy        Undefined

      Process         Undefined

  CurrentUser      Unrestricted

 LocalMachine     Restricted

The HKCU...PR:Certificates list is only used if the current user (yourself) has added Root Certificate Authorities (CA), which in your case is none.  In regedit, if you right-click Root, you'll see a Go to HKLM link, which is one of the other CA stores.

When Chrome tries to access a site, it polls all the CA store levels to see if they're healthy - regardless of whether they contain any certs.  It's this health check of the lowest level for CurrentUser that loops because of the HKCU permissions damage (and recovery attempts).

I don't have any specs for the PR:certificates value.  I can only report what I see.  I would assume the middle 16 bytes are part of the healthcheck and may include a timestamp or some other hash to verify health.

I don't have a damaged system to experiment with.  Since the rebuilt PR:Certificates value worked, I didn't look into it further.

LarryLACa, thanks for the added information.  My PR:Certificates value is just the 24 bytes since I did not have any certs under Root/Certificates.  So, given the information you provided, this makes sense.  However, it's these 24 bytes that are different after CryptSvc recreated the key and value.  Both the original 24 bytes and the replacement start and end with the 18 00 00 00 sequence as you describe.  The middle 16 bytes are what differ.  Do you know how the entire 24 byte sequence is derived, or, if not, can you say with some certainty that a change in this 24 byte sequence is normal?  I'm only digging this much because this relates to a pretty sensitive service, and I want to be sure that this is expected or normal.  Thanks again for the help.

Nick Papatonis:

To do a full before/after comparison, you also need to look at the permissions.  It's usually the permissions on the ProtectedRoots (PR) key that get cleaned up.  I watch screenshots of the registry Perms>Advanced displays.

The PR:Certificates value is a binary encoded list of the user certificates in Root/Certificates.  My notes from observed values:

=Summ; ProtectedRoots.Certificates usage #CryptSvc PR.certs

PR has (only) a "Certificates" data item

PR.cert first 24B always 18 00 00 00 * 18 00 00 00, len=24B+20B*cert#

      cert20B= cert.key= cert (.cer sha1) thumbprint

The binary Certificates begins with 24B, which begins and ends with 

 18 00 00 00, 

For each certificate, append the 20B sha1 thrumbprint.

Most users don't have any personal certificate authority certs.  These will be under the Root/Certificates, before you do the Root delete cleanup.

If you used the powershell script to do the repair, it saves and restores Root/Certificates, and the PR:Certificates binary list is rebuild accordingly.

The script also dumps/save the old permissions to ProtRoots.log.  If you rerun the script, it will append the new values (before the repair) and you can look in the log for the before/after snapshots.

If you want help with the script or log, tag in on the Chrome CryptSvc help thread here.

LarryLACa, I followed the instructions you mentioned above (and which you detailed more here, https://productforums.google.com/forum/#!topic/chrome/s5S1uPI0kMc).  It worked exactly as you indicated.  However, I compared the export of the [HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\Root\ProtectedRoots] before and after, and I found something that hopefully you can explain.  The "Certificates" binary value is different afterward.  Presumably, when the service re-added the keys and values, it initialized this with a different value.  I'm not sure what this value is exactly.  Is it a certificate thumbprint?  Is there a way to verify that this new hex id (or whatever it is) is pointing to a valid and trusted certificate on my machine?  Thanks!