ITMS Clients Fail to Download Packages/Upgrade via CEM with "Certificate Chain Not Trusted" (0x80090325) or DNS/Connection Errors
search cancel

ITMS Clients Fail to Download Packages/Upgrade via CEM with "Certificate Chain Not Trusted" (0x80090325) or DNS/Connection Errors

book

Article ID: 421148

calendar_today

Updated On:

Products

IT Management Suite

Issue/Introduction

It was reported that a subset of IT Management Suite (ITMS) clients, particularly those running older Symantec Management Agent (SMA) versions like 8.7.x, are failing to download packages or execute tasks, including necessary SMA upgrades, when operating in Cloud-enabled Management (CEM) mode.

Symptoms observed on the client:

  • Package Download Failure: Clients cannot download packages from Site Servers (SS) or Package Servers (PS) when communicating through the CEM Gateway.

  • Log Errors: The Symantec Management Agent (SMA) logs show errors related to network communication failures during the connection attempt to the Gateway or Package Server.


Initial agent log entries noticed during troubleshooting:

Agent logs:

Operation 'Direct: Connect' failed.
Url: HTTPS://SS015.example.com:4726/Altiris/PS/getpackagesnapshot.asp?Resource=%7BA6C6xxxx-xxxxxxxxxxxxEC073137D%7D&PackageId=%7B83E0490E-F566-4E36-9E32-148D7B5EBBA7%7D&compress=1
Connection path: 5? - Direct: [10.100.166.147] -> SS015.example.com [Unknown]
Connection id: 
Communication profile id: {C656xxxx-xxxxxxxxxxxxx61175B}
Throttling: 0 0 0
Connecton stage: DNS resolve
Error type: DNS error
Error code: No such host is known (11001)
Error note: Failed to resolve host name 'SS015.example.com' to an IP address
Connection path id: f3 30 1f af 18 20 19 92 3c 78 14 e9 90 cc 91 bd 85 e0 58 4d
-----------------------------------------------------------------------------------------------------
Date: 10/17/2025 9:15:03 AM, Tick Count: 999035562 (11.13:30:35.5620000), Host Name: Client-5430, Size: 931 B
Process: AeXNSAgent.exe (13792), Thread ID: 11836, Module: AeXNetComms.dll
Priority: 1, Source: NetworkOperation

 

Download Snapshot failed: Failed to resolve host name 'SS015.example.com' to an IP address (-2147013895)
-----------------------------------------------------------------------------------------------------
Date: 10/17/2025 9:15:03 AM, Tick Count: 999035562 (11.13:30:35.5620000), Host Name: Client-5430, Size: 360 B
Process: AeXNSAgent.exe (13792), Thread ID: 11836, Module: AeXPackageDelivery.dll
Priority: 1, Source: PackageDownload
 

Error while downloading package: Failed to resolve host name 'SS015.example.com' to an IP address
-----------------------------------------------------------------------------------------------------
Date: 10/17/2025 9:15:03 AM, Tick Count: 999035562 (11.13:30:35.5620000), Host Name: Client-5430, Size: 353 B
Process: AeXNSAgent.exe (13792), Thread ID: 11836, Module: AeXPackageDelivery.dll
Priority: 1, Source: PackageDelivery

 

Operation 'Direct: Connect' failed.
Url: HTTPS://SS020.example.com:4726/Altiris/PS/getpackagesnapshot.asp?Resource=%7BA6C6xxxx-xxxxxxxxxxxxEC073137D%7D&PackageId=%7B47E1F709-5EF8-44EA-9A1A-955620A09ED4%7D&compress=1
Connection path: 5? - Direct: [10.100.166.147] -> SS020.example.com [Unknown]
Connection id: 
Communication profile id: {C656xxxx-xxxxxxxxxxxxx61175B}
Throttling: 0 0 0
Connecton stage: DNS resolve
Error type: DNS error
Error code: No such host is known (11001)
Error note: Failed to resolve host name 'SS020.example.com' to an IP address
Connection path id: 37 87 c0 xxxxxxxxxxxx 29 ab
-----------------------------------------------------------------------------------------------------
Date: 10/9/2025 7:04:15 AM, Tick Count: 299987437 (3.11:19:47.4370000), Host Name: Client-5430, Size: 931 B
Process: AeXNSAgent.exe (13792), Thread ID: 11836, Module: AeXNetComms.dll
Priority: 1, Source: NetworkOperation

 

