SecureChannelFailure

Patch My Pc | install & update thousands of apps

Have you ever struggled with Lenovo T480 or HP Elitedesk 800 G4 devices that refused to cooperate with Intune? In this blog, we unravel the saga of SecureChannelFailure errors, elusive SSL/TLS handshake issues, and a troublesome TPM. Armed with Fiddler and Wireshark, we uncovered a cryptographic glitch causing the chaos. The result? Apps wouldn’t install, and no PowerShell scripts could be deployed during Windows Autopilot.

Want to learn how we solved the problem and got those T480s back on track? Dive in to find out!

I will divide this blog into multiple parts

Introduction

A few weeks ago, someone approached me with an issue affecting his Lenovo T480 devices. The problem? None of his Apps or PowerShell scripts were deployed to new or existing devices! Using Windows Autopilot to enroll new devices always ended up with the Apps (Failed) message.

autopilot enrollment fails. The ESP is showing that the Apps (Failed) after it was stuck on identifying for a while

It was a complete deployment freeze, leaving him unable to push crucial Apps and PowerShell scripts across his fleet. It was obvious that the device wasn’t having any issues enrolling into Entra and Intune; it even received all of the configured policies! However, it all broke down the moment the Intune Management Extension was installed, and the Win32app Workload needed to kick in.

Somehow, the moment the IME needed to start handling the Win32App workload, many SecureChannelFailure errors appeared when trying to download apps via Intune.

The errors pertain to a network request failure with the following key details: Error type: Web exception status = SecureChannelFailure
Message: "System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel."
The error occurs in a non-retriable web exception context when sending network requests.

When looking at the IME code itself, it will indeed throw an error when there is an issue communicating with the service. If an error occurs, it will throw the error: Could not establish trust relationship for the SSL/TLS secure Channel.

This image displays a piece of C# code from a method called IsWebExceptionRetryable. The method determines whether a WebException is retryable by evaluating its status and message. Here’s a breakdown of the code: Log.TraceInformation: Logs the web exception status to provide information about the type of failure.
The method first checks if the exception's status is NameResolutionFailure or ConnectFailure. If so, it returns true, indicating that the exception is retryable.
It then checks if the message contains the phrase "Could not establish trust relationship for the SSL/TLS secure channel". If it does, the method returns false, indicating the error is not retryable.
It also checks for messages related to "Unable to connect to the remote server" or "The underlying connection was closed" and returns true if these conditions are met, marking the exception as retryable.
If the exception is a protocol error or the response is not an HttpWebResponse, it returns false.
Lastly, it checks the status code from the response, logs a warning if the status code is 502, and returns false for that status code.

These SSL/TLS errors indicated the device could not create a secure SSL/TLS connection with Microsoft services. When looking closely at the flow in the screenshot above, we will spot multiple SSL/TLS secure channel failures during the web request. The logs indicate a non-retriable web exception with the error:
System.Net.WebException: Could not create SSL/TLS secure channel. The client couldn’t establish a secure connection to the Intune service at agents.amsua0602.manage.microsoft.com.

The SecureChannelFailure occurs multiple times, preventing the device from making successful web requests to the Microsoft service. The funny thing is that opening Microsoft Edge and copy-pasting that URL in the address bar just worked.

Narrowing down the root cause

Curiously, his other devices, such as Lenovo T14, T460, and Cloud PCs, weren’t affected, making this a device-specific issue.

I initially suspected that the problem might be related to the network configuration. So, I asked about potential proxy settings, firewall rules, and any policies applied that could affect how these devices communicate with Intune servers. If the issue were network-related, it would likely affect all devices behind the same configuration. However, since the Cloud PCs and other physical devices had no problems, I knew the issue had to be tied to the Lenovo T480 hardware.

It’s obvious that I don’t need to tell you that we made sure the Firmware/Drivers, especially the Network card, were 100% up to date. I also reviewed a great guide that provides some general troubleshooting steps related to SSL/TLS secure channel errors. Unfortunately, nothing seemed out of the ordinary in terms of the configurations I reviewed, but I knew this issue went deeper.

Determined to dig deeper, I decided to capture more specific data using Fiddler.

Fiddler: SSPI and Schannel Error

Using Fiddler, I captured an authentication failure with the error:
System.Security.Authentication.AuthenticationException: A call to SSPI failed.

This image shows a network trace with SSL/TLS details using Fiddler. It captures an HTTPS handshake to agents.amsua0602.manage.microsoft.com, which resulted in a failure. Here's a summary of the key details: Error message:
"HTTPS handshake to agents.amsua0602.manage.microsoft.com failed."
System.Security.Authentication.AuthenticationException: "A call to SSPI failed."
Error detail: "The Local Security Authority cannot be contacted."
Win32 (Schannel) Native Error Code: 0x80090304
This suggests an issue with the Secure Channel (Schannel) during the handshake, possibly related to missing or invalid credentials, problems with the Local Security Authority Subsystem (LSASS), or the inability to verify certificates properly. The TLS version and cipher suites used are also visible in the details, which include multiple signature algorithms like rsa_pss_rsae_sha512 and ecdsa_sha384. These could indicate issues with the supported cryptographic protocols or an incompatibility in the handshake process.

