locked
AuthenticationException: The remote certificate is invalid according to the validation procedure RRS feed

  • Question

  • User1804174617 posted

    We have a legacy web application which was developed with ASP.NET 2.0 for SharePoint 2010. The application consumes a 3rd-party web service with the HTTP protocol. Recently the 3rd-party web service was migrated to support the HTTPS protocol. We updated our application to use the HTTPS web service meanwhile keep our application with the HTTP protocol. We added CA certificates on the machine which runs our web application. When entering the HTTPS URL in an Internet Explorer 11 browser, we can get a correct response from the 3rd-party web service. But when run our web application which calls the HTTPS URL, we get a server error "The remote certificate is invalid according to the validation procedure".

    Here are some questions regarding the issue:

    1. Do we need to upgrade our application to use HTTPS protocol in order to call the 3rd-party HTTPS URL?
    2. Do we need to upgrade our application to a later version of .NET Framework (say .NET Framework 4.6)?
    3. Do we need to update our application, other than the URL itself and the CA certificates, to call the 3rd-party HTTPS URL?
    4. Anything else which may cause the issue?

    Your help is very much appreciated.

    Environments:

    OS: Windows Server 2008 R2, SharePoint 2010

    .NET Framework: ASP.NET 2.0

    Tool: Visual Studio 2010

    Monday, December 3, 2018 11:18 PM

Answers

All replies

  • User-943250815 posted

    yongcao99

    Do we need to upgrade our application to use HTTPS protocol in order to call the 3rd-party HTTPS URL?


    Only if 3rd-party is using TLS1.1 or TLS1.2, you have to upgrade at least to .NET 4.6, But this is not (for now) related to Certificate issue

    yongcao99

    Do we need to update our application, other than the URL itself and the CA certificates, to call the 3rd-party HTTPS URL?


    Just for Certificate I don´t think it is necessary any upgrade.

    On the other hand, when you installed 3rd-party certificate I almost sure you installed for "Current User", and ASP.NET runs using "Local Machine Context", so your browser trust on certificate, but ASP.NET not.
    Take a look here https://blogs.msdn.microsoft.com/jpsanders/2009/09/16/troubleshooting-asp-net-the-remote-certificate-is-invalid-according-to-the-validation-procedure/

    Tuesday, December 4, 2018 7:43 PM
  • User1804174617 posted

    Thank you @jzero. We have installed CA certificates in both ‘Current User’ and ‘(Local Computer)’ on our machine. Does the 3rd-party need to install their certificates in different stores?

    Tuesday, December 4, 2018 10:59 PM
  • User-943250815 posted

    It was supposed they have own Certificate on right place and web server configured correctly and it is expected not be a self-certificate.
    Please read again the link I sent, there are some instructions for you trace and get some more info.

    As a test and "only as test" you can by-pass Certificate Validation Check using right before call WebService, this definition is global so just use it as a test, to check if you cant contact WebService
    System.Net.ServicePointManager.ServerCertificateValidationCallback = New System.Net.Security.RemoteCertificateValidationCallback(AddressOf MyValidateAnyCert)

    Where "MyValidateAnyCert" is a function like:
    Public Shared Function MyValidateAnyCert(ByVal sender As Object, ByVal certificate As X509Certificate, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean
    Return True ' Just return true, do not validate cert
    End Function

    Do not use it in Production

    Wednesday, December 5, 2018 12:09 AM
  • User1804174617 posted

    If I add the following code to ignore the certificate validation:

        ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, errors) =>return true; };

    the web application will work fine. We know for sure that there is something wrong with the certificate validation.

    I also added the System.Net trace by following the https://blogs.msdn.microsoft.com/jpsanders/2009/09/16/troubleshooting-asp-net-the-remote-certificate-is-invalid-according-to-the-validation-procedure/. Here are some logs:

    System.Net Information: 0 : [18440] SecureChannel#63583231::.ctor(hostname=webservices.central1.com, #clientCertificates=0)

        ProcessId=7288

        DateTime=2018-12-07T23:57:52.8200169Z

    System.Net Information: 0 : [18440] SecureChannel#63583231 - Left with 0 client certificates to choose from.

        ProcessId=7288

        DateTime=2018-12-07T23:57:52.8210170Z

    System.Net Information: 0 : [18440] SecureChannel#63583231 - Remote certificate was verified as invalid by the user.

        ProcessId=7288

        DateTime=2018-12-07T23:57:53.7941143Z

    System.Net.Sockets Verbose: 0 : [18440] Socket#8181468::Dispose()

        ProcessId=7288

        DateTime=2018-12-07T23:57:54.0071356Z

    System.Net Error: 0 : [18440] Exception in the HttpWebRequest#50261861:: - The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

        ProcessId=7288

        DateTime=2018-12-07T23:57:54.0071356Z

    Saturday, December 8, 2018 12:48 AM
  • User-943250815 posted

    yongcao99

    Left with 0 client certificates to choose from.


    Just in case, do you have installed all chain certificates and root certificates?
    As an example I have to contact a system of some states in my country, so I have to get installed State Certificate, Chain Certificates and Root Certificate, (at right place) due to trust relation.

    Also check if certificate you have is for "webservices.central1.com" and not for "www.central1.com" or any other ?????.central1.com

    Can you share the full url of webservice to get wsdl?


    At this moment is all I can suggest you

    Saturday, December 8, 2018 3:15 PM
  • User1804174617 posted

    Thank you @jzero. We found out that the 3rd-party is using TLS1.2 and our legacy ASP.NET 2.0 application is using SSL 3.0. The System.Net trace does not explicitly indicate that the protocols are mismatching. 

    TLS is enabled and SSL is disabled by default for Internet Explorer 11. That is why when entering the HTTPS URL in an Internet Explorer 11 browser, we can get a correct response from the 3rd-party web service. By disabling TLS and enabling SSL, we got a "This page can't be displayed" message.

    We need to upgrade our legacy web application to a higher version of .NET Framework to use TLS 1.2.

    Tuesday, December 18, 2018 6:39 PM
  • User1804174617 posted

    I can mark as answer, @jzero should get the credit.

    Tuesday, December 18, 2018 6:43 PM
  • User-943250815 posted

    Nice, now you have (at least) a starting point.
    Suggest you install VS2015, so you can set "Target Framework" to 4.6 and above. At this time do not remove your existing VS2010
    As I remember on VS2010 there is no such option on the list (Property Pages > Build > Target Framework), and I'm not sure if just changing on web.config will work

    After you get new VS2015 installed, make a copy of all files to a new folder and open with VS2015. As soon you open in VS2015, if necessary a Conversion process should run and made changes or alert you about some issues.
    I recommending VS2015, because there is no straight conversion from 2010 > 2017, if you want use VS2017, you have first convert to 2015 then 2017
    Here some notes about migrating projects/websites from older versions to VS2015 and to VS2017
    https://docs.microsoft.com/en-us/visualstudio/porting/porting-migrating-and-upgrading-visual-studio-projects?view=vs-2015
    https://docs.microsoft.com/en-us/visualstudio/porting/port-migrate-and-upgrade-visual-studio-projects?view=vs-2017
    Here you can get older versions of VS https://visualstudio.microsoft.com/vs/older-downloads/

    So unfortunately you have a long path.

    Appreciate you intent to mark as answer, if you want do it, just click on link right above message.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, December 19, 2018 12:20 PM