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.

The Lenovo T480 Miraculously Revived

In a surprising twist, after leaving the Lenovo T480 enrolled and untouched for some time, the device suddenly sprang back to life! The previously stubborn SecureChannelFailure errors that had blocked app installs and script executions mysteriously resolved on their own. Naturally, I couldn’t resist checking the network traffic with Wireshark. To my surprise, the elusive Certificate Verify step had returned, and this time, it was using rsa_pkcs1_sha256 instead of the troublesome RSA-PSS.

the elusive Certificate Verify step had returned, and this time, it was using rsa_pkcs1_sha256 instead of the troublesome RSA-PSS.

This discovery strongly suggested that Microsoft had pushed a service-side fix?. The handshake, which had failed before, now succeeded by switching to an algorithm more compatible with the device’s TPM. This explained why the Lenovo T480 suddenly started working again. Without any need for re-enrollment, the device resumed secure communication with Intune, and all the deployment failures vanished.

The most interesting part? No intervention was required on our end, no re-enrollment or manual updates. This unexpected resolution points to a fix applied centrally by Microsoft, potentially addressing compatibility issues with RSA-PSS in combination with the Infineon TPM.

This outcome serves as a reminder that while client-side troubleshooting is crucial, sometimes the root cause lies in server-side updates or cryptographic compatibility issues that only become clear after monitoring the network traffic. In this case, Wireshark once again proved invaluable, helping us pinpoint the exact moment things turned around.

So, if you’re ever faced with cryptic errors like SecureChannelFailure, don’t forget to check Wireshark to see what’s really happening during the handshake, it might reveal changes you didn’t even know were coming!

Conclusion: A Surprising Resolution and a Temporary Fix

The issue with the Lenovo T480 devices has been resolved thanks to a combination of Microsoft’s service-side fix and our temporary workaround of disabling RSA-PSS. While disabling RSA-PSS worked for now, this solution may only be temporary. As cryptographic standards evolve, relying on outdated TPM firmware may lead to further issues.

The long-term solution? Likely firmware updates from manufacturers—though this might be slow. If you encounter similar problems, inspect the SSL/TLS handshake using Wireshark. If the Certificate Verify step is missing, disabling RSA-PSS might buy you time until a more permanent solution is available.

SecureChannelFailure Errors, and the Curious Case of the Failing IME

Introduction