The error code 0x80090304 points to an issue with SSPI (Security Support Provider Interface), which is a Windows API responsible for managing secure communication channels. Specifically, it means the device couldn’t contact the Local Security Authority (LSA) to handle the authentication for the SSL/TLS handshake. This confirmed that something was breaking down during the secure channel setup.

At this point, I was convinced it was more than just a network misconfiguration, so I moved on to Wireshark to examine the handshake itself.

But to do so, I needed to have my hands on such a device, so the OP was so kind to send over a test device while I was spending some days at Workplace Ninjas Switzerland.

Diving Into Wireshark: The Missing Certificate Verify Step

Once I had the device in hand, I decided to capture the network traffic using Wireshark. This allowed me to analyze the SSL/TLS handshake, which is critical for establishing a secure communication channel. Right away, I noticed that something was wrong. Was the Certificate Verify step, a key part of the handshake, missing? Let me explain, why I thought that was weird.

In a successful handshake, the Certificate Verify step allows the client to prove it possesses the correct private key by signing part of the handshake. Without this step, the server can’t verify the client’s identity, and the handshake will fail. This explained the SecureChannelFailure error.

Here’s a quick breakdown of what a successful SSL/TLS handshake looks like, step by step:

Client Hello: The client sends a message to the server listing the ciphers and SSL/TLS versions it supports.
Server Hello: The server responds by selecting a cipher suite and sending its certificate to the client.
Certificate: The server’s certificate is sent to the client for validation.
Certificate Verify: (This was missing!) The client proves ownership of the private key by signing the handshake.
Key Exchange: Both the client and server exchange keys to begin encryption.
Finished Messages: Both parties confirm that the handshake has been successfully completed.

This diagram captures the essential steps of the SSL/TLS handshake, focusing on how encryption and trust are established between the client and server before secure communication can begin.

The missing Certificate Verify step was a clear indication that something was wrong during the client-side cryptographic operation—but what?

Identifying RSA-PSS as the Culprit

Upon further investigation, I found that the SSL/TLS handshake was attempting to use the RSA-PSS signature algorithm, which is more secure than the older RSA-PKCS1 method. This led me to suspect the issue lay with the Infineon TPM 2.0 on the Lenovo T480.

wireshark showing that it it want to use the rsa_PSS_RSAE_SHA256 algorithm

By checking the HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003 registry key, I confirmed that RSA-PSS was being used for the signature/hash combinations in TLS 1.2 handshakes.

HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003 showing the hash alghoritms

These settings control which algorithms can be used for signing ServerKeyExchange and Certificate Verify messages. While these settings are essential for enabling modern cryptographic standards, in this case, RSA-PSS was causing the failure due to TPM compatibility issues.

The Fix: Disabling RSA-PSS

To resolve the issue, I disabled the use of RSA-PSS by removing it from the registry’s supported ciphers.

Here’s a PowerShell script that automates the process:

$RegPath = 'HKLM:SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003\'

[string[]]$Functions = Get-ItemPropertyValue $RegPath -Name Functions -ErrorAction SilentlyContinue

Try {

If ($Functions) {

Write-Verbose 'Removing RSAE-PSS ciphers...'

ForEach ($Function in $Functions) {

If ($Function -NotMatch 'RSAE') {

[string[]]$NewFunctions += $Function

}

}

Write-Verbose 'Updating registry...'

Set-ItemProperty $RegPath -Name Functions -Value $NewFunctions -Force

}

Else {

Write-Warning "Unable to read $RegPath."

}

}

Catch {

$ErrorMessage = $_.Exception.Message

Write-Warning $ErrorMessage

Exit 1

}

This script removes the RSAE-PSS ciphers and forces the system to use RSA-PKCS1 instead. With this change, the TLS handshake was now able to proceed to the certificate verification.

After disabling the rsa-pss ciphers the device is now able to communicate with the service and it now uses the rsa_pcks alghoritm

After running the script and rebooting the device, the SecureChannelFailure error disappeared, and the device was successfully connected to Intune.

Conclusion: A Temporary Fix, but More Changes Ahead

Disabling RSA-PSS has now resolved the issue for these Lenovo T480 devices. However, this is only a temporary fix. As Microsoft and other service providers continue to adopt modern cryptographic standards, older TPM firmware will likely cause more problems.

The long-term solution will require firmware updates from manufacturers like Lenovo and Infineon to support RSA-PSS fully (not going to happen). If you encounter similar issues, start by inspecting the SSL/TLS handshake using Wireshark and check if the Certificate Verify step is missing. If it is, disabling RSA-PSS may offer a temporary workaround until a Microsoft comes up with an official statement.

SecureChannelFailure Errors, and the Curious Case of the Lenovo T480

Introduction