On Site Server:

SetWsConnection: stalled WS connection detected for endpoint (will expire): agent=78af5180-efde-4c46-b3af-472907bc4508, auth=True, addr=10.xxx.xx.216:64231 (Opened), conn-id=8218708a-c1e3-437a-9381-0f51af108dae, age=00:11:26.0426363
 new connection: agent=78af5180-efde-4c46-b3af-472907bc4508, auth=True, addr=10.xxx.xx.222:51729 (Opened), conn-id=6faae51f-1d76-47bd-a0b5-fc4915b14792, age=00:00:00.0781806
-----------------------------------------------------------------------------------------------------
Date: 11/11/2025 8:23:15 AM, Tick Count: 123669031 (1.10:21:09.0310000), Host Name: SS015, Size: 631 B
Process: AtrsHost.exe (4660), Thread ID: 7732, Module: AtrsHost.exe
Priority: 2, Source: ClientStatus

Environment

ITMS 8.7.x, 8.8.x

Cause

The primary issue stems from a configuration discrepancy in the Cloud-enabled Management Settings policy on the Symantec Management Platform (SMP Server or Notification Server (NS)). The key contributing factors are:

  1. CEM Gateway Certificate Thumbprint Mismatch: The SMA clients are using an outdated or incorrect Gateway Certificate Thumbprint stored in their CEM policy. This mismatch leads to a TLS Handshake Error (0x80090325) when connecting to the live CEM Gateway.

  2. Incorrect Policy Targeting: The default policy target for the CEM Settings policy (Based from  default filter "All Computers where the Cloud-enabled Management feature is enabled") was not including all necessary clients, preventing the delivery of the corrected CEM configuration.

  3. Secondary Network Block: A separate, confirmed network timeout (Error 10060) was also observed for a secondary Gateway, indicating an independent firewall/network configuration issue that should be addressed in parallel.

 

The confirmed root cause is a CEM Configuration Policy Discrepancy that prevented clients from trusting the Gateway's security certificate.

Primary Root Cause: CEM Certificate Thumbprint Mismatch

The log analysis confirms that the SMA is actively rejecting the connection because of a security incompatibility related to the certificate chain:

Log Excerpt (Client Logs: \Agent_xxx.log) Error Type and Code Explanation
Error type: TLS handshake error Error code: The certificate chain was issued by an authority that is not trusted (0x80090325) The SMA client cannot validate the Gateway's certificate, explicitly stating a 'thumbprint mismatch'. This means the SHA-1 or SHA-256 fingerprint of the current certificate on the Gateway does not match the one recorded in the client's CEM policy.
Error note: 'Gateway017.example.com' server's certificate is not valid, thumbprint mismatch    

Secondary Root Cause: Policy Target Exclusion

The default CEM policy target, based on default Filter "All Computers where the Cloud-enabled Management feature is enabled," was not used. The older, non-working clients were not listed in this target, meaning the corrected CEM policy (containing the updated thumbprint) could not be delivered to them. This is common in complex environments where client status or network settings might prevent them from being accurately classified under the default filter.

Tertiary/Parallel Issue: Network Connectivity Block

A different set of errors points to a basic network block for a secondary Gateway:

Log Excerpt (Client Logs: \Agent_xxx.log) Error Type and Code Explanation
Error type: Connection error Error code: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond (10060) This is a TCP timeout. The client could not establish a connection to the specified Gateway on port 443, indicating an external firewall or security group block.
Connection stage: Gateway connect    

 

Just as a reference for understanding what the agent logs are saying, here is the basic analysis thread:

  1. The evidence points toward a Cloud-enabled Management (CEM) certificate issue being the primary cause for the non-working clients, specifically an outdated or incorrect Gateway Certificate Thumbprint.
  2. A critical TLS Handshake error (0x80090325) related to the CEM Gateway certificate.

The core problem is related to a specific security incompatibility where the older SMA client (8.7.3391) is invalidating the CEM Gateway’s certificate, preventing all further task and package communication, including the critical SMA upgrade package.

What we saw on the agent logs:

