Could not establish trust relationship for the ssl tls secure channel ошибка

First published on TECHNET on Jun 13, 2013

This post is a contribution from Amy Luu, an engineer with the SharePoint Developer Support team.

You can get the following error when SharePoint communicates to an external service via HTTPS either within the same server or a different server.

Typically, the scenario will be that a custom component that resides in SharePoint 2010/2013 calls WCF service over HTTPS on the same or different server.  The reason for this is that SharePoint implements its own certificate validation policy to override .NET certificate validation.

Fix is to setup a trust between SharePoint and the server requiring certificate validation.

In SharePoint Central Administration site, go to “Security” and then “Manage Trust”.  Upload the certificates to SharePoint.  The key is to get both the root and subordinate certificates on to SharePoint.

The steps to get the certificates from the remote server hosting the WCF service are as follows:

1.  Browse from IE to the WCF service (e.g., https://remotehost/service.svc?wsdl)

2.  Right click on the browser body and choose “Properties” and then “Certificates” and then “Certificate Path”.

This tells you the certificate chain that’s required by the other server in order to communicate with it properly.  You can double-click on each level in the certificate chain to go to that particular certificate, then click on “Details” tab, “Copy to File” to save the certificate with the default settings.

As an example, get both VeriSign & VeriSign Class 3 Extended Validation SSL CA.

Hope this helps!

The Windows OS has come a long way since Windows NT. The OS has managed to improve and integrate so many unique features into the Windows ecosystem, but there are still a few issues that are yet to be fixed. Some of these issues, like SSL/TLS errors, appear irresoluble, especially on Windows 10 and 11. Tech and Windows buffs may be able to use CMD (Command Prompt) to solve some of these issues, but the average user is more likely to remain stuck.

In this article, we offer tips on how to fix “the underlying connection was closed,” one of the most seemingly irresolvable errors on Windows 10 and 11. First, we explain the error and its causes, and then we present the methods for fixing it.

What is the SSL/TLS Secure Channel Error?

The SSL/TLS secure channel error is closely related to a user’s connection to a web server. Specifically, it is an issue with the website’s SSL certificate. SSL certificate (short for Secure Sockets Layer certificate) is a digital document that shows that a website is secure and encrypted according to the standards of the Internet. This certificate signifies a website’s level of security and confirms that the website is not overly susceptible to the activities of cybercriminals.

Now, an SSL error refers simply to the fact that your web browser is having issues authenticating the SSL certificate on a website. This may be because the SSL certificate on the website has expired or is nonexistent. Whichever the case, your web browser thinks that the website is not secure and should not be used.

Typically, when your web browser displays an SSL error message, the address bar already shows you that the website is insecure. A secure website has a padlock icon. So, when you see this padlock icon, you know that the search engine has already approved the website and you can keep payment and password information on such websites. But when there is no padlock icon, the web address reads “HTTP” instead of “HTTPS,” and your web warns you that the website is insecure, you can still use the website—just not for anything that has to do with your passwords and payment transactions.

In addition to the SSL (and SSL error) there is TLS (Transport Layer Security). The latter is an improvement upon SSL. Thus, it is a security protocol that ensures that information can be streamed between two channels, the web server and the client (you), without any problems. These problems could be an illegal intermediary like a hacker’s algorithm or a tracker that steals data. In any case, the protocol ensures that the communication between a web server and a user is safe.

TLS error, in this context, consequently refers to any error that frustrates the communication between a web server and a user. Whether this is a result of the server’s inadequacies or the user’s browser applications or machine, TLS errors prevent the user from accessing the content on the web server.

The SSL/TLS secure channel error is technically referred to as a handshake error. Simply put, this handshake error, which could take the form of “the underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel”, occurs because your web browser cannot verify the validity of the server. This verification process is like a handshake between your side (your PC and web browser) and the server side. When it fails, you get the “underlying connection was closed…” error.

Causes of the SSL/TLS Errors on Windows 10 and 11

There are many possible causes for the SSL/TLS errors on Windows 10 and 11. Once again, these errors could be from the end of the user or the server. In any case, “the underlying connection was closed” is triggered when:

1. The SSL certificate is invalid, expired, or revoked: The most common reason for the TLS/SSL error is that there is something wrong with the SSL certificate. This is a server or hostname issue that could take many forms. It could be that the website does not have an SSL certificate. However, with the ease of acquiring these digital signatures, it is more likely that the certificate is invalid because it is incomplete or does not match the URL hostname. If this is not the case, then the certificate on the website has expired or been revoked.
2. The user’s time or date is incorrect: Interestingly, something as trivial as incorrect time settings can trigger the SSL/TLS error. If your PC runs on manual time, for example, and you happened to remove and install your PC battery, there will be a noticeable lag in time. Therefore, if you do not set your time to automatic sync or use the universal time option, some of your browsers may not be able to verify the SSL/TLS certificate on a website.
3. There is an incompatible plugin or web browser configuration: Any number of things could be wrong with the browser you are using. Maybe there is a plugin that has a high web-safety requirement and consequently shuts down the connection to a server it considers inadequate. Or it could be that you somehow configured your browser to block your communication with particular websites or servers.
4. A third-party application/protocol is interrupting the handshake process: There may be an active third-party application that is interrupting the SSL/TLS handshake process. There are two well-known culprits capable of this: antivirus software applications and VPNs. Both of these applications can use firewalls to refuse your connection to a website, resulting in the “Could not establish trust relationship” error.
5. The user needs to update their OS: It could simply be that your system OS is lacking something. As a result, the majority of its servers are insufficient for establishing a connection.

How to Fix “the underlying connection was closed: could not establish trust relationship for the SSL/TLS secure channel” Error on Windows 10

There are several ways you can effortlessly fix the SSL/TLS error on Windows 10 and 11. These are outlined below.

1. Try a Different Browser: The first thing you should do when you encounter the “The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel” error is try a different browser. If you were using Google Chrome before, try using Mozilla Firefox or Microsoft Edge or any of the many other browsers.
2. Reconfigure Your Browser: Assuming you don’t have another web browser installed on your PC, you could reconfigure your browser to ‘tolerate’ a website, irrespective of its SSL/TLS certificate problems. For example, you can enable Google Chrome to show content on insecure websites by following the subsequent process:

• Navigate to the options menu by clicking the three dots at the top right-side of your Chrome interface.
• Select Settings from the options and the Security and Privacy tab on the left pane.
• Navigate to and click Site Settings and choose the Additional content settings from the options that pop up.
• Select the Insecure content option and tap the Add button for the Allowed to show insecure content
• Type in the URL of the website and add it.

1. Enable TLS 1.2: You could also enable TLS 1.2 on your PC so that it runs the current protocol for verifying SSL/TLS certificates. To do this,

• Initiate the Run program with Windows key + R.
• Type cpl into the text box and enter. This takes you to the Internet Properties pop-up window.
• Navigate to the Advanced tab options and scroll down to the TLS options.
• Select and tick the Use TLS 1.2.
• Click OK and restart your PC.

1. Update PC Time/Date: If your PC time is incorrect and the SSL/TLS error keeps popping up, you should set the time to automatic update. This way, whenever your PC is connected to the Internet, it will synchronize your clock. To do this (option on Windows 11/10),

• Go to the Settings page on your PC and select the Time and Language
• From the Date & time tab, make sure that the Set time automatically option is turned on.
• Click the Sync now

If you notice that restarting your PC resets this setting, you will need to use the Services option to set up an automatic synchronization. This way, you would not need to use the Sync now option whenever you restart your PC. To set up automatic time synchronization,

• Initiate the Run program with Windows key + R.
• Type msc into the text box and enter.
• From the options that pop up, scroll down to Windows Time.
• Right-click on the Windows Time option and select Properties.
• Navigate to the Startup type button and choose Automatic from the options.
• Move your cursor to the Service status option and select Start.
• Next, click the Apply option and OK, and then restart your PC.

1. Opt for an Alternative Web Server: If you don’t have a way to get the web link to the website you are trying to reach and can only do that through a software application, you may need to look for an alternative web server from which to access the web content. On this front, you may be trying to use the cracked version of an application and are trying to go around the SSL/TLS secure channel error that pops up as a result. Visiting the official website and downloading the genuine software version and release is better for your PC health. This will save you from the stress of worrying about the invalid SSL certificate of the other website.
2. Temporarily Shut Down Antivirus/VPN: You can also solve the “The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel” error by temporarily shutting down your Windows antivirus or the VPN you are currently using. As earlier explained, these applications have strong firewall protocols that may be responsible for the SSL/TLS error. Simply put, these protocols can block any perceived threat and therefore prevent you from accessing content from particular websites or servers. So, all you need to do is temporarily shut down these applications and you should be able to access the website. To temporarily disable the Windows Security app (which is the default antivirus for Windows 11/10),

• Open the Windows Security app and select the Virus and threat protection tab on the left pane.
• Move your cursor to the Virus and threat protection settings and click on Manage settings.
• From the options that pop up, you can disable the button for Real-time protection, as well as Cloud-delivered protection.
• Then you can try accessing the web server once again.

Note that this solution is not very safe. If the website is insecure and has cyber criminals waiting to breach the security of your system, this option effectively opens you up to attacks. Therefore, whenever you use this option (of disabling your antivirus temporarily) to access a website with a faulty SSL certificate, restart your PC immediately after so that the Windows antivirus can scan and remove every suspicious file from your PC. You can also use a trusted and safe malware tool in addition to Windows Security to give your PC added protection.

How to Fix TLS/SSL Errors on Windows 11

In addition to the global solutions presented in the previous section for fixing TLS/SSL errors on Windows, you can also use the control update command for Windows 11. This is a shortcut that you can use with the Run program (Windows key + R) to download and install needed driver and service updates for your Windows 11 OS. Simply open Run, type “control update” in the Run field, and click Enter. The system will start checking for new updates immediately.

Nevertheless, even though Windows 11 is still being strengthened and reinforced to remove gaps, it is easier to fix the “The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel” error on it. Therefore, if you are using Windows 11, the first thing to do when you encounter this error is update your Windows. If it doesn’t work, you can use the other solutions presented in this article.

Hi,

I worked yesterday on repro but it’s seems difficult.

I can’t post the certificate publicly on github. How can i send you this information privately ?

The certificate looks like this:

$ openssl x509 -in certificate.crt -text -noout
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 0 (0x0)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: CN = *.subdomain.wcfbug2499.local
        Validity
            Not Before: Jun 22 10:23:42 2009 GMT
            Not After : Jun 20 10:23:42 2019 GMT
        Subject: CN = *.subdomain.wcfbug2499.local
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (1024 bit)
                Modulus:
                    00:b7:f9:b4:6d:9d:13:01:a2:5a:f8:64:c2:9d:49:
                    f0:40:d6:55:a3:28:4c:3b:70:9d:64:fb:87:5a:1e:
                    51:5a:e6:08:eb:dd:91:aa:a2:94:50:bf:e3:6b:be:
                    d9:bf:75:8f:ce:9a:1f:d5:de:6b:20:60:58:74:29:
                    bd:56:76:b2:cf:bf:34:2b:22:ab:5e:46:78:74:0f:
                    22:d3:0c:a8:02:c0:c0:d2:84:bb:1f:68:5a:69:23:
                    f7:3b:73:d0:c3:9b:2c:9b:cd:21:f3:24:2c:d0:7f:
                    05:11:38:48:9f:77:18:0d:06:5d:70:7c:6d:85:b9:
                    3e:8d:81:5d:9b:8d:1a:1d:a5
                Exponent: 65537 (0x10001)
    Signature Algorithm: md5WithRSAEncryption
         4c:12:f8:50:ec:ec:36:f4:fb:45:f3:53:19:7a:ad:49:63:c6:
         e2:09:d0:41:ec:71:74:b0:88:a2:39:51:4c:8a:8a:4d:2f:5f:
         49:d2:4c:ed:23:a8:05:e6:e3:45:6b:a4:da:5e:75:9f:95:74:
         82:65:55:09:fb:30:9b:b6:7b:c0:70:79:53:1b:17:5f:d4:8e:
         db:dc:15:0e:70:52:35:88:3d:9c:e5:bb:80:b9:16:22:5e:9e:
         2f:9a:e0:c6:3c:ea:e5:9b:7e:c7:de:66:fd:a9:fb:25:f3:b1:
         70:d5:fb:b9:14:6b:16:0e:29:7a:7c:b8:bd:ce:fc:dd:d9:fa:
         98:2b

This is not the real certificate: it’s was made up and it’s likely not working but may be it will help.

This certificate expired in june 2019 but the problem happened before the expiration. And it’s working as expected when not using SocketsHttpHandler.

This is the unit test i use to show the problem:

[Test]
public void Should_Not_Throw_On_No_Trust_Domain()
{
    //AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);

    BasicHttpBinding binding = new BasicHttpBinding
    {
        CloseTimeout = TimeSpan.Parse("00:10:00"),
        OpenTimeout = TimeSpan.Parse("00:10:00"),
        ReceiveTimeout = TimeSpan.Parse("00:10:00"),
        SendTimeout = TimeSpan.Parse("00:10:00"),
        MaxBufferPoolSize = 90000000,
        MaxBufferSize = 90000000,
        MaxReceivedMessageSize = 90000000,
        ReaderQuotas = new XmlDictionaryReaderQuotas
        {
            MaxDepth = 32,
            MaxArrayLength = 90000000,
            MaxStringContentLength = 90000000
        },
    };
    binding.Security.Mode = BasicHttpSecurityMode.Transport;
    binding.Security.Transport = new HttpTransportSecurity
    {
        ClientCredentialType = HttpClientCredentialType.None,
        ProxyCredentialType = HttpProxyCredentialType.Basic
    };
    EndpointAddress remoteAddress = new EndpointAddress("https://abc.subdomain.wcfbug2499.local/path-to-service");
    WcfServiceClient client = new WcfServiceClient(binding, remoteAddress);

    client.ChannelFactory.Credentials.ServiceCertificate.SslCertificateAuthentication =
        client.ClientCredentials.ServiceCertificate.SslCertificateAuthentication =
            new X509ServiceCertificateAuthentication
            {
                CertificateValidationMode = X509CertificateValidationMode.None,
                RevocationMode = X509RevocationMode.NoCheck,
                TrustedStoreLocation = StoreLocation.LocalMachine
            };

    try
    {
        string serviceResultat = client.DemoClient();

        ((ICommunicationObject) client).Close();
        
        Assert.IsNotNull(serviceResultat);
    }
    catch (CommunicationException)
    {
        client.Abort();
        throw;
    }
    catch (TimeoutException)
    {
        client.Abort();
        throw;
    }
    catch (Exception)
    {
        client.Abort();
        throw;
    }
}

[ServiceContract]
public interface IWcfService
{
    [OperationContract]
    string DemoClient();
}

public class WcfServiceClient : System.ServiceModel.ClientBase<IWcfService>, IWcfService
{

    public WcfServiceClient()
    {
    }

    public WcfServiceClient(string endpointConfigurationName) :
        base(endpointConfigurationName)
    {
    }

    public WcfServiceClient(string endpointConfigurationName, string remoteAddress) :
        base(endpointConfigurationName, remoteAddress)
    {
    }

    public WcfServiceClient(string endpointConfigurationName,
        System.ServiceModel.EndpointAddress remoteAddress) :
        base(endpointConfigurationName, remoteAddress)
    {
    }

    public WcfServiceClient(System.ServiceModel.Channels.Binding binding,
        System.ServiceModel.EndpointAddress remoteAddress) :
        base(binding, remoteAddress)
    {
    }

    /// <inheritdoc />
    public string DemoClient()
    {
        return base.Channel.DemoClient();
    }
}

It’s worked when the switch System.Net.Http.UseSocketsHttpHandler have the value false.

It’s produced the following stack strace when the switch System.Net.Http.UseSocketsHttpHandler have the value true:

System.ServiceModel.Security.SecurityNegotiationException : Could not establish trust relationship for the SSL/TLS secure channel with authority 'abc.subdomain.wcfbug2499.local'.
  ----> System.Net.Http.HttpRequestException : The SSL connection could not be established, see inner exception.
  ----> System.Security.Authentication.AuthenticationException : Authentication failed, see inner exception.
  ----> System.ComponentModel.Win32Exception : Le jeton fourni à la fonction n’est pas valide
   at System.ServiceModel.Channels.HttpChannelUtilities.ProcessGetResponseWebException(HttpRequestException requestException, HttpRequestMessage request, HttpAbortReason abortReason)
   at System.ServiceModel.Channels.HttpChannelFactory`1.HttpClientRequestChannel.HttpClientChannelAsyncRequest.SendRequestAsync(Message message, TimeoutHelper timeoutHelper)
   at System.ServiceModel.Channels.RequestChannel.RequestAsync(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.RequestChannel.RequestAsyncInternal(Message message, TimeSpan timeout)
   at System.Runtime.TaskHelpers.WaitForCompletionNoSpin[TResult](Task`1 task)
   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(MethodCall methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(MethodInfo targetMethod, Object[] args)
--- End of stack trace from previous location where exception was thrown ---
   at System.Reflection.DispatchProxyGenerator.Invoke(Object[] args)
   at generatedProxy_1.DemoClient()
   at WcfBug2499.WcfServiceClient.DemoClient() in C:devsandboxWcfBug2499WcfBug2499.TestsWcfBug2499UsingLocalDomainTests.cs:line 121
   at WcfBug2499.WcfBug2499UsingLocalDomainTests.Should_Not_Throw_On_No_Trust_Domain() in C:devsandboxWcfBug2499WcfBug2499.TestsWcfBug2499UsingLocalDomainTests.cs:line 56
--HttpRequestException
   at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnectionPool.CreateConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnectionPool.WaitForCreatedConnectionAsync(ValueTask`1 creationTask)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationToken cancellationToken)
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.DecompressionHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.FinishSendAsyncUnbuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
   at System.ServiceModel.Channels.HttpChannelFactory`1.HttpClientRequestChannel.HttpClientChannelAsyncRequest.SendRequestAsync(Message message, TimeoutHelper timeoutHelper)
--AuthenticationException
   at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, ExceptionDispatchInfo exception)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.PartialFrameCallback(AsyncProtocolRequest asyncRequest)
--- End of stack trace from previous location where exception was thrown ---
   at System.Net.Security.SslState.ThrowIfExceptional()
   at System.Net.Security.SslState.InternalEndProcessAuthentication(LazyAsyncResult lazyResult)
   at System.Net.Security.SslState.EndProcessAuthentication(IAsyncResult result)
   at System.Net.Security.SslStream.EndAuthenticateAsClient(IAsyncResult asyncResult)
   at System.Net.Security.SslStream.<>c.<AuthenticateAsClientAsync>b__47_1(IAsyncResult iar)
   at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)
