Articles in this section

Fixing SCUP TLS Handshake Error: 'Could not create SSL/TLS secure channel'

This article provides a solution for the "Could not create SSL/TLS secure channel" error encountered when importing catalogs into System Center Updates Publisher (SCUP). The issue stems from SCUP's reliance on older .NET Framework TLS defaults, which are incompatible with modern secure catalog servers. The resolution involves configuring the .NET Framework to use TLS 1.2 or higher.

Problem Description

When attempting to import the JetPatch third-party catalog (CAB) into System Center Updates Publisher (SCUP) on a Windows server, the process fails.

Symptoms:

  • SCUP import wizard logs or UI display:
The request was aborted: Could not create SSL/TLS secure channel.

UpdatesPublisher Log: (located at %LocalAppData%\Microsoft\UpdatesPublisher\Logs) contains entries similar to:

Download file: 'http://catalog.jetpatch.com/JetPatch-Catalog.cab' failed.
Exception Message: The request was aborted: Could not create SSL/TLS secure channel.

This issue occurs even if:

  • The catalog URL (catalog.jetpatch.com) is accessible from a web browser on the affected server.
  • A direct Invoke-WebRequest in PowerShell successfully retrieves content from the catalog URL.

The root cause of this issue lies in the default TLS negotiation behavior of the .NET Framework.

To confirm if your server is impacted, perform these PowerShell checks:

1. Check Registry Settings for .NET Strong Cryptography

Run these commands in a PowerShell prompt:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name SchUseStrongCrypto -ErrorAction SilentlyContinue
Get-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name SchUseStrongCrypto -ErrorAction SilentlyContinue

Expected Output (for both commands):

SchUseStrongCrypto : 1

If the output is anything other than 1 (or if the SchUseStrongCrypto property is missing), this indicates a misconfiguration. 

2. Verify .NET SecurityProtocol Includes TLS 1.2

Run this command in a PowerShell prompt:

[Net.ServicePointManager]::SecurityProtocol

Expected Output:

Tls, Tls11, Tls12

If Tls12 is not present in the output, the .NET Framework is not configured to explicitly use TLS 1.2. 

3. Perform a Low-Level TLS Handshake Test

Run these commands in a PowerShell prompt:

$tcp = New-Object Net.Sockets.TcpClient('catalog.jetpatch.com', 443)
$ssl = New-Object Net.Security.SslStream($tcp.GetStream(), $false, ({$True}))
$ssl.AuthenticateAsClient('catalog.jetpatch.com')
$ssl.RemoteCertificate | Format-List *
$ssl.Close()
$tcp.Close()

If the AuthenticateAsClient command is not successful (e.g., it throws an error indicating a handshake failure), it confirms a problem with the server's ability to negotiate TLS 1.2+ connections for .NET applications.

 

To resolve this issue, you must configure the .NET Framework on your Windows server to prioritize and use strong cryptography (TLS 1.2 or higher) by default.

Step 1: Enable Strong Cryptography (TLS 1.2+) for all .NET Framework Applications

Execute the following commands in an elevated PowerShell prompt (Run as Administrator):

# For 64-bit .NET Framework applications
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" `
    -Name "SchUseStrongCrypto" -PropertyType DWORD -Value 1 -Force

# For 32-bit .NET Framework applications on 64-bit Windows
New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" `
    -Name "SchUseStrongCrypto" -PropertyType DWORD -Value 1 -Force

These commands create or update registry entries that instruct .NET Framework 4.x applications to prioritize and use TLS 1.2 or higher for all secure communications.

Step 2: Restart PowerShell

⚠ Important: After applying the registry changes, you must close and re-open PowerShell (or start a new console). This action ensures that the new PowerShell process loads the updated registry settings.

Step 3: Verify the Changes Manually

Re-run the manual verification checks (steps 1, 2, and 3 from the "How to Verify the Issue" section above) to confirm that:

  • The SchUseStrongCrypto registry keys are now properly set to 1.
  • The [Net.ServicePointManager]::SecurityProtocol output explicitly includes Tls12.
  • The low-level TLS handshake test completes successfully without errors.

Step 4: Restart SCUP (or the Entire Server)

To ensure that SCUP and all related processes pick up the updated .NET cryptography settings, perform one of the following:

  • Fully close SCUP (including any background processes like JetPatchSCUPTool.exe in Task Manager) and then re-open SCUP to ensure it picks up the updated .NET crypto settings.
  • Alternatively, restart the entire Windows server to guarantee that all system processes are using the new default TLS configurations.

Step 5: Re-attempt Catalog Import

After completing the above steps, return to SCUP and re-run the catalog import wizard. The import process should now complete successfully without encountering TLS errors.

Related Articles

 

 

 

 

Related articles

Comments

0 comments

Article is closed for comments.