“Yetkili SSL / TLS güvenli kanalı için güven ilişkisi kurulamadı” nasıl çözülür?

Gerçekten bu sorunu çözdüğümü düşündüm, ama sadece daha önce gizlenmişti.

HTTPS kullanarak IIS 7'de barındırılan bir WCF hizmetim var. Internet Explorer'da bu siteye göz atarken, ben bunun nedeni, bir cazibe gibi çalışır gelmiş yerel kök sertifika yetkilisi deposuna sertifika ekledi.

1 makinede geliştiriyorum, bu yüzden istemci ve sunucu aynı makinedir. Sertifika doğrudan IIS 7 yönetim ek bileşeninden otomatik olarak imzalanır.

Sürekli olarak bu hatayı alıyorum ...

Yetkili SSL / TLS güvenli kanalı için güven ilişkisi kurulamadı.

... istemci konsolundan çağrıldığında.

Kullanarak findprivatekeyve kullanarak sertifikaya kendim izinler ve ağ hizmeti verdim cacls.exe.

SOAPUI kullanarak hizmete bağlanmaya çalıştım ve işe yarıyor, bu yüzden http ile çalışmak için kullanılan ne dayalı kod olan istemci uygulamamda bir sorun olmalı.

Başka nereye bakabilirim, neden bağlanamadığım için tüm olasılıkları tükettiğimi düşünüyorum?

Çözüm olarak, istemci tarafındaki ServicePointManager' lere bir işleyici ekleyebilirsiniz ServerCertificateValidationCallback:

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

ancak sunucu sertifikasını tamamen göz ardı ettiği ve hizmet noktası yöneticisine, sertifikanın iyi olduğu ve istemci güvenliğini ciddi şekilde tehlikeye atabileceğini söylediği için bunun iyi bir uygulama olmadığını unutmayın . Bunu hassaslaştırabilir ve bazı özel kontroller yapabilirsiniz (sertifika adı, karma vb. İçin). en azından test sertifikalarını kullanırken geliştirme sırasında sorunları aşabilirsiniz.

Bu sorun olduğunda, client.config gibi uç noktaları vardı çünkü:

 https://myserver/myservice.svc 

ama sertifika bekliyordum

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

Bitiş noktalarını sunucunun FQDN'sine uyacak şekilde değiştirmek sorunumu çözer. Bu sorunun tek nedeni olmadığını biliyorum.

ilk iki lambda, üçüncüsü normal kod kullanır ... umarım faydalı bulursun

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

Sorununuz, kendinden imzalı bir anahtar kullandığınız için ortaya çıkar. İstemci bu anahtara güvenmez ve anahtarın kendisi doğrulama için bir zincir veya sertifika iptal listesi sağlamaz.

Birkaç seçeneğiniz var - şunları yapabilirsiniz

1. istemcide sertifika doğrulamayı kapat (kötü hamle, orta saldırılarda adam var)

2. kök CA oluşturmak ve bundan sertifika oluşturmak için makecert kullanın (tamam taşıyın, ancak hala CRL yok)

3. Windows Sertifika Sunucusu'nu veya başka bir PKI çözümünü kullanarak bir iç kök CA oluşturun ve ardından bu kök sertifikaya güvenin (yönetmek için biraz acı)

4. güvenilir CA'lardan birinden SSL sertifikası satın alın (pahalı)

Tek satırlık bir çözüm. İstemci tarafında sunucuyu aramadan önce bunu herhangi bir yere ekleyin:

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

İstemci SSL / TLS güvenlik denetimlerini atlayacağından bu yalnızca sınama amacıyla kullanılmalıdır.

Aynı sorunla karşılaştım ve iki çözümle çözebildim: İlk olarak, "Bilgisayar hesabı" için MMC ek bileşeni "Sertifikalar" ı kullandım ve kendinden imzalı sertifikayı "Güvenilen Kök Sertifika Yetkilileri" klasörüne sürükledim . Bu, yerel bilgisayarın (sertifikayı oluşturan bilgisayar) artık bu sertifikaya güveneceği anlamına gelir. İkinci olarak, sertifikanın bazı dahili bilgisayar adı için oluşturulduğunu fark ettim, ancak web hizmetine başka bir ad kullanılarak erişildiğini fark ettim. Bu, sertifikayı doğrularken uyumsuzluğa neden oldu. Computer.operations.local için sertifika oluşturduk, ancak web servisine https://computer.internaldomain.companydomain.com adresini kullanarak eriştik . URL'yi sertifikayı oluşturmak için kullandığımız URL'ye geçirdiğimizde başka hatayla karşılaşmadık.

