Several client toolkits, including the Microsoft .NET framework, enforce strict checking when validating server certificates during SSL based connections. This article describes how to configure the client environment in Microsoft .NET to allow communication with servers using un-trusted or self-signed server certificates.




Diagnosing the problem

Resolving the problem


Related Links


Introduction top


By default, F5 Networks controllers embed the hostname of the machine as the name in the server security certificate. This must match the hostname in the URL used to connect to the server. This means that if the server certificate was created with a hostname of, then the URL for the soap request must be http[s]://  But, not all F5 controllers have domain names associated with them and can only be referenced externally by their ip address.  This causes a conflict with the embedded name in the certificate and the address in the URL.  There are also problems due to the fact that the F5 Networks controllers self sign their own certificates. This means that your browser will issue a warning that the certificate was issued by a company you have not chosen to trust.


The .NET Framework uses strict security certificate validation for an application.  The default policy is to allow valid certificates, as well as valid certificates that have expired.  Self-signed certificates are considered not valid and will consequently be blocked by the default security policy.


One solution is to manually add the certificate to the local trust store on the client machine with Internet Explorer's user interface or programmatically with the Microsoft crypt APIs.  But this can be troublesome to manage and difficult to implement when the application is run in an ASP.NET based solution.  Manually configuring the client environment may not be optimal for distributed applications. For configurations within a trusted environment such as a protected network, it may be desirable to override the safety features of the .NET framework. 


Diagnosing the problem top

When attempting a communication over SSL, a System.Net.WebException is likely to be thrown due to the default security policy.

Exception: System.Net.WebException: The underlying connection was closed: 
Could not establish trust relationship with remote server.
    at System.Net.HttpWebRequest.CheckFinalStatus()
    at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult)
    at System.Net.HttpWebRequest.GetRequestStream()
    at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)


Resolving the problem top

The .NET Framework uses the System.NET.ICertificatePolicy interface to provide custom security certificate validation for an application.  This can be overridden to achieve the desired results.  The first step is to create a custom System.Net.ICertificatePolicy class as illustrated by the following code sample.

// trustedCertificatePolicy.cs
using System;
using System.Net;
using System.Security;
using System.Security.Cryptography.X509Certificates;
namespace myApp
  public class trustedCertificatePolicy : System.Net.ICertificatePolicy 
    public trustedCertificatePolicy() {}
    public bool CheckValidationResult
      System.Net.ServicePoint sp,
      System.Security.Cryptography.X509Certificates.X509Certificate certificate,
      System.Net.WebRequest request, int problem)
      return true;




Next, in the main routine of the application, the default Certificate Policy needs to be overridden with the new trustedCertificatePolicy class.

class myApp
  static void Main(string[] args)
    System.Net.ServicePointManager.CertificatePolicy = new trustedCertificatePolicy();




Now, all SSL based communications in this application will follow the new security policy of allowing all server certificates.


Summary top

The act of allowing all server certificates introduces a security risk and it is recommended that the developer understand these risks.  But the risks can be mitigated by controlling the environment for which the application runs.  In a trusted environment (known clients to known servers) this approach is viable and reduces the amount of manual intervention needed due to application and network changes.


Related Links top

iControl Developer
ICertificatePolicy Interface (MSDN)