Certificate Subject Name Mismatch (0x800B010F) Prevents Task Server and Client Registration in ITMS

Products

IT Management Suite

Issue/Introduction

Systems—including Task Servers and client devices—are unable to complete registration with the Symantec Management Platform (SMP).

While basic communications like receiving new configuration and sending basic inventory seem to function, the ability to receive and execute tasks is broken due to a communication failure during Task Server registration.

Environment

ITMS 8.7.x, 8.8

Cause

The root cause of this failure is a TLS handshake error stemming from a certificate subject name mismatch. The client (or Task Server agent) is attempting to connect to the Notification Server (NS) using a specific hostname (e.g., short name or IP), but the SSL certificate presented by the NS does not have that hostname listed as its Common Name (CN) or as a Subject Alternative Name (SAN).

The specific error code seen in the agent logs is 0x800B010F, which translates to: "The certificate's CN name does not match the passed value." This occurs when the name used in the Agent Communication Profile does not match the valid names in the NS's SSL certificate.

The following excerpts from the agent log file (located in C:\ProgramData\Symantec\SMP\Logs) show the specific errors:

Log Entry Excerpt (Masked)	Interpretation
Url: HTTPS://SMPServer2018.EXAMPLE.net/Altiris/TaskManagement/CTAgent/GetClientTaskServers.aspx?resourceGuid=...	The agent is trying to reach the Task Server endpoint using FQDN SMPServer2018.EXAMPLE.net.
Connection path: 2 - Direct: [10.xx.xxx.219] -> SMPServer2018 [10.xx.xxx.219:443]	Shows the connection attempt via IP, but the hostname is what triggers the certificate validation.
Error type: TLS handshake error	Confirms the secure connection failed before data could be exchanged.
Error code: The certificate's CN name does not match the passed value (0x800B010F)	The core error: The name the agent is using does not match the certificate's subject.
Task Server Connection: Failed to receive persistent properties from NS, error: The certificate's CN name does not match the passed value (0x800B010F)	Confirms the failure blocks Task Server registration steps.

The confirmed root cause is a Certificate Subject Name Mismatch.

When the Symantec Management Agent attempts to establish a secure (HTTPS) connection, the hostname it uses for the connection must be present in the server's SSL certificate, either as the Common Name (CN) or within the Subject Alternative Name (SAN) field. Error $\text{0x800B010F}$ indicates this check failed.

This is often caused by:

Agent Communication Profile Discrepancy (Most Likely): The profile is configured to use an FQDN or IP address that was not included when the NS's SSL certificate was generated.
Duplicate Communication Profile: An older, incorrect profile is still active and being used by clients, causing them to connect using an outdated or non-matching name.

Resolution

The resolution involves ensuring that the hostname/FQDN the agents use to connect to the Notification Server is precisely included in the NS's SSL certificate, or changing the Agent Communication Profile to use a name that is on the certificate.

Phase 1: Diagnosis - Check the Certificate and Agent Profile

Check the Notification Server's SSL Certificate:
- On the NS, open Internet Information Services (IIS) Manager.
- Navigate to Sites and select Default Web Site.
- In the Actions pane, click Bindings....
- Select the binding for https on port $\text{443}$ and click Edit....
- Click View next to the SSL certificate name.
- Go to the Details tab and check the Subject (CN) and Subject Alternative Name fields. Note down every exact FQDN/hostname listed.
Check the Agent's Communication Profile:
- On the SMP Console, navigate to Settings > All Settings > Agents/Plug-ins > Symantec Management Agent > Symantec Management Agent Communication Profiles.
- Check the Primary URL and Alternate URL settings.
- Crucial Step: The addresses listed here must be an exact match for one of the CN or SAN values noted in Step 1.

Communication Profile Setting	Agent Log URL	Match Requirement
`Primary URL` or `Alternate URL`	`HTTPS://SMPServer2018.EXAMPLE.net/...`	The FQDN (`SMPServer2018.EXAMPLE.net`) must be present in the certificate's CN or SAN field.

Phase 2: Resolution - Update the Profile or Certificate

Follow Option A if the certificate is correct, or Option B if the certificate is missing the required name.

Option A: Update the Agent Communication Profile (Recommended)

If the certificate is correct but the Agent Profile is using an incorrect name, update the profile to use a name that is listed on the certificate.

On the SMP Console, go to Settings > All Settings > Agents/Plug-ins > Symantec Management Agent > Symantec Management Agent Communication Profiles.
Select the relevant profile (usually Default Agent Communication Profile).
In the Primary URL field, ensure the FQDN exactly matches a CN or SAN from the NS's certificate (e.g., use https://SMPServer2018.EXAMPLE.net instead of https://SMPServer2018).
Click Save changes.

Option B: Replace the Notification Server SSL Certificate

If you cannot change the name used in the Agent Communication Profile, you must replace the certificate to include the name currently in use by the agents.

Acquire a new SSL certificate from your Certificate Authority (CA) that includes all necessary names (the name the agents are trying to use) as Subject Alternative Names (SANs).
Import the new certificate into the NS's Personal certificate store.
In IIS Manager, navigate to Sites > Default Web Site > Bindings...
Edit the HTTPS binding on port $\text{443}$ and select the new certificate.
Click OK to save the changes.
Tip: Restart the World Wide Web Publishing Service (W3SVC) in the Services console (or reboot the NS) to ensure IIS applies the new certificate immediately.

⚠️ Special Guidance: Removing Duplicate Agent Communication Profiles

If you suspect this issue stems from an old or duplicate communication profile being used by clients, follow this guidance based on SMP Server has a duplicated communication profile after migrating to a new server and Duplicate Task Server communication profiles show Existing profile '' contains the same FQDN and web application path.

This procedure requires direct database interaction and should be performed with caution.

Step 1: Identify Duplicate Profiles in the Database

Browse to Settings > Agents / Plug-ins > Symantec Management Agent Communication Profiles > Symantec Management Agent Communication profiles

Identify the correct duplicate profile (be sure that this profile is not currently in use by agents/site servers)
Right-click on the communication profile and select "Properties"
Copy the GUID of the communication profile
To find these Duplicate Profiles run this SQL Query (exactly as shown):

select Name, GUID, State, *
from item
where State like '%<Name of the server or profile having issue>%'
order by 1

Once you find the GUID, set it's attribute to 0 and add it to the ItemToDelete table (deletes happen every 15 minutes on the NS.Quarter Hour Task schedule)

Update Item
set Attributes = 0
where Guid = 'GUID OF PROFILE TO DELETE'

Then:

insert into ItemToDelete
select guid, GETDATE()
from item where guid = 'GUID OF PROFILE TO DELETE'

After the NS.Quarter Hour schedule runs the item will be removed from the database.

Step 2: Verify and Apply the Fix

Return to the SMP Console and verify that only the correct profile remains under Settings > All Settings > Agents/Plug-ins > Symantec Management Agent > Settings > Symantec Management Agent Communication Profiles.
Follow the steps in Option A (Update the Agent Communication Profile) to ensure the remaining profile has the correct FQDN listed.
Ensure the agents receive a new configuration file to use the updated, single profile.

✅ Verification

Monitor the Task Server Agent Log:
- Check the agent logs (e.g., %ProgramData%\Symantec\Symantec Agent\Logs).
- The Direct: Connect operations for Task Management should now report success, and the $\text{0x800B010F}$ error should be absent.