Come risolvere "Impossibile stabilire una relazione di fiducia per il canale sicuro SSL / TLS con autorità"

Pensavo davvero di aver risolto questo problema, ma era solo mascherato prima.

Ho un servizio WCF ospitato in IIS 7 usando HTTPS. Quando passo in rassegna a questo sito in Internet Explorer, funziona come un fascino, questo è perché io ho aggiunto il certificato all'archivio locale di un'autorità di certificazione.

Sto sviluppando su 1 macchina, quindi client e server sono la stessa macchina. Il certificato è autofirmato direttamente dallo snap-in di gestione di IIS 7.

Ricevo continuamente questo errore ora ...

Impossibile stabilire una relazione di fiducia per il canale sicuro SSL / TLS con l'autorità.

... quando viene chiamato dalla console client.

Mi sono dato manualmente le autorizzazioni e il servizio di rete al certificato, usando findprivatekeye usando cacls.exe.

Ho provato a connettermi al servizio tramite SOAPUI e funziona, quindi deve essere un problema nella mia applicazione client, che è un codice basato su ciò che funzionava con http.

Dove altro posso guardare sembra che abbia esaurito tutte le possibilità sul perché non riesco a connettermi?

Come una soluzione si potrebbe aggiungere un gestore per le ServicePointManager's ServerCertificateValidationCallbacksul lato client:

System.Net.ServicePointManager.ServerCertificateValidationCallback +=
    (se, cert, chain, sslerror) =>
        {
            return true;
        };

ma tieni presente che questa non è una buona pratica in quanto ignora completamente il certificato del server e dice al gestore del punto di servizio che qualunque certificato va bene può compromettere seriamente la sicurezza del client. È possibile perfezionarlo ed eseguire alcuni controlli personalizzati (per nome certificato, hash ecc.). almeno è possibile aggirare i problemi durante lo sviluppo quando si utilizzano i certificati di prova.

Quando ho questo problema è perché client.config aveva i suoi endpoint come:

 https://myserver/myservice.svc 

ma il certificato era in attesa

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

La modifica degli endpoint in modo che corrisponda al nome di dominio completo del server risolve il mio problema. So che questa non è l'unica causa di questo problema.

i primi due usano lambda, il terzo usa un codice normale ... spero che lo trovi utile

            //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;
    }

Il tuo problema sorge perché stai usando una chiave autofirmata. Il client non considera attendibile questa chiave, né la chiave stessa fornisce una catena per la convalida o un elenco di revoche di certificati.

Hai alcune opzioni - puoi

1. disattivare la convalida del certificato sul client (mossa sbagliata, gli attacchi man in the middle abbondano)

