TRestClient and Cipher restrictions to TLSv1.2 does not work on Windows7 and Server2008R2 ... and how it can be solved.
TRestClient and Cipher restrictions to TLSv1.2 does not work on Windows7 and Server2008R2 ... and how it can be solved.
For one of our solutions we use a REST Client based on TRestClient. Internally this component is connected to System.Net.HttpClient. The client software is running on a Windows 2008R2 Server as target platform. We develop with Delphi Seattle (but the REST Client has not changed much since that version).
This worked fine until we followed the security recommendation of the Apache organization “By the end of 2016, only TLSv1.2 ciphers should remain in use”. We removed the older cipher suites from the system (exact syntax of the httpd-ssl.conf = SSLCipherSuite HIGH:MEDIUM:!SSLv3:!kRSA)
Now the TRestClient raised the error “Error getting Server Certificate“.
Accessing the REST Server from Internet-Explorer was possible from the same machine (using TLSv1.2). After some debugging we still assumed that the problem was interconnected to the TLSv1.2 support of the System.Net.HttpClient. Hint: https://blogs.msdn.microsoft.com/kaushal/2011/10/02/support-for-ssltls-protocols-on-windows/ gives a nice summary on the default status.
First thought was to switch to the Indy HttpClient. But the TRestClient.IPImplementationID logic is not really obvious. As well there is no access to Indy HttpClient for manipulating the necessary settings as all is completely hidden by TCustomRESTClient.CreateHttpClient.
By luck we found that the same Delphi software was running started from a Windows10 Client and we searched further until we found the following Microsoft patch not being part of the normal Microsoft Update strategy: https://support.microsoft.com/en-au/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in
Now everything is running again. I post that finding just in case somebody else runs into that problem!
https://support.microsoft.com/en-au/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in
For one of our solutions we use a REST Client based on TRestClient. Internally this component is connected to System.Net.HttpClient. The client software is running on a Windows 2008R2 Server as target platform. We develop with Delphi Seattle (but the REST Client has not changed much since that version).
This worked fine until we followed the security recommendation of the Apache organization “By the end of 2016, only TLSv1.2 ciphers should remain in use”. We removed the older cipher suites from the system (exact syntax of the httpd-ssl.conf = SSLCipherSuite HIGH:MEDIUM:!SSLv3:!kRSA)
Now the TRestClient raised the error “Error getting Server Certificate“.
Accessing the REST Server from Internet-Explorer was possible from the same machine (using TLSv1.2). After some debugging we still assumed that the problem was interconnected to the TLSv1.2 support of the System.Net.HttpClient. Hint: https://blogs.msdn.microsoft.com/kaushal/2011/10/02/support-for-ssltls-protocols-on-windows/ gives a nice summary on the default status.
First thought was to switch to the Indy HttpClient. But the TRestClient.IPImplementationID logic is not really obvious. As well there is no access to Indy HttpClient for manipulating the necessary settings as all is completely hidden by TCustomRESTClient.CreateHttpClient.
By luck we found that the same Delphi software was running started from a Windows10 Client and we searched further until we found the following Microsoft patch not being part of the normal Microsoft Update strategy: https://support.microsoft.com/en-au/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in
Now everything is running again. I post that finding just in case somebody else runs into that problem!
https://support.microsoft.com/en-au/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in
Great that it helped. Was really a nasty problem and not easy to trace down.
ReplyDelete