One of the initial concerns because of some persistent connections errors in the agent logs can be discarded because:
Persistent connection is not used to download packages from the site servers, persistent connection to NS is used to get policies, persistent connection to site server can be used by client task agent only, which is not used during SMA upgrade.

 

The difference between working and non-working clients is in CEM policies

The working client:

Connection paths to: https:SS020.example.com:443 HTTPS://SS020.example.com:443/Altiris/WebSockets
1.1 - Via gateway 1: [10.xxx.166.127] -> Gateway017.example.com [5x.xx.xxx.178:443] -> SS020.example.com:443,
2.1 - Via gateway 1: [10.xxx.166.127] -> Gateway017.example.com [5x.xx.xxx.181:443] -> SS020.example.com:443,
3.1 - Via gateway 1: [10.xxx.166.127] -> Gateway017.example.com [5x.xx.xxx.178:443] -> SS020:443,
4.1 - Via gateway 1: [10.xxx.166.127] -> Gateway017.example.com [5x.xx.xxx.181:443] -> SS020:443,
5.2 - Via gateway 2: [10.xxx.166.127] -> Gateway016.example.com [5x.xx.xxx.178:443] -> SS020.example.com:443,
6.2 - Via gateway 2: [10.xxx.166.127] -> Gateway016.example.com [5x.xx.xxx.181:443] -> SS020.example.com:443,
7.2 - Via gateway 2: [10.xxx.166.127] -> Gateway016.example.com [5x.xx.xxx.178:443] -> SS020:443,
8.2 - Via gateway 2: [10.xxx.166.127] -> Gateway016.example.com [5x.xx.xxx.181:443] -> SS020:443,
9.0? - Direct: [10.xxx.166.127] -> SS020.example.com [Unknown],
10.0? - Direct: [10.xxx.166.127] -> SS020 [Unknown] 

 

The not-working client:

Connection paths to: https:SS015:443 HTTPS://SS015/Altiris/PS/getpackagesnapshot.asp?Resource=%7B32a7xxxxxx-xxxx-xxxx-xxxx-xxxxxxe0b586%7D&PackageId=%7B83E0490E-F566-4E36-9E32-148D7B5EBBA7%7D&compress=1
1.2 - Via deleted gateway 2: [10.xxx.166.116] -> Gateway017.example.com [5x.xx.xxx.178:443] -> SS015.example.com:443,
2.2 - Via deleted gateway 2: [10.xxx.166.116] -> Gateway017.example.com [5x.xx.xxx.181:443] -> SS015.example.com:443,
3.2 - Via deleted gateway 2: [10.xxx.166.116] -> Gateway017.example.com [5x.xx.xxx.178:443] -> SS015:443,
4.2 - Via deleted gateway 2: [10.xxx.166.116] -> Gateway017.example.com [5x.xx.xxx.181:443] -> SS015:443,
5.1 - Via deleted gateway 1: [10.xxx.166.116] -> Gateway016.example.com [5x.xx.xxx.178:443] -> SS015.example.com:443,
6.1 - Via deleted gateway 1: [10.xxx.166.116] -> Gateway016.example.com [5x.xx.xxx.181:443] -> SS015.example.com:443,
7.1 - Via deleted gateway 1: [10.xxx.166.116] -> Gateway016.example.com [5x.xx.xxx.178:443] -> SS015:443,
8.1 - Via deleted gateway 1: [10.xxx.166.116] -> Gateway016.example.com [5x.xx.xxx.181:443] -> SS015:443,
9.0? - Direct: [10.xxx.166.116] -> SS015.example.com:443 [Unknown],
10.0? - Direct: [10.xxx.166.116] -> SS015 [Unknown]

The "deleted" keywords means that CEM mode was switching off for that client, it could be that they hit server's bug that was fixed sometime this year only, where CEM policy could disappear for a client, already fixed in our ITMS 8.8 release.

Or they were trying changing the gateways' certificate and did that incorrectly.

The connection to SS016 fails because it does not answer, see log record below. It does not matter that the connection attempt was to a task server in the log record because the failure point is the gateway, the same error would occur if PS connection was performed.