--- End of stack trace from previous location where exception was thrown ---
   at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken)
--Win32Exception

The following snippets will fix the case where there is something wrong with the SSL certificate on the server you are calling. For example, it may be self-signed or the host name between the certificate and the server may not match.

This is dangerous if you are calling a server outside of your direct control, since you can no longer be as sure that you are talking to the server you think you’re connected to. However, if you are dealing with internal servers and getting a «correct» certificate is not practical, use the following to tell the web service to ignore the certificate problems and bravely soldier on.

The first two use lambda expressions, the third uses regular code. The first accepts any certificate. The last two at least check that the host name in the certificate is the one you expect.
… hope you find it helpful

//Trust all certificates
System.Net.ServicePointManager.ServerCertificateValidationCallback =
    ((sender, certificate, chain, sslPolicyErrors) => true);

// trust sender
System.Net.ServicePointManager.ServerCertificateValidationCallback
                = ((sender, cert, chain, errors) => cert.Subject.Contains("YourServerName"));

// validate cert by calling a function
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);

// callback used to validate the certificate in an SSL conversation
private static bool ValidateRemoteCertificate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors policyErrors)
{
    bool result = cert.Subject.Contains("YourServerName");
    return result;
}

The following snippets will fix the case where there is something wrong with the SSL certificate on the server you are calling. For example, it may be self-signed or the host name between the certificate and the server may not match.

