Jak rozwiązać " nie można ustanowić relacji zaufania dla bezpiecznego kanału SSL / TLS z urzędem"

Kiedy mam ten problem, to dlatego, że klient.config miał swoje punkty końcowe:

 https://myserver/myservice.svc 

Ale certyfikat oczekiwał

 https://myserver.mydomain.com/myservice.svc

Zmiana punktów końcowych, aby pasowały do FQDN serwera rozwiązuje mój problem. Wiem, że to nie jedyna przyczyna tego problemu.

Twój problem pojawia się, ponieważ używasz samodzielnie podpisanego klucza. Klient nie ufa temu kluczowi, ani sam klucz nie zapewnia łańcucha do walidacji ani listy odwołań certyfikatu.

Masz kilka opcji-możesz

1. Wyłącz sprawdzanie poprawności certyfikatu klient (zły ruch, człowiek w środkowe ataki obfitują)

2. Użyj makecert, aby utworzyć root CA i utwórz z tego certyfikaty (ok move, ale nadal nie ma CRL)

3. Utwórz wewnętrzny korzeń CA za pomocą Windows Certificate Server lub inne Rozwiązanie PKI to Zaufaj temu rootowi cert (a bit of a pain to manage)

4. Zakup certyfikatu SSL od jednego zaufanego CAs (drogie)

Dwie pierwsze używają lambda, trzecia używa zwykłego kodu... mam nadzieję, że okaże się to pomocne

            //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 = false;
        if (cert.Subject.ToUpper().Contains("YourServerName"))
        {
            result = true;
        }

        return result;
    }

Rozwiązanie jednoliniowe. Dodaj to w dowolnym miejscu przed wywołaniem serwera po stronie klienta:

System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };

Powinno to być używane tylko do celów testowych, ponieważ klient pominie kontrole bezpieczeństwa SSL / TLS.

Napotkałem ten sam problem i udało mi się go rozwiązać dwoma rozwiązaniami: Najpierw użyłem przystawki MMC "certyfikaty" dla "konta komputerowego" i przeciągnąłem certyfikat z podpisem własnym do folderu "Zaufane główne urzędy certyfikacji". Oznacza to, że lokalny komputer (ten, który wygenerował certyfikat) będzie teraz ufał temu certyfikatowi. Po drugie zauważyłem, że certyfikat został wygenerowany dla jakiejś wewnętrznej nazwy komputera, ale usługa internetowa była dostępna za pomocą inne nazwisko. Spowodowało to niedopasowanie podczas walidacji certyfikatu. Wygenerowaliśmy certyfikat dla komputera.szef.lokalny, ale dostęp do usługi internetowej za pomocą https://computer.internaldomain.companydomain.com . Kiedy zmieniliśmy adres URL na ten, który został użyty do wygenerowania certyfikatu, nie otrzymaliśmy więcej błędów.

Być może samo przełączanie adresów URL zadziałałoby, ale czyniąc certyfikat zaufanym, unikasz również czerwonego ekranu w przeglądarce Internet Explorer, gdzie mówi ci, że nie ufa certyfikat.

Wykonaj następujące kroki:

1. Open service link W IE.

2. Kliknij wzmiankę o błędzie certyfikatu na pasku adresu i kliknij Wyświetl certyfikaty.

3. Czek wystawiony na: imię i nazwisko.

4. Przyjmij wydaną nazwę i zastąp localhost wzmiankę w usłudze i kliencie endpoint base address name pełną kwalifikowaną nazwą domeny (FQDN).

Na przykład: https://localhost:203/SampleService.svc Na https: / / INL-126166-.groupinfra.com : 203 / SampleService. svc

Miałem ten sam problem. Dodałem również certyfikaty CA w lokalnym sklepie, ale zrobiłem w niewłaściwy sposób.

Używając konsoli mmc (Start - > Run - > mmc) należy dodać certyfikaty jako konto usługi (wybierając konto usługi IIS) lub konto komputera (dodaje się dla każdego konta na komputerze)

Oto obraz tego, o czym mówię

Od teraz możesz dodać certyfikaty CAs ( zaufany Root CAs i Intermediate CAs ), a wszystko będzie dobrze działać

Miałem podobny problem z certyfikatem własnoręcznie podpisanym. Mogę go rozwiązać, używając nazwy certyfikatu takiej samej jak FQDN serwera.

Idealnie, część SSL powinna być zarządzana po stronie serwera. Klient nie musi instalować żadnego certyfikatu dla SSL. Również niektóre z postów wymienionych o omijaniu SSL z kodu klienta. Ale całkowicie się z tym nie zgadzam.

Właśnie przeciągnąłem certyfikat do folderu "Trusted Root Certification Authorities" i voila wszystko działało ładnie.

netsh http add urlacl url=https://+:8732/Servicename user=NT-MYNDIGHET\INTERAKTIV

Nie jestem pewien, jakiej nazwy potrzebujesz dla użytkownika (moja jest norweska, jak widać !): user=NT-AUTHORITY/INTERACTIVE ?

Możesz zobaczyć wszystkie istniejące urlacl ' y, wydając polecenie: netsh http show urlacl

Oprócz powyższych odpowiedzi, możesz napotkać ten błąd, jeśli twój Klient uruchamia złą wersję TLS, na przykład jeśli serwer obsługuje tylko TLS 1.2.

Możesz to naprawić używając:

            ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; //tested in .NET 4.5

Miało to miejsce podczas próby połączenia się z usługą WCF używając tylko nazwy hosta, np. https://host/MyService.svc Podczas używania certyfikatu powiązanego z nazwą np. host.mysite.com.

Przełączanie na https://host.mysite.com/MyService.svc i to rozwiązało sprawę.

Miało to miejsce podczas próby połączenia się z usługą WCF poprzez. IP np. https://111.11.111.1:port/MyService.svc podczas używania certyfikatu powiązanego z nazwą np. mysite.com.

Przejście na https://mysite.com:port/MyService.svc rozwiązało to.

Po prostu Naprawiono podobny problem.

Zdałem sobie sprawę, że mam pulę aplikacji, która była uruchomiona pod kontem, które miało tylko uprawnienia do odczytu nad certyfikatem, że zostało użyte.

Aplikacja. NET mogła poprawnie pobrać certyfikat, ale ten wyjątek został wyrzucony tylko po wywołaniu GetRequestStream ().

Uprawnienia certyfikatów można zarządzać za pomocą MMC console

Dodaj to do kodu klienta:

ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(
    delegate
    {
        return true;
    });