Operation 'CEM: Connect' failed.
Url: HTTPS://SS020.example.com:443/Altiris/ClientTaskServer/Register.aspx?lastResort=true&resTypeGuid=%7B493435F7-xxxx-xxxx-xxxx-xxxxxxB7781F%7D&sysType=Win64&version=8.7.3391&resourceGuid=32a7xxxxxx-xxxx-xxxx-xxxx-xxxxxxe0b586&crc=0008000700000D3F
Connection path: 8.1 - Via deleted gateway 1: [10.xxx.166.116] -> {*}Gateway016.example.com [5x.xx.xxx.181:443{*}] -> SS020:443
Connection id: 1629.7236
Communication profile id: {6217C5E9-xxxxxxxxx-4E8032BED3D0}
Throttling: 0 0 0
Connection stage: Gateway connect
Error type: Connection error
Error code: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond (10060)
Error note: Failed to connect sync socket 0000000000001B68 to 5x.xx.xxx.181:443
Connection path id: bd b2 24 42 ab 1b 8f 50 5b 30 14 b5 05 59 79 60 87 8f c9 bd
-----------------------------------------------------------------------------------------------------
Date: 12/1/2025 1:12:14 PM, Tick Count: 40302984 (11:11:42.9840000), Host Name: Client-5430, Size: 1.17 KB
Process: AeXNSAgent.exe (7236), Thread ID: 12572, Module: AeXNetComms.dll
Priority: 8, Source: NetworkOperation

 The connection to Gateway017 fails because the client cannot validate the gateways' certificate, see log record below. So they probably use custom gateway certificate, and they did try changing it at some point and this client just has not completed the changing process for some reason.

 Operation 'CEM: Connect' failed.
Url: HTTPS://SS015/Altiris/PS/getpackagesnapshot.asp?Resource=%7B32a7xxxxxx-xxxx-xxxx-xxxx-xxxxxxe0b586%7D&PackageId=%7B83E0490E-F566-4E36-9E32-148D7B5EBBA7%7D&compress=1
Connection path: 1.2 - Via deleted gateway 2: [10.xxx.166.116] -> Gateway017.example.com [5x.xx.xxx.178:443] -> SS015.example.com:443
Connection id: 1634.7236
Communication profile id: {A6xxxxxx-xxxx-xxxx-xxxx-xxxxxx20C519}
Throttling: 0 0 0
Connecton stage: Gateway connect
Error type: TLS handshake error
Error code: The certificate chain was issued by an authority that is not trusted (0x80090325)
Error note: 'Gateway017.example.com' server's certificate is not valid, thumbprint mismatch
Gateway SSL connection info:
  Server certificate:
      Serial number: xx xx xx xxxxxxxx dd d9 2f
      Thumbprint: xx xx xx xxxxxxxx 9d f2 cf
  Client certificate:
      Serial number: 5f xx xx xx xxxxxxxxxx xx xx 65 dc 9d
      Thumbprint: fd xx xx xx xxxxxxxxxx xx xx 9b 98 68
  Cryptographic protocol: TLS 1.3
  Cipher suite: TLS_AES_256_GCM_SHA384
  Cipher algorithm: AES
  Cipher key length: 256
  Hash algorithm: 
  Hash length: 0
  Key exchange algorithm: 
  Key length: 384
Client SSL attributes for gateway connection:
  Client certificate:
      Serial number: 5f xx xx xx xxxxxxxxxx xx xx 65 dc 9d
      Thumbprint: fd xx xx xx xxxxxxxxxx xx xx 9b 98 68
  Cryptographic protocol: TLS 1.0, 1.1, 1.2, 1.3
Connection path id: 9f f5 xxxxxxxxxxxxxxxx 07 70 7c
-----------------------------------------------------------------------------------------------------
Date: 12/1/2025 1:13:09 PM, Tick Count: 40358140 (11:12:38.1400000), Host Name: Client-5430, Size: 1.91 KB
Process: AeXNSAgent.exe (7236), Thread ID: 6276, Module: AeXNetComms.dll
Priority: 8, Source: NetworkOperation

Check with the customer for the current Gateway017 certificate. Is it 

      Serial number: xx xx xx xxxxxxxx dd d9 2f
      Thumbprint: xx xx xx xxxxxxxx 9d f2 cf

Resolution

The resolution involves two main phases: correcting the CEM Policy certificate data and ensuring the policy is correctly targeted to all affected clients. The network block must be addressed by the network team.

