Search the Community

Have you ever encountered this frustrating error message when trying to make an HTTPS request from your .NET application? “System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.” If so, you are not alone. This error is quite common; it means that your client application cannot establish a secure connection with the server. In this article, I will show you how to diagnose and fix this error. What Does the Error Mean?The "Could not create SSL/TLS secure channel" error occurs when your application fails to establish a secure connection with the web server using the SSL/TLS protocol. SSL/TLS stands for Secure Sockets Layer/Transport Layer Security, a standard protocol for encrypting and authenticating data over the internet. When your application makes a web request, it initiates a "handshake" process with the webserver to negotiate the encryption and authentication parameters. This process involves exchanging certificates, keys, and cipher suites to ensure that both parties can communicate securely. If this process fails for any reason, the error is thrown. Check our article on Certified Kubernetes Administrator Exam Series (Part-6): Security, to get a better understanding of Kubernetes security. Why Does the Error Happen?There are many possible reasons why the error can happen, but they can be broadly categorized into client-side and server-side issues. Client-side issues: These are problems related to the configuration and settings of your application, such as the SSL/TLS protocol version, the security policy, the certificate validation, and the proxy settings. These issues can be fixed by changing the code or the configuration of your application. Server-side issues: These are problems related to the configuration and settings of the web server, such as the SSL/TLS protocol version, the certificate chain, the cipher suites, and the firewall rules. These issues can be fixed by changing the configuration or the code of the web server or by contacting the web service provider. Some of the common causes of the error are: The web server does not support the SSL/TLS protocol version that your application is using. The web server does not have a valid certificate, or the certificate is not trusted by your application. The web server does not support the cipher suites that your application is using.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 usingThis 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 systemThis 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 matchThis 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 ClustersDevSecOps – Kubernetes DevOps & SecurityCertified Kubernetes Security (CKS): ConclusionIn 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. View the full article

Don’t be surprised if you have seen the Certificate Update in the Amazon Relational Database Service (Amazon RDS) console. If you use or plan to use Secure Sockets Layer (SSL) or Transport Layer Security (TLS) with certificate verification to connect to your database instances of Amazon RDS for MySQL, MariaDB, SQL Server, Oracle, PostgreSQL, and Amazon Aurora, it means you should rotate new certificate authority (CA) certificates in both your DB instances and application before the root certificate expires. Most SSL/TLS certificates (rds-ca-2019) for your DB instances will expire in 2024 after the certificate update in 2020. In December 2022, we released new CA certificates that are valid for 40 years (rds-ca-rsa2048-g1) and 100 years (rds-ca-rsa4096-g1 and rds-ca-ecc384-g1). So, if you rotate your CA certificates, you don’t need to do It again for a long time... View the full article