Zezwalanie na niezaufane certyfikaty SSL z HttpClient

Mam problem z komunikacją mojej aplikacji Windows 8 z testowym interfejsem API sieci Web przez SSL.

Wygląda na to, że HttpClient / HttpClientHandler nie zapewnia, a opcja ignorowania niezaufanych certyfikatów, takich jak WebRequest, umożliwia Ci to (choć w „hacky” sposób ServerCertificateValidationCallback).

Każda pomoc byłaby bardzo mile widziana!

W systemie Windows 8.1 możesz teraz ufać nieprawidłowym certyfikatom SSL. Musisz użyć Windows.Web.HttpClient lub jeśli chcesz użyć System.Net.Http.HttpClient, możesz użyć adaptera obsługi komunikatów, który napisałem: http://www.nuget.org/packages/WinRtHttpClientHandler

Dokumenty są na GitHub: https://github.com/onovotny/WinRtHttpClientHandler

Szybkim i brudnym rozwiązaniem jest skorzystanie z ServicePointManager.ServerCertificateValidationCallbackdelegata. Pozwala to na zapewnienie własnej walidacji certyfikatu. Walidacja jest stosowana globalnie w całej domenie aplikacji.

ServicePointManager.ServerCertificateValidationCallback +=
    (sender, cert, chain, sslPolicyErrors) => true;

Używam tego głównie do testów jednostkowych w sytuacjach, w których chcę uruchomić punkt końcowy, który hostuję w procesie i próbuję trafić go za pomocą klienta WCF lub HttpClient.

W przypadku kodu produkcyjnego możesz potrzebować dokładniejszej kontroli i lepiej byłoby użyć właściwości WebRequestHandleri jej ServerCertificateValidationCallbackdelegata (patrz odpowiedź dtb poniżej ). Lub ctacke odpowiedź za pomocą HttpClientHandler. Wolę jeden z tych dwóch teraz, nawet w moich testach integracji, niż sposób, w jaki to robiłem, chyba że nie mogę znaleźć żadnego innego zaczepu.

Przyjrzyj się klasie WebRequestHandler i jej właściwości ServerCertificateValidationCallback :

using (var handler = new WebRequestHandler())
{
    handler.ServerCertificateValidationCallback = ...

    using (var client = new HttpClient(handler))
    {
        ...
    }
}

Jeśli próbujesz to zrobić w bibliotece .NET Standard, oto proste rozwiązanie, z całym ryzykiem związanym z powrotem truedo programu obsługi. Bezpieczeństwo pozostawiam tobie.

var handler = new HttpClientHandler();
handler.ClientCertificateOptions = ClientCertificateOption.Manual;
handler.ServerCertificateCustomValidationCallback = 
    (httpRequestMessage, cert, cetChain, policyErrors) =>
{
    return true;
};

var client = new HttpClient(handler);

Lub możesz użyć dla HttpClient w Windows.Web.Httpprzestrzeni nazw:

var filter = new HttpBaseProtocolFilter();
#if DEBUG
    filter.IgnorableServerCertificateErrors.Add(ChainValidationResult.Expired);
    filter.IgnorableServerCertificateErrors.Add(ChainValidationResult.Untrusted);
    filter.IgnorableServerCertificateErrors.Add(ChainValidationResult.InvalidName);
#endif
using (var httpClient = new HttpClient(filter)) {
    ...
}

Jeśli używasz, System.Net.Http.HttpClientuważam, że prawidłowy wzór jest

var handler = new HttpClientHandler() 
{ 
    ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
};

var http = new HttpClient(handler);
var res = http.GetAsync(url);

Większość odpowiedzi sugeruje użycie typowego wzoru:

using (var httpClient = new HttpClient())
{
 // do something
}

ze względu na interfejs IDisposable. Proszę, nie rób tego!

Microsoft wyjaśnia, dlaczego:

• https://docs.microsoft.com/en-us/azure/architecture/antipatterns/improper-instantiation
• https://blogs.msdn.microsoft.com/henrikn/2012/08/07/httpclient-httpclienthandler-and-webrequesthandler-explained/

A tutaj możesz znaleźć szczegółową analizę tego, co dzieje się za kulisami: https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

Jeśli chodzi o Twoje pytanie dotyczące SSL i na podstawie https://docs.microsoft.com/en-us/azure/architecture/antipatterns/improper-instantiation/#how-to-fix-the-problem

Oto twój wzór:

class HttpInterface
{
 // https://docs.microsoft.com/en-us/azure/architecture/antipatterns/improper-instantiation/#how-to-fix-the-problem
 // https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient#remarks
 private static readonly HttpClient client;

 // static initialize
 static HttpInterface()
 {
  // choose one of these depending on your framework

  // HttpClientHandler is an HttpMessageHandler with a common set of properties
  var handler = new HttpClientHandler();
  {
      ServerCertificateCustomValidationCallback = delegate { return true; },
  };
  // derives from HttpClientHandler but adds properties that generally only are available on full .NET
  var handler = new WebRequestHandler()
  {
      ServerCertificateValidationCallback = delegate { return true; },
      ServerCertificateCustomValidationCallback = delegate { return true; },
  };

  client = new HttpClient(handler);
 }

 .....