Symptom / Error Message

Root Cause

Resolution / Verification

Log Error: Error code: The certificate chain was issued by an authority that is not trusted (0x80090325)

CEM Gateway Certificate Thumbprint Mismatch. The certificate thumbprint used by the live CEM Gateway does not match the thumbprint cached on the older SMA client, as defined in its CEM policy. This is common after a Gateway certificate renewal or reinstall where the new thumbprint fails to propagate.

Immediate Action: Correct the thumbprint in the CEM Configuration policy on the Notification Server (NS) to match the current Gateway certificate.
Secondary Action: Ensure the correct CEM policy is successfully pushed to all affected clients.

Log Error: Failed to connect sync socket... (10060) to Gateway016.example.com

Gateway Connectivity/Firewall Block. A connection timeout indicates a network block preventing the client from establishing a TCP handshake on port 443 with the Gateway. The issue is at the Gateway connect stage, not DNS resolution.

Perform network diagnostics (Telnet/TCP test) from the Gateway/NS toward the client. Confirm firewall rules are open for the specific traffic between the Gateway and the Task Server, ensuring port 443 is unblocked.

 

 

Phase 1: Correcting the CEM Policy and Target

The core fix is to ensure the Cloud-enabled Management Settings policy contains the correct, current certificate thumbprint and is successfully delivered to all clients.

1. Verify the Current CEM Gateway Certificate Thumbprint

  • Action: Immediately verify the Server Certificate Thumbprint installed on the physical CEM Gateway machine (e.g., Gateway017.example.com).

  • Path: Open the certificate manager on the Gateway machine and locate the server certificate used for CEM. Copy the Thumbprint value.

  • Crucial Comparison: Compare this live thumbprint against the thumbprint referenced in the failing client's log to confirm the mismatch:

    • Log Thumbprint: xx xx xx xxxxxxxx 9d f2 cf

    • Log Serial Number: xx xx xx xxxxxxxx dd d9 2f

2. Correct the Gateway Entry in the CEM Policy

  • Action: On the Symantec Management Console, navigate to Settings > Notification Server > Cloud-enabled Management > Policy > Cloud-enabled Management Settings.

  • Action: Edit the Gateway entry corresponding to the affected Gateway (e.g., Gateway017.example.com).

  • Action: Update the Server Certificate Thumbprint field with the correct, current thumbprint value verified in Step 1.

3. Modify the CEM Policy Target to Include All Affected Clients

Since the default target was insufficient, broadening the scope ensures the fixed policy reaches the non-communicating clients.

  • Action: In the Cloud-enabled Management Settings policy, review the Target.

  • Action: Change the Target to a filter that is confirmed to contain all affected clients. The most successful approach reported by the customer was changing the target to a broader group, such as "All Windows Computers meeting Cloud-enabled Management criteria" or a custom filter designed to include all systems where CEM is possible.

    • Note: Changing the target to "All Computers" is an effective, though broader, way to ensure every client receives the updated certificate information, which is critical for clients with communication issues but needs to be used with caution since no "All Computers" may have enabled for CEM mode .

4. Validate Policy Delivery and Package Download

  • Verification: After updating the policy target and the thumbprint, the affected clients should now receive the corrected CEM configuration.

  • Action: Initiate a manual configuration request on an affected client (or wait for the next scheduled policy request) to force the policy update.

  • Verification: Confirm that the client can now successfully connect to the Gateway and download packages. Check the client logs for successful NetworkOperation entries instead of the old TLS error.

 

Phase 2: Investigating the Secondary Network Timeout (Error 10060)

This must be addressed by the networking team, as it is a separate physical/network issue.

  • Action: Engage your networking team (or cloud provider team, if hosted in AWS) to investigate the network connection block between the client IP range and the secondary Gateway (e.g., Gateway016.example.com).

  • Diagnostic Tool: Use a tool like Telnet or a custom TCP test from an affected client's network to the Gateway's external IP on port 443 (e.g., telnet [Gateway IP] 443).

  • Action: Verify that the firewall rules, security groups (e.g., AWS Security Groups), and Access Control Lists (ACLs) are correctly configured to permit traffic on TCP/443 (or the specific port used by the Gateway) between the client's network and the Gateway.

Powered by Wolken Software