Cách giải quyết không thể thiết lập mối quan hệ tin cậy cho kênh bảo mật SSL / TLS với quyền hạn

Thực sự nghĩ rằng tôi đã khắc phục vấn đề này, nhưng nó chỉ được ngụy trang trước đó.

Tôi có dịch vụ WCF được lưu trữ trong IIS 7 bằng HTTPS. Khi tôi duyệt đến trang web này trong Internet Explorer, nó hoạt động như một bùa mê, điều này là do tôi đã thêm chứng chỉ vào cửa hàng ủy quyền chứng chỉ gốc cục bộ.

Tôi đang phát triển trên 1 máy, vì vậy máy khách và máy chủ là cùng một máy. Chứng chỉ được tự ký trực tiếp từ quản lý IIS 7.

Tôi liên tục nhận được lỗi này bây giờ ...

Không thể thiết lập mối quan hệ tin cậy cho kênh bảo mật SSL / TLS có thẩm quyền.

... khi được gọi từ bảng điều khiển máy khách.

Tôi tự cấp cho mình quyền và dịch vụ mạng cho chứng chỉ, sử dụng findprivatekeyvà sử dụngcacls.exe .

Tôi đã cố gắng kết nối với dịch vụ bằng SOAPUI và nó hoạt động, vì vậy nó phải là một vấn đề trong ứng dụng khách của tôi, đó là mã dựa trên những gì được sử dụng để làm việc với http.

Nơi nào khác tôi có thể nhìn tôi dường như đã cạn kiệt tất cả các khả năng về lý do tại sao tôi không thể kết nối?

Là một workaround bạn có thể thêm một handler cho sự ServicePointManager's ServerCertificateValidationCallbacktrên các mặt hàng:

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

nhưng lưu ý rằng đây không phải là một thông lệ tốt vì nó hoàn toàn bỏ qua chứng chỉ máy chủ và nói với người quản lý điểm dịch vụ rằng bất kỳ chứng chỉ nào đều ổn có thể ảnh hưởng nghiêm trọng đến bảo mật của khách hàng. Bạn có thể tinh chỉnh điều này và thực hiện một số kiểm tra tùy chỉnh (đối với tên chứng chỉ, hàm băm, v.v.). ít nhất bạn có thể tránh được các vấn đề trong quá trình phát triển khi sử dụng chứng chỉ kiểm tra.

Khi tôi gặp vấn đề này là do client.config có các điểm cuối như:

 https://myserver/myservice.svc 

nhưng chứng chỉ đã được mong đợi

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

Thay đổi điểm cuối để phù hợp với FQDN của máy chủ sẽ giải quyết vấn đề của tôi. Tôi biết đây không phải là nguyên nhân duy nhất của vấn đề này.

hai cái đầu tiên sử dụng lambda, cái thứ ba sử dụng mã thông thường ... hy vọng bạn thấy nó hữu ích

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

Vấn đề của bạn phát sinh do bạn đang sử dụng khóa tự ký. Khách hàng không tin tưởng khóa này, bản thân khóa cũng không cung cấp chuỗi để xác thực hoặc danh sách hủy bỏ chứng chỉ.

Bạn có một vài lựa chọn - bạn có thể

1. tắt xác nhận chứng chỉ trên máy khách (di chuyển xấu, người đàn ông ở giữa tấn công rất nhiều)

2. sử dụng makecert để tạo CA gốc và tạo chứng chỉ từ đó (di chuyển ok, nhưng vẫn không có CRL)

3. tạo một CA gốc nội bộ bằng Windows Chứng chỉ máy chủ hoặc giải pháp PKI khác sau đó tin tưởng chứng chỉ gốc đó (một chút khó khăn để quản lý)

4. mua chứng chỉ SSL từ một trong những CA đáng tin cậy (đắt tiền)

Một giải pháp một dòng. Thêm phần này vào bất cứ đâu trước khi gọi máy chủ ở phía máy khách:

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

Điều này chỉ nên được sử dụng cho mục đích thử nghiệm vì khách hàng sẽ bỏ qua kiểm tra bảo mật SSL / TLS.

Tôi gặp phải cùng một vấn đề và tôi đã có thể giải quyết bằng hai giải pháp: Thứ nhất, tôi đã sử dụng "Chứng chỉ" đính kèm MMC cho "Tài khoản máy tính" và kéo chứng chỉ tự ký vào thư mục "Cơ quan chứng nhận gốc đáng tin cậy" . Điều này có nghĩa là máy tính cục bộ (máy tính đã tạo chứng chỉ) giờ sẽ tin tưởng chứng chỉ đó. Thứ hai, tôi nhận thấy rằng chứng chỉ được tạo cho một số tên máy tính nội bộ, nhưng dịch vụ web đã được truy cập bằng tên khác. Điều này gây ra sự không phù hợp khi xác nhận giấy chứng nhận. Chúng tôi đã tạo chứng chỉ cho computer.operations.local, nhưng đã truy cập dịch vụ web bằng cách sử dụng https://computer.i INTERNaldomain.companydomain.com . Khi chúng tôi chuyển URL sang một được sử dụng để tạo chứng chỉ, chúng tôi không gặp phải lỗi nào nữa.

