How to Fix "Could Not Create SSL/TLS Secure Channel"

If you’ve ever seen this frustrating .NET error

“System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.”

-you’re not alone.
This is one of the most common HTTPS errors developers face, and it almost always means your application failed to complete the SSL/TLS handshake with the server.

In this guide, you'll learn exactly why this error happens, how to fix it step-by-step, and how to prevent it in the future.

What This Error Means & Why It Occurs

SSL/TLS handshake basics

When a .NET client makes an HTTPS request, it begins a TLS handshake with the server.
This handshake negotiates:

• Protocol version (TLS 1.0 / 1.1 / 1.2 / 1.3)
• Cipher suite (AES, SHA256, ECDHE, etc.)
• Server certificate validation
• Secure key exchange

If any part of the handshake fails, .NET throws:

“Could not create SSL/TLS secure channel.”

Client vs server mismatch in protocol or cipher

Most commonly, the client and server cannot agree on:

• Supported TLS version
• Accepted cipher suites

For example:
Server requires TLS 1.2, but your .NET app defaults to TLS 1.0 → handshake fails.

Certificate trust/validation failures

Even if the server has a certificate, the connection fails if:

• The certificate is expired
• The certificate is self-signed
• Intermediate CA certificates are missing
• The certificate chain is not trusted by the client

Common Causes & Scenarios

Unsupported TLS versions or disabled protocols

Older .NET Framework versions default to TLS 1.0/1.1, which many servers no longer accept.

Certificate not trusted, expired, or missing intermediate chain

Even a valid certificate can fail if the intermediate CA is missing, which is extremely common.

Cipher suite incompatibility

If client and server do not share any common cipher, the handshake is aborted.

Firewall, proxy, or DNS blocking the handshake

Corporate networks often break TLS using:

• SSL inspection
• Transparent proxies
• MITM appliances
• Incorrect DNS → pointing to a server with wrong certificate

Permissions issues on certificate private key

If your app uses a client certificate, the executing user/service must have read permissions on the private key. Without it, TLS authentication fails silently.

How to Fix the Error?

Below are the different ways of troubleshooting and fixing the error.

Scenario 1: The server does not support the SSL/TLS protocol version that your application is using

This scenario can happen when the server is configured to use a higher or a lower protocol version than your application. For instance, the server may only support TLS 1.2 or higher while your application uses TLS 1.0 or lower. To diagnose this scenario, you can use Fiddler to see the protocol version your application and the server are using. 

To fix this scenario, you can either change the protocol version of your application or the web server so that they match or are compatible. To change the protocol version of your application, you can use the ServicePointManager.SecurityProtocol property. For example, to use TLS 1.2, you can add the following line of code before making the HTTPS request:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls1.2;

To change the protocol version of the server, you need to contact the server administrator or refer to the server documentation.

Scenario 2: The server certificate is not trusted by your application or the system

This scenario can happen when the server certificate is self-signed, expired, revoked, or issued by an untrusted authority. For example, the server may use a certificate that is generated by itself or by a private certificate authority that is not recognized by your application or the system.

To troubleshoot this scenario, you can use Fiddler or Wireshark to see the server certificate and its trust chain. In Fiddler, you can see the server certificate by clicking on the padlock icon in the Sessions list and then clicking on the Certificates tab. In Wireshark, you can see the server certificate by expanding the ssl.handshake.certificate field of the ServerHello packet.

To fix this scenario, you can either trust the server certificate or bypass the certificate validation. To trust the server certificate, add it to the list of trusted root certificates of your application or the system. In Windows, you can use the Certificate Manager tool (certmgr.msc) to import the certificate to the Trusted Root Certification Authorities store. Alternatively, you can use the X509Store class in .NET to programmatically add the certificate to the store. Below is a code sample that adds the certificate from a file.

Using System.Security.Cryptography.X509Certificates;

// Load the certificate from a file
X509Certificate2 cert = new X509Certificate2("server.crt");

// Open the trusted root store
X509Store store = new X509Store(StoreName.Root, StoreLocation.LocalMachine);
store.Open(OpenFlags.ReadWrite);

// Add the certificate to the store
store.Add(cert);

// Close the store
store.Close();

To bypass the certificate validation, you can use the ServicePointManager.ServerCertificateValidationCallback property to specify a custom delegate that always returns true. Below is a code sample that ignores any SSL policy errors

using System.Net;
using System.Net.Security;
using System.Security.Cryptography.X509Certificates;

// Define a custom delegate that always returns true
bool ValidateServerCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
    return true;
}