This is dangerous if you are calling a server outside of your direct control, since you can no longer be as sure that you are talking to the server you think you’re connected to. However, if you are dealing with internal servers and getting a «correct» certificate is not practical, use the following to tell the web service to ignore the certificate problems and bravely soldier on.

The first two use lambda expressions, the third uses regular code. The first accepts any certificate. The last two at least check that the host name in the certificate is the one you expect.
… hope you find it helpful

//Trust all certificates
System.Net.ServicePointManager.ServerCertificateValidationCallback =
    ((sender, certificate, chain, sslPolicyErrors) => true);

// trust sender
System.Net.ServicePointManager.ServerCertificateValidationCallback
                = ((sender, cert, chain, errors) => cert.Subject.Contains("YourServerName"));

// validate cert by calling a function
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);

// callback used to validate the certificate in an SSL conversation
private static bool ValidateRemoteCertificate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors policyErrors)
{
    bool result = cert.Subject.Contains("YourServerName");
    return result;
}

Environment

SharePoint 2013, Windows Azure AD service as Identity Provider.

Scenario

Using SAML Authentication and was trying to access a service application from SSL enabled Portal. Exported the service application security certificate and imported into SharePoint Trusted Root Certificate authority

Problem

Following is the error message when trying to connect to service application from SharePoint.  “The underlying connection was closed: Could not establish trust relationship for the SSL/TLS
secure channel”.

Resolution

The imported certificate is having some validation error. The problem was incorrect host name used in certificates. 
We were accessing the URL using the IP and the certificate is using the server name as ip-AC1F08ED. The resolution is either we should have service application URL with fully qualified domain name or the certificate issue should
point to the server IP.

Following error in event viewer. 
Error: «An operation failed because the following certificate has validation errors»