Có thể chỉ cần chuyển đổi URL sẽ có hiệu quả, nhưng bằng cách làm cho chứng chỉ được tin cậy, bạn cũng tránh được màn hình màu đỏ trong Internet Explorer, nơi nó cho bạn biết rằng nó không tin tưởng vào chứng chỉ.

Nếu bạn sử dụng lõi .net, hãy thử điều này:

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

Vui lòng thực hiện các bước sau:

1. Mở liên kết dịch vụ trong IE.

2. Nhấp vào đề cập lỗi chứng chỉ trong thanh địa chỉ và nhấp vào Xem chứng chỉ.

3. Kiểm tra phát hành cho: tên.

4. Lấy tên đã ban hành và thay thế đề cập localhost trong dịch vụ và tên địa chỉ cơ sở điểm cuối của khách hàng bằng một tên miền đủ điều kiện (FQDN).

Ví dụ: https: // localhost : 203 / SampleService.svc Đến https: // INL-126166-.groupinfra.com : 203 / SampleService.svc

Ngoài các câu trả lời ở trên, bạn có thể gặp phải lỗi này nếu máy khách của bạn đang chạy phiên bản TLS sai, ví dụ nếu máy chủ chỉ chạy TLS 1.2.

Bạn có thể sửa nó bằng cách sử dụng:

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

Tôi đã từng gặp vấn đề tương tự. Tôi cũng đã thêm chứng chỉ CA trong cửa hàng địa phương, nhưng tôi đã làm theo cách SAU.

Sử dụng Bảng điều khiển mmc (Bắt đầu -> Chạy -> mmc ), bạn nên thêm Chứng chỉ kèm làm tài khoản Dịch vụ (chọn tài khoản dịch vụ của IIS) hoặc Tài khoản máy tính (nó bổ sung cho mọi tài khoản trên máy)

Đây là hình ảnh của những gì tôi đang nói về

Từ đây, bạn có thể thêm chứng chỉ CA ( CA gốc đáng tin cậy và CA trung gian ) và mọi thứ sẽ hoạt động tốt

Tôi đã có vấn đề tương tự với giấy chứng nhận tự ký. Tôi có thể giải quyết nó bằng cách sử dụng tên chứng chỉ giống như FQDN của máy chủ.

Lý tưởng nhất, phần SSL nên được quản lý ở phía máy chủ. Khách hàng không bắt buộc phải cài đặt bất kỳ chứng chỉ nào cho SSL. Ngoài ra, một số bài viết được đề cập về việc bỏ qua SSL từ mã máy khách. Nhưng tôi hoàn toàn không đồng ý với điều đó.

Tôi chỉ cần kéo chứng chỉ vào thư mục "Cơ quan chứng nhận gốc đáng tin cậy" và mọi thứ đều hoạt động tốt.

Oh. Và lần đầu tiên tôi đã thêm những điều sau đây từ Dấu nhắc của Quản trị viên:

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

Tôi không chắc chắn về tên bạn cần cho người dùng (tên của tôi là tiếng Na Uy như bạn có thể thấy!) : user=NT-AUTHORITY/INTERACTIVE?

Bạn có thể thấy tất cả các urlacl hiện có bằng cách ban hành lệnh: netsh http show urlacl

Điều này xảy ra khi cố gắng kết nối với Dịch vụ WCF thông qua. IP, ví dụ như https://111.11.111.1:port/MyService.svctrong khi sử dụng chứng chỉ gắn với tên, ví dụ mysite.com.

Chuyển sang https://mysite.com:port/MyService.svcgiải quyết nó.

Điều này xảy ra khi cố gắng kết nối với Dịch vụ WCF chỉ bằng tên máy chủ, ví dụ: https: //host/MyService.svc trong khi sử dụng chứng chỉ gắn với tên, ví dụ: host.mysite.com.

Chuyển sang https://host.mysite.com/MyService.svc và điều này đã giải quyết nó.

Chỉ cần sửa một vấn đề tương tự.

Tôi nhận ra rằng tôi có một nhóm ứng dụng đang chạy trong một tài khoản chỉ có quyền đọc đối với chứng chỉ mà nó được sử dụng.

Ứng dụng .NET có thể truy xuất chính xác chứng chỉ nhưng ngoại lệ đó chỉ được ném khi GetRequestStream () được gọi.

Quyền chứng chỉ có thể được quản lý thông qua bảng điều khiển MMC

Nếu bạn đang sử dụng lõi .net, thì trong quá trình phát triển, bạn có thể bỏ qua xác thực chứng chỉ bằng cách sử dụng các chỉ thị của trình biên dịch. Cách này sẽ chỉ xác nhận chứng chỉ để phát hành chứ không phải để gỡ lỗi:

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

Thêm mã này vào mã máy khách của bạn:

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