// Assign the delegate to the callback property
ServicePointManager.ServerCertificateValidationCallback = ValidateServerCertificate;

However, bypassing the certificate validation is not recommended, as it can expose your application to security risks like a man-in-the-middle attack. You should only use this option for testing purposes or when you trust the server completely.

Check our course on Docker Certified Associate Exam Series (Part-6): Docker Engine Security, to learn how to secure your Docker hosts using TLS certificates.

Scenario 3: The cipher suites supported by the server and your application do not match

This scenario can happen when the server and your application have different preferences or requirements for the cipher suites that they use in the SSL/TLS session. For example, the server may only support strong cipher suites that use AES encryption and SHA-256 hashing, while your application may only support weak cipher suites that use RC4 encryption and MD5 hashing. Or the server may require a cipher suite that uses elliptic curve cryptography (ECC), while your application does not support ECC.

Use Fiddler or Wireshark to see the cipher suites that your application and the server are offering and selecting. For example, in Fiddler, you can see the cipher suites in the Ciphers column of the Sessions list. In Wireshark, you can see the cipher suites in the ssl.handshake.ciphersuites field of the ClientHello and ServerHello packets.

To fix this scenario, you can either change the cipher suites of your application or the server so that they have at least one common cipher suite. To change the cipher suites of your application, use the ServicePointManager.CipherSuites property. For example, to use only the cipher suites that use AES encryption and SHA-256 hashing, integrate the following code:

using System.Net;
using System.Net.Security;

// Define a list of cipher suites that use AES and SHA-256
TlsCipherSuite[] cipherSuites = new TlsCipherSuite[]
{
    TlsCipherSuite.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
    TlsCipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
    TlsCipherSuite.TLS_RSA_WITH_AES_256_GCM_SHA384,
    TlsCipherSuite.TLS_RSA_WITH_AES_128_GCM_SHA256
};

// Assign the list to the property
ServicePointManager.CipherSuites = cipherSuites;

To change the server's cipher suites, you may need to contact the server administrator. 

How to test your HTTPS connection and verify that it is secure?

After you have fixed the error and established a successful SSL/TLS connection with the server, you may want to test your connection and verify that it is secure. Below are some of the ways to do that:

• Use Fiddler or Wireshark to inspect the encrypted data that is exchanged between your application and the server. You can see the data in the Text View or Hex View tabs of Fiddler, or in the ssl.app_data field of Wireshark. You can also see the encryption algorithm and the key length that are used in the session in the Ciphers column of Fiddler, or in the ssl.cipher field of Wireshark.
• Use online tools such as SSL Labs or Qualys SSL Server Test to scan the server and check its SSL/TLS configuration and security. These tools can give you a detailed report on the server certificate, the protocol version, the cipher suites, and the vulnerabilities that the server may have. They can also give you a rating on the server’s SSL/TLS security, from A+ to F.
• Use the SslStream class to get information about the SSL/TLS session, such as the protocol version, the cipher suite, the key exchange algorithm, and the hash algorithm. You can access these properties from the SslStream object that is returned by the WebRequest.GetRequestStream or the HttpClientHandler.SslProtocols methods. Below is a sample code that gets the protocol version and the cipher suit.

using System.Net;
using System.Net.Security;

// Create a web request to the server
WebRequest request = WebRequest.Create("https://example.com");

// Get the request stream
SslStream stream = (SslStream)request.GetRequestStream();

// Get the protocol version and the cipher suite
string protocol = stream.SslProtocol.ToString();
string cipher = stream.CipherAlgorithm.ToString();

// Print the information
Console.WriteLine("Protocol: {0}", protocol);
Console.WriteLine("Cipher: {0}", cipher);

Interested in learning more about Kubernetes security? Check out the following articles and courses from KodeKloud:

• 10 Kubernetes Security Best Practices to Secure K8 Clusters
• DevSecOps – Kubernetes DevOps & Security
• Certified Kubernetes Security (CKS): 

Also, you can understand more about DevSecOps here:

Conclusion

In this article, we have seen how to diagnose and fix the “Could not create SSL/TLS secure channel” error. I have also shown you how to test your HTTPS connection and verify that it is secure. I hope you have found this article helpful and interesting.

 If you have any questions or feedback, please feel free to leave a comment below. 

If you're keen on learning more about DevOps, simply sign up for a free account on KodeKloud. As a member, you'll gain access to over 70 courses, labs, quizzes, and projects designed to enhance your proficiency in various DevOps skills.

FAQs