Belki sadece URL'leri değiştirmek işe yarardı, ancak sertifikayı güvenilir hale getirerek Internet Explorer'da sertifikanın güvenmediğini belirten kırmızı ekrandan da kaçınabilirsiniz.

.Net core kullanıyorsanız bunu deneyin:

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

Lütfen aşağıdaki adımları uygulayın:

1. IE'de hizmet bağlantısını açın.

2. Adres çubuğundaki sertifika hatası sözünü tıklayın ve Sertifikaları görüntüle'yi tıklayın.

3. Çek verilen ad:.

4. Verilen adı alın ve hizmet ve istemci uç noktası temel adres adındaki localhost sözünü tam etki alanı adı (FQDN) ile değiştirin.

Örneğin: https: // localhost : 203 / SampleService.svc https: // INL-126166-.groupinfra.com : 203 / SampleService.svc

Yukarıdaki yanıtlara ek olarak, istemciniz yanlış TLS sürümünü çalıştırıyorsa, örneğin sunucu yalnızca TLS 1.2 çalıştırıyorsa bu hatayla karşılaşabilirsiniz.

Şunları kullanarak düzeltebilirsiniz:

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

Ben de aynı problemi yaşadım. Ayrıca yerel mağazaya CA sertifikaları ekledim, ancak YANLIŞ şekilde yaptım.

Mmc Konsolu'nu (Başlat -> Çalıştır -> mmc ) kullanarak Sertifikalar ek bileşenini Hizmet hesabı (IIS'nin hizmet hesabını seçerek) veya Bilgisayar hesabı (makinedeki her hesap için ekler) olarak eklemeniz gerekir.

İşte neden bahsettiğimin bir resmi

Şimdi buradan CA sertifikaları ( Güvenilir Kök CA'lar ve Ara CA'lar ) ekleyebilirsiniz ve her şey düzgün çalışır

Kendinden imzalı sertifika ile benzer bir sorun yaşadım. Sunucunun FQDN'si ile aynı sertifika adını kullanarak çözebilirim.

İdeal olarak, SSL kısmı sunucu tarafında yönetilmelidir. İstemcinin SSL için herhangi bir sertifika yüklemesine gerek yoktur. Ayrıca, SSL'nin istemci kodundan atlanmasıyla ilgili bazı yayınlar. Ama buna kesinlikle katılmıyorum.

Sertifikayı "Güvenilen Kök Sertifika Yetkilileri" klasörüne sürükledim ve her şey güzel çalıştı.

Ah. Ve önce bir Yönetici Komut İstemi'nden aşağıdakileri ekledim:

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

Ben emin kullanıcı için ihtiyaç ismin görebilir (gördüğünüz gibi benim Norveç değildir!): user=NT-AUTHORITY/INTERACTIVE?

Komutu vererek mevcut tüm urlacl'leri görebilirsiniz: netsh http show urlacl

Bu, üzerinden WCF Hizmetine bağlanmaya çalışırken meydana geldi. IP, örneğin https://111.11.111.1:port/MyService.svcbir siteye bağlı bir sertifika kullanırken, örneğin mysite.com.

Çözüldü https://mysite.com:port/MyService.svc.

Bu, WCF Hizmetine yalnızca anasistem adı kullanılarak örneğin https: //host/MyService.svc kullanarak bağlanmaya çalışırken, örn.

Https://host.mysite.com/MyService.svc adresine geçerek bu sorunu çözdü.

Benzer bir sorunu düzelttik.

Yalnızca kullanılan sertifika üzerinde okuma izni olan bir hesap altında çalışan bir uygulama havuzum olduğunu fark ettim.

.NET uygulaması sertifikayı doğru şekilde alabilir, ancak bu kural dışı durum yalnızca GetRequestStream () çağrıldığında atılır.

Sertifika izinleri MMC konsolu üzerinden yönetilebilir

.Net core kullanıyorsanız, geliştirme sırasında derleyici yönergelerini kullanarak sertifika doğrulamasını atlayabilirsiniz. Bu şekilde, hata ayıklama için değil, yalnızca sürüm için sertifika doğrulanır:

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

Bunu müşteri kodunuza ekleyin:

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