 // in your code use the static client to do your stuff
 var jsonEncoded = new StringContent(someJsonString, Encoding.UTF8, "application/json");

 // here in sync
 using (HttpResponseMessage resultMsg = client.PostAsync(someRequestUrl, jsonEncoded).Result)
 {
  using (HttpContent respContent = resultMsg.Content)
  {
   return respContent.ReadAsStringAsync().Result;
  }
 }
}

Jeśli dotyczy to aplikacji środowiska wykonawczego systemu Windows, musisz dodać certyfikat z podpisem własnym do projektu i odwołać się do niego w pliku appxmanifest.

Dokumenty są tutaj: http://msdn.microsoft.com/en-us/library/windows/apps/hh465031.aspx

To samo, jeśli pochodzi z niezaufanego urzędu certyfikacji (np. Prywatnego urzędu certyfikacji, któremu sama maszyna nie ufa) - musisz uzyskać publiczny certyfikat urzędu certyfikacji, dodać go jako zawartość do aplikacji, a następnie dodać do manifestu.

Gdy to zrobisz, aplikacja zobaczy go jako poprawnie podpisany certyfikat.

Nie mam odpowiedzi, ale mam alternatywę.

Jeśli używasz Fiddlera2 do monitorowania ruchu i włączasz deszyfrowanie HTTPS, Twoje środowisko programistyczne nie będzie narzekać. To nie zadziała na urządzeniach WinRT, takich jak Microsoft Surface, ponieważ nie można na nich zainstalować standardowych aplikacji. Ale twój programistyczny komputer z Win8 będzie w porządku.

Aby włączyć szyfrowanie HTTPS w Fiddler2, przejdź do Narzędzia> Opcje Fiddlera > HTTPS (karta)> Zaznacz „Odszyfruj ruch HTTPS” .

Będę miał na oku ten wątek mając nadzieję, że ktoś znajdzie eleganckie rozwiązanie.

Znalazłem przykład w tym kliencie Kubernetes, w którym używali X509VerificationFlags.AllowUnknownCertificateAuthority, aby ufać certyfikatom głównym z podpisem własnym. Lekko przerobiłem ich przykład, aby działał z naszymi własnymi certyfikatami głównymi zakodowanymi w PEM. Mam nadzieję, że to komuś pomoże.

namespace Utils
{
  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Net.Security;
  using System.Security.Cryptography.X509Certificates;

  /// <summary>
  /// Verifies that specific self signed root certificates are trusted.
  /// </summary>
  public class HttpClientHandler : System.Net.Http.HttpClientHandler
  {
    /// <summary>
    /// Initializes a new instance of the <see cref="HttpClientHandler"/> class.
    /// </summary>
    /// <param name="pemRootCerts">The PEM encoded root certificates to trust.</param>
    public HttpClientHandler(IEnumerable<string> pemRootCerts)
    {
      foreach (var pemRootCert in pemRootCerts)
      {
        var text = pemRootCert.Trim();
        text = text.Replace("-----BEGIN CERTIFICATE-----", string.Empty);
        text = text.Replace("-----END CERTIFICATE-----", string.Empty);
        this.rootCerts.Add(new X509Certificate2(Convert.FromBase64String(text)));
      }

      this.ServerCertificateCustomValidationCallback = this.VerifyServerCertificate;
    }

    private bool VerifyServerCertificate(
      object sender,
      X509Certificate certificate,
      X509Chain chain,
      SslPolicyErrors sslPolicyErrors)
    {
      // If the certificate is a valid, signed certificate, return true.
      if (sslPolicyErrors == SslPolicyErrors.None)
      {
        return true;
      }

      // If there are errors in the certificate chain, look at each error to determine the cause.
      if ((sslPolicyErrors & SslPolicyErrors.RemoteCertificateChainErrors) != 0)
      {
        chain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck;

        // add all your extra certificate chain
        foreach (var rootCert in this.rootCerts)
        {
          chain.ChainPolicy.ExtraStore.Add(rootCert);
        }

        chain.ChainPolicy.VerificationFlags = X509VerificationFlags.AllowUnknownCertificateAuthority;
        var isValid = chain.Build((X509Certificate2)certificate);

        var rootCertActual = chain.ChainElements[chain.ChainElements.Count - 1].Certificate;
        var rootCertExpected = this.rootCerts[this.rootCerts.Count - 1];
        isValid = isValid && rootCertActual.RawData.SequenceEqual(rootCertExpected.RawData);

        return isValid;
      }

      // In all other cases, return false.
      return false;
    }

    private readonly IList<X509Certificate2> rootCerts = new List<X509Certificate2>();
  }
}

Znalazłem przykład online, który wydaje się działać dobrze:

Najpierw utwórz nowy ICertificatePolicy

using System.Security.Cryptography.X509Certificates;
using System.Net;

public class MyPolicy : ICertificatePolicy
{
  public bool CheckValidationResult(ServicePoint srvPoint, X509Certificate certificate, WebRequest request, 
int certificateProblem)
  {
    //Return True to force the certificate to be accepted.
    return true;
  }
}

Następnie użyj tego przed wysłaniem żądania http w następujący sposób:

System.Net.ServicePointManager.CertificatePolicy = new MyPolicy();

http://www.terminally-incoherent.com/blog/2008/05/05/send-a-https-post-request-with-c/