Crypt32 Errors In Event Viewer After SEP 11.0 Installation

[Migration User]

I am seeing a lot of errors from Source: Crypt32 on my machines after installing SEP 11.0 Agents. We are using SEPM MR4. Is there any connection between the two? Also due to this errors the machines sometimes go into a HUNG state and recover only after a while.

The error that is sown in the Event Viewer is:

Event Type: Error
Event Source: crypt32
Event Category: None
Event ID: 8
Date: 4/25/2009
Time: 4:48:47 PM
User: N/A
Computer: XXXXX
Description:
Failed auto update retrieval of third-party root list sequence number from: <http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt> with error: This network connection does not exist.


For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

[Migration User]

Hi,

This behavior can occur if the Update Root Certificates component is turned on and the computer cannot connect to the Windows Update server on the Internet. The Update Root Certificates component automatically updates trusted root-certificate authorities from the Microsoft Update server at regular intervals.

The reason why the computer cannot connect to the Windows Update Server might be WRONG PROXY settings. SEP makes uses of the SYSTEM account for the proxy settings which are taking from a different registry keys.

Now to take care of this issue Please do the following :-

- Allow the computer to connect to the Windows Update Server
- Set up the right PROXY settings for the SYSTEM account
- Follow MS KB http://support.microsoft.com/kb/317541/en-us:
* In the SEPM server run command: proxycfg -u
* Restart IIS


http://support.microsoft.com/kb/317541/en-us


Thanks & Regards

Sandip

[Migration User]

Hi Sandip

Thanks for the prompt response. But sadly this solution doesnt help resolve the issue. I dont want to remove the UPDATE ROOT CERTIFICATES from the Windows Add Remove, so, i tried the proxy config command, but that didnt help.

When i stop the symantec services this crypt32 errors dont show up, but when i start the symantec services, immediately the errors start popping up. Im sure there is a connection between this error and symantec services. Somewhere Symantec is stopping the Root Certificates from getting updated.

I have seen these in a lot of machines in my network. I am flooded with calls due to this. The impact is that this makes the machine boot up very slowly and sometimes it even takes more than 10 minutes. But when the SEP is disabled, the same machine boots up in minutes.

Please help.

[Benjamin John]

I'm having the same exact problem with crypt32 errors after upgrading from SAV to the latest version of SEP. This definetly is an after affect from the installation of SEP. If I filter the eventlog, I can see that it started right after the installation of SEP.

We use WSUS for our microsoft updates, so I don't know why it even goes to microsoft.com for these updates anyway.
We also use a proxy server in our environment.

There's another post on this board that says the crypt errors are possible generated by the PTP scan, because it happens every hour, and that looks to be the case.

I'm sure others are having the same problem, unless maybe your machines have a direct connection to the net?

[Migration User]

Please Install Root Certificates Update (rootsupd.exe) from Microsoft

There are a few things to check:
1. Make sure your DNS is set up properly.
2. Make sure the account you are requesting with has the authority to request certificates through the Certification Authority.
3. In my case, I had to go to Add/Remove programs/Windows Components and uncheck Update Root Certificates as per M317541.
4. After all above are good, reboot.

[Benjamin John]

Anyone else have any update on this?
Thanks

[Migration User]

Here is the link for the latest Root Certificate Update.

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=f814ec0e-ee7e-435e-99f8-20b44d4531b0

These can be manually downloaded periodically and distributed into your environment if required.  You can also setup a WSUS server for the purpose of keeping your network up to date as well.  But that's a different topic for a different forum and thread.

**************

To understand the behavior, you need to understand what this update is.

Basically the root Certifcate Update is a list of vendors and distributors that are known to be good- this is the simplest explanation.

For a longer more descriptive look at what these are and how they affect you, you can read this article.

http://www.tech-faq.com/root-certificate-update.shtml

[Benjamin John]

Jason,

As I already mentioned above we use WSUS in our environment.

- This error never came up when SCS was installed. Definetly after SEP was installed.
We do use a proxy in our enivorment. Even if we were to use the solution that Sandip posted above, it still would not work for as our proxy requires authentication.

I just don't understand why this is happening just becuase we upgraded from SAV
I think as long as there is a user logged on (and that user has Internet access thru our proxy) the errors don't happen.

