This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
I updated to the April 2018 version of Win10 a couple months ago. It caused several issues and broke my Chrome browser completely, so I reverted back to the old version. But Microsoft forced another update on me, so I need this issue fixed somehow.
All the googling I've done says Microsoft has "fixed" this issue with the April update breaking Chrome, but I've installed all patches and they clearly haven't, not in my case. Pages simply refuse to load and time out.
I've narrowed the issue down to the "Cryptographic Services" service. If I stop the service, all of the Chrome pages instantly load and I have no issues for about an hour. It seems to be some sort of issue with certificates/SSL.
The problem is the service keeps restarting itself. I've tried setting it to "disabled," tried unchecking the service in System Configuration, nothing works. It always comes back and Chrome breaks. I'm sure there's good reason to keep it running but I'm not going to let Microsoft force me out of my favorite browser/bookmarks/extensions/etc. like this, and I can't keep stopping a service every hour just to browse the web.
So I need a solution please. And something specifically related to fixing the issue with Cryptographic Services preventing SSL on Chrome. I've done all the basic stuff like reinstalling Chrome, checking firewall settings, etc..
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
I just did but there were no updates available! but I'm sure everything works fine now!!
thanks again for this great fix. to get rid of the ROOT file i had to take full control as an administrator! since your fix Goolge works perfect.!! I had no time outs till now!
greetings,
will theus
˙ǝuıɟ buıʞɹoʍ ǝq oʇ sɯǝǝs buıɥʇʎɹǝʌǝ puɐ osןɐ ǝʇɐpdn ǝɥʇ pıp ı
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!
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, 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.