2. usa makecert per creare una CA root e creare certificati da quella (ok sposta, ma non c'è ancora CRL)

3. creare una CA radice interna utilizzando Windows Certificate Server o altra soluzione PKI, quindi fidarsi di quel certificato root (un po 'una seccatura da gestire)

4. acquistare un certificato SSL da una delle autorità di certificazione attendibili (costoso)

Una soluzione a una linea. Aggiungi questo ovunque prima di chiamare il server sul lato client:

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

Questo dovrebbe essere usato solo a scopo di test perché il client salterà i controlli di sicurezza SSL / TLS.

Ho riscontrato lo stesso problema e sono stato in grado di risolverlo con due soluzioni: in primo luogo, ho utilizzato lo snap-in MMC "Certificati" per "Account computer" e trascinato il certificato autofirmato nella cartella "Autorità di certificazione radice attendibili" . Ciò significa che il computer locale (quello che ha generato il certificato) ora si fiderà di quel certificato. In secondo luogo, ho notato che il certificato è stato generato per un nome di computer interno, ma al servizio Web si accedeva utilizzando un altro nome. Ciò ha causato una mancata corrispondenza durante la convalida del certificato. Abbiamo generato il certificato per computer.operations.local, ma abbiamo effettuato l'accesso al servizio Web utilizzando https://computer.internaldomain.companydomain.com . Quando abbiamo passato l'URL a quello utilizzato per generare il certificato non abbiamo più riscontrato errori.

Forse il semplice cambio di URL avrebbe funzionato, ma rendendo affidabile il certificato eviti anche la schermata rossa in Internet Explorer dove ti dice che non si fida del certificato.

Se usi .net core prova questo:

client.ClientCredentials.ServiceCertificate.SslCertificateAuthentication =
        new X509ServiceCertificateAuthentication()
        {
            CertificateValidationMode = X509CertificateValidationMode.None,
            RevocationMode = System.Security.Cryptography.X509Certificates.X509RevocationMode.NoCheck
        };

Si prega di fare i seguenti passi:

1. Apri il collegamento al servizio in IE.

2. Fare clic sulla menzione dell'errore del certificato nella barra degli indirizzi e fare clic su Visualizza certificati.

3. Assegno rilasciato a: nome.

4. Prendere il nome emesso e sostituire la menzione localhost nel nome dell'indirizzo di base dell'endpoint del servizio e del client con un nome di dominio completo (FQDN).

Ad esempio: https: // localhost : 203 / SampleService.svc A https: // INL-126166-.groupinfra.com : 203 / SampleService.svc

Oltre alle risposte sopra, potresti riscontrare questo errore se il tuo client esegue una versione TLS errata, ad esempio se il server esegue solo TLS 1.2.

Puoi risolverlo usando:

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

Ho avuto lo stesso problema. Avevo anche aggiunto certificati CA nell'archivio locale, ma ho sbagliato.

Utilizzando mmc Console (Start -> Esegui -> mmc ) è necessario aggiungere lo snap-in Certificati come account di servizio (scegliendo l'account di servizio di IIS) o account di computer (si aggiunge per ogni account sulla macchina)

Ecco un'immagine di ciò di cui sto parlando

Da qui ora è possibile aggiungere certificati di CA ( CA principali attendibili e CA intermedie ) e tutto funzionerà correttamente

Ho avuto un problema simile con il certificato autofirmato. Potrei risolverlo usando il nome del certificato stesso del nome FQDN del server.

Idealmente, la parte SSL dovrebbe essere gestita sul lato server. Il client non è tenuto ad installare alcun certificato per SSL. Inoltre, alcuni dei post menzionati sull'esclusione di SSL dal codice client. Ma non sono assolutamente d'accordo.

Ho appena trascinato il certificato nella cartella "Autorità di certificazione radice attendibili" e voilà tutto ha funzionato bene.

Oh. E ho prima aggiunto quanto segue da un prompt dei comandi dell'amministratore:

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

Non sono sicuro del nome che ti serve per l'utente (il mio è norvegese come puoi vedere!) user=NT-AUTHORITY/INTERACTIVE:?

Puoi vedere tutti gli urlacl esistenti emettendo il comando: netsh http show urlacl

Ciò si è verificato durante il tentativo di connessione al servizio WCF tramite. l'IP, ad esempio https://111.11.111.1:port/MyService.svcdurante l'utilizzo di un certificato associato a un nome, ad esempio mysite.com.

Passando al https://mysite.com:port/MyService.svcrisolto.

Ciò si è verificato durante il tentativo di connessione al servizio WCF utilizzando solo il nome host, ad es . Https: //host/MyService.svc durante l'utilizzo di un certificato associato a un nome, ad esempio host.mysite.com.

Passando a https://host.mysite.com/MyService.svc e questo è stato risolto.

Ho appena risolto un problema simile.

Mi sono reso conto di disporre di un pool di applicazioni in esecuzione con un account che aveva solo l'autorizzazione di lettura sul certificato utilizzato.

L'applicazione .NET è stata in grado di recuperare correttamente il certificato ma quell'eccezione è stata generata solo quando è stato chiamato GetRequestStream ().

Le autorizzazioni per i certificati possono essere gestite tramite la console MMC

Se si utilizza .net core, durante lo sviluppo è possibile ignorare la convalida del certificato utilizzando le direttive del compilatore. In questo modo convaliderà solo il certificato per il rilascio e non per il debug:

#if (DEBUG)
        client.ClientCredentials.ServiceCertificate.SslCertificateAuthentication =
                new X509ServiceCertificateAuthentication()
                {
                    CertificateValidationMode = X509CertificateValidationMode.None,
                    RevocationMode = System.Security.Cryptography.X509Certificates.X509RevocationMode.NoCheck
                };   #endif

Aggiungi questo al tuo codice cliente:

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