[Migration User]

Hi,

I also face this problem just after upgrade for SAV10 to SEP11 MR5.
But as bjohn had asked, why this issue happen just because we upgraded from SAV.

 

[Migration User]

This may me because of the presence of the firewall which is present in SEP. Try by installing only AV/AS and see any errors are appearing in event viewer .

 

[Migration User]

We just upgraded and we are encountering this same issue.

We also use WSUS and authenticaation to internet access.
 

[Migration User]

I have this same CRYPT32 error (Event ID: 8) but only on one machine (as far as I can tell thus far).  It happens to be on our SEPM Management Console machine.  Here is what I have tried thus far to fix it (unsuccessfully):

-- checked that I can access http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt using IE (I can, both with proxy turned OFF and with proxy turned ON, so I seriously doubt its a proxy issue

-- rebooted the server

-- followed Microsoft's KB article advice and ran PROXYCFG -U to ensure that proxy settings were set

-- restarted Cryptographic Services service

-- restarted IIS (and also dependant Symantec Endpoint Protection Manager service)

The error is still occurring, roughly every 11 minutes.

The error started immediately following deployment of the v11.0.5000 SEP client to the server.

The client is configured to run both AV+AS and also NTP.

We do not use SEP's firewall.

[Zinc666]

Hi all,

Had the same problem - upgraded from SAV10 to SEP11 MR5 (AV & AS only) and some workstations (but not all weirdly) started getting the crypt32 errors.  All my workstations go through an MS ISA proxy. 

Rather than muck around with proxy settings or uninstalling automatic root updates on my clients (which seems a bad idea to me anyway) I had a look at the traffic going through my proxy.  After allowing unauthenticated HTTP access to the following sites the problematic machines successfully updated their root lists;

*.download.windowsupdate.com
*.update.microsoft.com
*.windowsupdate.com
*.windowsupdate.microsoft.com
download.microsoft.com
download.windowsupdate.com
ntservicepack.microsoft.com
windowsupdate.microsoft.com
wustat.windows.com

Look out for crypt32 events 2 & 7 after a successful update.  If you use ISA 2006 there should already be a 'Microsoft Update Domain Name' set for you to use in your access rule.

Why this happens only when SEP11 is installed I don't really know (nor care to be honest) but it looks like this issue has also affected users of McAfee VSE in the past too.

Anyway, I hope this info helps.  I'll post back when I'm certain the problem is now solved on my network .

Cheers,

Zinc666

[Migration User]

OK, it looks like I may have solved my issue.  Some credit goes to ZINC666 (see above) as I followed his advice regarding proxy rules.  Unfortunately I did not keep careful notes on the exact sequence of things that I did. Here's roughly the process:

(1) checked our MS ISA Proxy 2004 setup.  I added a new firewall rule which I called "Microsoft Update" and set it so that it allowed traffic from anywhere on my network to the domains listed above (see ZINC666's post).  I specifically set it so that it would allow traffic for system services, not just authenticated users

(2) I restarted some services on my affected server:  Cryptographic Services, IIS+Symantec, as well as another that I noticed which was the WinHTTP Web Proxy Auto-Discovery Service  (not sure if any of that was required, but anyway, that's what I did).

(3) I used the PROXYCFG app to try to turn off use of the proxy by this server (I don't think this worked, but ...)

Now here's an odd thing.  The very next time the CRYPT32 process showed into the Event Log on the affected server, it was an error.  I was quite discouraged, so I decided to try Diagnostic Logging on the ISA server.

The error had been happening regularly every 11 minutes.  So I waited until about 10 seconds before it was due, turned on the logging, waited for the error ... and ... for some reason it then WORKED and did not fail.

I cannot explain this.  But it may be that between the first time it failed and the time it worked, the WinHTTP Web Proxy Auto-Discovery Service was stopped.  I am not sure.  But maybe this will help someone.

After the update worked, I checked the Event Logs on the proxy server and found a few interesting things.  At the time the update worked there were event items such as:
-- connected client was not authenticated (I presume this means it was a system service of some kind)
-- the rule Microsoft Update matches the packet.  The packet is allowed.  (This is the new rule I set up according to ZINC666's list above)

Sorry this is semi-incoherent.  But maybe someone can make some sense of it and it may help.

[Migration User]

We are having this same issue, filling our eventlogs with the Event ID 8 Crypt32 error after migrating to SEP 11.0.5.

Since we have hundreds of servers and not all of them are in a/the same domain,
this isn't something we can solve temporarily with a policy by disabling the Root Certificates Update option.
Enabling unauthenticated accounts to connect to a list of websites isn't an enterprise best practice solution.

I did not yet receive a reply on the case I submitted concerning this.
Has anyone else?

[Migration User]

I found that if I use proxycfg to force our proxy server on the system then the issue goes away, and we get a nice "Successful" event rather than the errors.

Still puzzles me why this is the case when our proxies allow all windowsupdate.com and microsoft.com traffic through, it almost seems as if SEP doesn't like direct access? Who knows.

[wroot]

We have the same problem. We don't use proxy. The problem arise only on our AD server (Windows Server 2003 R2, with also DNS, Exchange). This server was completely isolated from the internet and yet there were no crypt32 errors before upgrading to 11.0.5 (was fine with 11.0.4).

We have tried to let it connect to *.download.windowsupdate.com (we are using FortiGate external firewall) and it can access txt file mentioned in the error just fine. Also we have added all the other addresses mentioned in this thread. But it still throws that error?

I haven't yet tried to install 11.0.5 without NTP module. Maybe there will some other advices than removing modules.

[Migration User]

I have found the root cause of this issue. No one in Symantec could tell me the root cause, I figured it out for myself in the end. If you are getting Event ID 8 errors in the Event Log after installing SEP, its because SEP is using a self-signed certificate for client-server communication. Windows attempts to find the trusted root for the certificate, but because the computer account has no proxy set (or no proxy access), the update fails. This is triggered more often after SEP is installed as SEP keeps trying to use the self signed certificate.

1)      Computer account doesn’t have a proxy set, so can’t get out to the Windows Update website

2)      SEP is using a self signed certificate for client/server communication

3)      SEP uses the self signed certificate and Windows can’t find a trusted root certification authority

4)      “Update Root Certificates” component tries to connect to the internet to see if there is a new trusted certificate authority (See Turn off Automatic Root Certificates Update - http://technet.microsoft.com/en-us/library/cc749503(WS.10).aspx )

5)      Update root certificate doesn’t work as connection times out

Our solution:

1)      Turn off the updating of root certificates from the internet via GPO (see http://technet.microsoft.com/en-us/library/cc749503(WS.10).aspx )

2)      Install root certificates as part of the Windows Updates (this package does the same thing - http://support.microsoft.com/kb/931125 )

[wroot]

We have a different story so far. After letting all those MS addresses through our firewall event log started to show both successful and failed attempts with crypt32 event. Then we temporary let this server full access to the Internet and then blocked again after a few hours. Now it shows nothing. No failed and no successful events. Maybe it needed full access to update just once (after SEP upgrade) to update its root certificates storage. Will keep monitoring.

[Migration User]

We need a solution for Windows XP machines that have no internet access.  WSUS has already installed the root certificates upgrade KB931125.

[Migration User]

 Symantec recommends to remove Root Certificates

Several Events ID 8 about crypt32 after installing Symantec Endpoint Protection (SEP)

http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/1f626f1854285036802574e4002de4c7?OpenDocument 

[Migration User]

I do not want to shut off Root Certificates.  Can Symantec not come up with an actual solution to this problem instead of a band-aid fix. 

[Migration User]

We're having the exact same problem after  upgrading to SEP 11.0.5, and it looks like I'm not alone....

Can someone from Symantec provide a real fix/solution for this?  I can't believe the recommendation is to just turn off Update Root Certificate on the server.  Has it orrcurred to anyone that maybe Update Root Certificate is turned on for a reason, and that turning it off just to stop an event (generated after upgrading SEP) from being logged is not a "solution"??  What about the ramifications of turning off Update Root Certificates, has that been considered at all before telling customers to do so??  I'm starting to see the ill-effects of this problem, and am *very* hopeful that Symantec will provide a true fix to eliminate this problem while running SEP 11 in the enterprise.

Charles

[wroot]

Followup (after letting server full access to the Internet for a half day), now it randomly shows successful or failed attempts with crypt32. Last week it suddenly showed ~20 errors, but then for a 5 days it was quiet and today there was a successful event only. Weird stuff, Symantec engineers need to dig that deeper.

[Migration User]

It would be nice if an actual Symantec employee would post something on this topic. 

[Migration User]

This is absurd - I've loaded the most recent Root Certificates Update and yet I am still receiving the same CRYPT32 errors.  I sat on hold yesterday for an hour and a half and the technician I was finally routed to was next to useless.

Is anyone from Symantec going to respond to this and let us know precisely what the problem is and what they plan on doing to resolve it anytime soon?

[Migration User]

Hi all,

We're currently looking into why RU5 seems to generate more Crypt32 events than previous versions - All I can say at this time is that it isn't entirely established if this is "our" issue to fix.

I will post back once I hear more.

[Migration User]

Well we did not see the issue until we installed RU5 must be quite the coincidence that everyone else is seeing this issue too.  Not sure "whose" issue it would be then. 

[Migration User]

One suggestion is to try to update your root certificates. Please check this guide from microsoft to do so:http://support.microsoft.com/?kbid=931125. Also It might be helpful if you could post your event ID for the issue. The post everyone is tagging onto says it is event ID 8, althought I am assuming you are all seeing event ID 11.

Hope this helps,
Grant

[Migration User]

I updated root certificates and that did not solve the issue.

I am seeing Event ID 8 not 11.  

Event Type:    Error
Event Source:    crypt32
Event Category:    None
Event ID:    8
Date:        2/16/2010
Time:        6:35:41 AM
User:        N/A
Computer:   
Description:
Failed auto update retrieval of third-party root list sequence number from: <http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt> with error: The specified server cannot perform the requested operation.


For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

[Migration User]

Anything new on this?

[Migration User]

this is due to proxy settings not being configured on the server side....SEPMs need to have proper proxy configured get with the people in your company that manages these.

[Migration User]

Am seeing this also after upgrading to SEP 11 RU5

[wroot]

So, what if i don't have and don't need a proxy? It was working fine without proxies and crypt32 errors before upgrading to RU5.

[Migration User]

I am not using a proxy server. 

[Migration User]

In my situation I tried all of the client side fixes that have been announced or described on thi post. So we started looking on the server end of things. After we placed the proxy in the SEPMs config the errors in the event logs stopped immediately. We started migrating to Sep11 last year. So I cant say when we noticed the errors, perhaps perhaps the errors had been there all along we just did not noticed them. So i cant specualte on how or what. Many times working in IT for a multinational corporation its easier to just find a fix and implement it vs tring to figure out exact root cause. We know one thing for certain, sep11 is the cause because removing it from the clients resolves the error loggin as well. So for what ever is worth. Good Luck!

[Migration User]

lol

[Migration User]

I've posted it some months ago here : https://www-secure.symantec.com/connect/pt-br/forums/several-events-id-8-about-crypt32-after-installing-symantec-endpoint-proteseveral-events-id-8

[Migration User]

I guess it took a month to fix a simple date issue with SEP.  Why not take a year to fix the Crypt error. 

[Migration User]

Has anyone tried changing the SEP service to run as a user with proxy-ability?  Just curious if that might solve the issue.

[Migration User]

Thanks for all the help on this issue Syamntec.  Your technical support is great. 

[Migration User]

Hi everybody,

Someone had solve this problem with crypt32 event? I'm having the same trouble with one of our server and, coincidentally, it's installed SEP 11 on this.

Best regards.

[wroot]

Of course not, because developers are not providing any fix or solution for this. On my server it now occurs not so often as before. Maybe once per 2 weeks or so.

[Migration User]

This is the MS explanation for the group policy to turn off automatic root certificate updates:

Specifies whether to automatically update root certificates using the Windows Update Web site.

Typically, a certificate is used when you use a secure Web site or when you send and receive secure e-mail. Anyone can issue certificates, but to have transactions that are as secure as possible, certificates must be issued by a trusted certificate authority (CA). Microsoft has included a list in Windows XP and other products of companies and organizations that it considers trusted authorities.

If you enable this setting, when you are presented with a certificate issued by an untrusted root authority your computer will not contact the Windows Update web site to see if Microsoft has added the CA to its list of trusted authorities.

If you disable or do not configure this setting, your computer will contact the Windows Update Web site.

If I am interpreting this explanation correctly, Symantec is presenting a "certificate issued by an untrusted root authority". 

We are currently using group policy to prevent the crypt32 errors and WSUS is providing periodic root certificate updates.

[Migration User]

I am also facing this problem and I think as my sepm server is unable to connect to internet from past few days due to some problem.

[Migration User]

Thanks to Matt will fix it for the link.

1)      Turn off the updating of root certificates from the internet via GPO (see http://technet.microsoft.com/en-us/library/cc749503(WS.10).aspx )

In your face Crypt32!

[Migration User]

I just removed "Update root certificates" from add remove windows components and it worked for me as no crypt32 error anymore.

[Migration User]

I do not want to remove Root Certificates.  I can't believe in over a year this is the only solution to this problem. 

[Benjamin John]

If you have a WSUS server in place, your root certificates will be updated by WSUS even if they are turned off in GP.

[Migration User]

I have had the same problem since SEP 11.5 was installed onto one of my servers a couple of weeks ago. Finally today I get time to sit down and look at it - can't believe the long running comments and lack of answers.

I don't want to disable the root certificate updates, I personally believe that (most) of the updates provided by MS are needed.

We were running SAV 10 previously and didn't have these issues, they started about 5 mins after SEP11.5 was installed.

A simple solution from MS, KB317541, is to open up a command prompt and type in proxycfg -u

This seems to import any proxy settings im using logged on as Administrator into the system account.

In an instant the crypt32 errors stopped popping up and have had no problems over the past couple of hours.

Hope it helps some of you out there!

SC

[wroot]

Well, i have tried this command now, and got such answer

C:\Documents and Settings\Administrator>proxycfg -u
Microsoft (R) WinHTTP Default Proxy Configuration Tool
Copyright (c) Microsoft Corporation. All rights reserved.

Updated proxy settings
Current WinHTTP proxy settings under:
  HKEY_LOCAL_MACHINE\
    SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\
      WinHttpSettings :

     Direct access (no proxy server).

I'm not sure it could help as i dont have any proxy. I suggest to monitor your logs, these errors still can come back. In my case a few error entries appear once per week.

[Migration User]

Hi,

This issue has been logged with Symantec and I can assure it is getting top priority as present!  We have weekly calls with them and once I have a solution will post it on the forum.

[Migration User]

MS KB 317541 worked fine for me, but only for x86 systems (See - http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/1f626f1854285036802574e4002de4c7?OpenDocument)

For x64 boxes I used the same method, but deferent tool:
c:\windows\sysWow64\proxycfg -u
(See description here - http://blogs.msdn.com/b/jpsanders/archive/2009/07/21/winhttp-proxy-configuration-on-windows-2003-x64.aspx)
 

[ℬrίαη]

I tried this for the 32bit server but getting "Error writing proxy settings"

[Migration User]

My solution was a simple one. I installed .NET Framework 3.5 SP1. No more errors.

[Migration User]

You installed the update on the SEPM or on the client?

[Migration User]

Hello!

I don't know did anyone found the real solution, but below is what I did to bypass it.

Preamble: our enterprise has 2 sites with different IP subnets.

Computer1 (ISA, upgraded SEP from 11.01 to 11.061) had Crypt32 error. It locates in Subnet1.

Computer2 (SEMP) is in the main office (Subnet2). SEMP has proxy settings, pointing on Computer3 (ISA, SEP 11.061 and main gateway/proxy for Subntet2).

First of all I checked out that Computer1 has Internet access itself. The access is granted. Then I tried to open URL mentioned in EventLog. Success! “Proxycfg –u” shows me nothing but "Direct access (no proxy server)". Reading this post I found srussolillo’s reply (In my situation I tried all) that gave me some idea: probably proxy-server settings configured in SEPM are propagated to all SEP’s client.

After that I created new access rule on Computer3 allowing Computer1 to connect to http://www.download.windowsupdate.com/msdownload/bla-bla-bla, and restart SEP service. As soon as SEP started I received 2 events indicated that retrieval of third-party root list was successful.

Try to grant access to computers with Crypt issue to windowsupdate. May be that will help.

Apparently guys form Symantec made new feature with proxy setting inheritance. But why?