Deployment fails after selection of "Initial Deployment" job. Getting "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."

book

Article ID: 198870

calendar_today

Updated On:

Products

Deployment Solution

Issue/Introduction

The customer is trying to run their "Initial Deployment" job to a set of new machines. However, it is not succeeding.

The NS logs shows:

<event date="08/18/2020 12:50:44.1952428 -04:00" severity="2" source="Altiris.Deployment.Web.Services.GetResourceGuid.ProcessRequest" module="Symantec.Deployment.Web.Services.dll" process="w3wp" pid="6508" thread="592" tickCount="1315589968">

<![CDATA[Invalid computer resource Guid.
Error Message:The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

Stack Trace:   at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
   at System.Net.HttpWebRequest.GetRequestStream()
   at Altiris.Deployment.Web.Services.GetResourceGuid.CreateResource(Guid resourceGuid, String resName, String token)
   at Altiris.Deployment.Web.Services.GetResourceGuid.getResponseXML(List`1 predefinedComputerListParam, Boolean callCreateResourceDirect, Guid existingGuid)
   at Altiris.Deployment.Web.Services.GetResourceGuid.GetResorceGuid(List`1 keyNames, List`1 keyValues, String identifierList, Boolean unknownClientNode)
   at Altiris.Deployment.Web.Services.GetResourceGuid.ProcessRequest(String& request, Byte[]& clientConfigData, String& clientConfigXml, Boolean& compress)]]>
</event>

Consider the following sequence of steps, which the customer has attempted multiple times with identical results (and the same GUID for the Computer object every time):

  1. Access Manage -> Computers from the ITMS Console
  2. Search for "PECTAgent" in the list of computers
  3. Click to view the Task/Job History for the selected computer; see attached image which shows that history
  4. Delete the Computer object from ITMS (and confirm if prompted)
  5. Repeat step 2 to verify that the system is gone
  6. PXE boot the client system and wait for WinPE to start
  7. Select a Job from the Initial Deployment list
  8. Observe that the deployment never starts and that the job is never logged
  9. Turn off the computer
  10. Repeat step 2 to locate PECTAgent -- it is back now
  11. Click to view the Task/Job History for the object, and see that the new attempt is still not logged

It was also noticed that the agent communication profile is showing an issue with the "root certificate which is not trusted by the trust provider" on port 443, but it does fall back to port 80 successfully.

Cause

The SMP Server tries to redirect resource creation call to NS web. Since the initial call to DS web service was performed over HTTPs, call to NS is also a HTTPs call. That one fails with error "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel". 

The problem was related to the server name used in call and in NS web certificate, which caused "Certificate name mismatch". 

Environment

DS 8.5 RU3

Resolution

In order to narrow down if there is an issue with the certificate in use, please refer to the following:

1. Try the script from this Stack Overflow post for enabling .NET network tracing and substitute the relevant WebRequest call:

$id = [Environment]::TickCount;
$fileName = "${PSScriptRoot}\Powershell_log_${id}.txt"
$listener1 = New-Object "System.Diagnostics.TextWriterTraceListener" @($fileName, "text_listener")
$listener2 = New-Object "System.Diagnostics.ConsoleTraceListener"
$listener2.Name = "console_listener"
[System.Diagnostics.Trace]::AutoFlush = $true
[System.Diagnostics.Trace]::Listeners.Add($listener1) | out-null
[System.Diagnostics.Trace]::Listeners.Add($listener2) | out-null
# Use reflection to enable and hook up the TraceSource
$logging = [System.Net.Sockets.Socket].Assembly.GetType("System.Net.Logging")
$flags = [System.Reflection.BindingFlags]::NonPublic -bor [System.Reflection.BindingFlags]::Static
$logging.GetField("s_LoggingEnabled", $flags).SetValue($null, $true)
$webTracing = $logging.GetProperty("Web", $flags);
$webTraceSource = [System.Diagnostics.Tracesource]$webTracing.GetValue($null, $null);
$webTraceSource.Switch.Level = [System.Diagnostics.SourceLevels]::Information
$webTracesource.Listeners.Add($listener1) | out-null
$webTracesource.Listeners.Add($listener2) | out-null
[System.Diagnostics.Trace]::TraceInformation("About to do net stuff");
$wr = [System.Net.WebRequest]::Create("https://ns.ad.example.com:443/Altiris/NS/Agent/CreateResource.aspx")
$response = $wr.GetResponse()
[System.Diagnostics.Trace]::TraceInformation("Finished doing net stuff");
#get rid of the listeners
[System.Diagnostics.Trace]::Listeners.Clear();
$webTraceSource.Listeners.Clear();
$listener1.Dispose();
$listener2.Dispose();


2. The resulting logfile should identify the exact problem:

System.Net Information: 0 : [12808] SecureChannel#20268497 - Remote certificate has errors:
System.Net Information: 0 : [12808] SecureChannel#20268497 - Certificate name mismatch.
System.Net Information: 0 : [12808] SecureChannel#20268497 - Remote certificate was verified as invalid by the user.
System.Net Error: 0 : [12808] Exception in HttpWebRequest#47759218:: - The underlying connection was closed: Could not
establish trust relationship for the SSL/TLS secure channel..


The customer issued a Notification Server web certificate in September 2019 with a Common Name itms.example.com and two Subject Alternative Names: itms.example.com and ns.example.com.
Then, the customer issued and installed a new certificate with three SANs: itms.example.comns.example.com (like before), plus ns.ad.example.com (which is named in the URL). With this information, the customer added all thee SANs names to his agent communication profile.

Attachments