EldoS | Feel safer!

Software components for data protection, secure storage and transfer

TLS 1.2 Support for a .Net 2.0 Web Service Client

Posted: 02/02/2016 21:17:06
by Bruce Chao (Basic support level)
Joined: 02/02/2016
Posts: 2


A remote web service stopped supporting TLS 1.0 (now only 1.1 and 1.2) anymore and we are left with the only option to upgrade the solution (from .Net 2.0) to .Net 4.5. We'd like to evaluate the product (HTTPBlackBox?) to see we can save the trouble.

I'd like to know how we can plug in the required code into our existing web service call in order to enable TLS 1.2 support? The web service is imported into the .Net solution as a service reference; web client class, properties and method are available for us to use. we tried to find sample code to follow but have no luck yet. I'd think this is a very common situation out there.

Here is a sample code that describes how we create the client and make the call. Thanks again if anyone can help answering this question!


public class MyLoginClass
public static LoginResult AuthenticateUser
(string strUserID, string strPassword)

// This line used to work - does not anymore because
// service provider now only supports TLS 1.1 and 1.2
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;

// Create a Web Service client
myGeneration.myWebServiceService myid =
new myGeneration.myWebServiceService();

// Create request and response object
myGeneration.authenticateRequest req =
new myGeneration.authenticateRequest();

myGeneration.authenticateResponse resp =
new myGeneration.authenticateResponse();

// Assign the required parameters in the request object
req.UserID = strUserID;
req.UserPassword = strPassword;

// Use the client to execute the request
resp = myid.authenticate(req);

// check the resp object and decide whether login OK or failed
Posted: 02/03/2016 02:09:50
by Ken Ivanov (Team)

Hi Bruce,

Thank you for getting in touch with us.

I am afraid SecureBlackbox components are not 'pluggable' to .NET framework service consumers due to restrictions of the framework, which does not allow to attach external transports. This means that most likely you would need to use SecureBlackbox components (primarily TElHTTPSClient and TElXMLSOAPClient) to communicate to a web service.

Posted: 02/03/2016 06:06:53
by Bruce Chao (Basic support level)
Joined: 02/02/2016
Posts: 2

Thanks Ken, so I assume we can no longer consume the imported service reference (or use any of the classes that come with it), but rather need to write custom code using XMLBlackBox's classes (the two you mentioned) to directly send/receive SOAP message to/from the remote service?

What is the best sample code we can reference? I looked and is it this?

(That sample appears to work only in http, not https - again it'd be great if there is code sample)

Thanks again!
Posted: 02/03/2016 06:13:19
by Dmytro Bogatskyy (Team)


What is the best sample code we can reference? I looked and is it this?

(That sample appears to work only in http, not https - again it'd be great if there is code sample)

For https support please add the following code into the sample:
_HTTPClient.OnCertificateValidate += new SBSSLCommon.TSBCertificateValidateEvent(HTTPClient_OnCertificateValidate);

void HTTPClient_OnCertificateValidate(object Sender, SBX509.TElX509Certificate X509Certificate, ref bool Validate)
   Validate = true;
   // NEVER do this in production code. Instead perform full certificate validation.
   // You can use TElX509CertificateValidator class for complete certificiate chain validation.
   // See other samples for example of how TElX509CertificateValidator class should be used.
Posted: 02/03/2016 13:55:18
by Ken Ivanov (Team)

Hi Bruce,

As a more general question about your TLS problem, what kind of solution would you consider the most convenient for your scenario? We actually researched the options we could employ about improving interoperability between non-TLS1.2-capable platforms and TLS1.2-capable servers and yet we haven't managed to find a simple solution. As it is totally impossible to infiltrate into any level of standard .NET components (like WebClient or your web service wrappers), we are forced to make customers affected by the problem refactor large parts of their logic to switch it to our components.

An option of a local TLS/HTTP proxy component which would accept TLS 1.0 (or, more likely, plain HTTP) connection from your code and then use TLS 1.2 to relay your request to the server looks fairly attractive so far. In other words, you set up your native .NET components to use an HTTP (CONNECT) proxy, which would actually point to the hypothetical SBB component, and then make requests to your web service as you normally do - with the exception of using http:// instead of https://. The proxy component would intercept your HTTP connection and forward the data to your web service over TLS 1.2. What do you think, could that be a good/convenient option for you? Your opinion would help us greatly.





Topic viewed 5792 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!