Что может вызвать ошибку System.Net: сбой AcquireCredentialsHandle () с ошибкой 0X8009030D? - PullRequest
Новая
       69

Что может вызвать ошибку System.Net: сбой AcquireCredentialsHandle () с ошибкой 0X8009030D?

0 голосов
/ 24 мая 2018

У меня есть простой кусок кода соединения https, который хорошо работает с одним хостом ssl, подключаясь, даже если корневому центру сертификации не доверяют (это среда песочницы, поэтому мы не беспокоимся о дыре в безопасности, которую это создает, длясейчас) и загружая сертификат и ключ из текстовых файлов, используя пакет Nuget OpenSSL.X509Certificate2Provider: 

    public async Task<string> Register()
    {
        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
        ServicePointManager.ServerCertificateValidationCallback = (sender, cert, chain, sslPolicyErrors) => true;

        using (var handler = new HttpClientHandler())
        {
            var rawcert = File.ReadAllText(@"C:\OpenSSL\bin\certTransport.pem");
            var rawkey = File.ReadAllText(@"C:\OpenSSL\bin\privateKeyTransport.key");

            var provider = new CertificateFromFileProvider(rawcert, rawkey);
            var cert = provider.Certificate;
            handler.ClientCertificateOptions = ClientCertificateOption.Manual;
            handler.ServerCertificateCustomValidationCallback +=
                (HttpRequestMessage req, X509Certificate2 cert2, X509Chain chain, SslPolicyErrors err) =>
                {
                    return true;
                };

            handler.ClientCertificates.Add(cert);

            using (var client = new HttpClient(handler))
            {
                client.BaseAddress = new Uri("https://{uri}/");
                var response = await client.GetStringAsync("register");
                return response;
            }
        }
    }

Когда я указываю этот код на другой хост, который должен быть защищен точно таким же образом, яполучаю следующую ошибку: System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.

И, копаясь в журналах, я обнаруживаю: System.Net Information: 0 : [35036] AcquireCredentialsHandle(package = Microsoft Unified Security Protocol Provider, intent = Outbound, scc = System.Net.SecureCredential) System.Net Error: 0 : [35036] AcquireCredentialsHandle() failed with error 0X8009030D.

При поиске в стеке я нахожу много ошибок, связанных с разрешениями хранилища сертификатов, но клиентсертификат в этом случае не загружается из хранилища.

Я также нахожу много проблем, связанных с SecurityProtocolType.Я проверил, что сервер использует Tls1.2 (только).

Я вызываю код из модульного теста в VS 2017 Enterprise, работающего с правами администратора на Win10 x64.Код содержится в библиотеке классов .Net 4.7, а не в IIS.

Что может быть причиной этой проблемы?

ОБНОВЛЕНИЕ После полезных комментариев @Jeroen Mostert нижеЯ попробовал базовый тест соединения с OpenSSL.Немного анонимные результаты: 

OpenSSL> s_client -connect {REMOVED}:443 -CAfile C:\OpenSSL\bin\archive-ii\transport-production-new\certTransport.pem
CONNECTED(000001F0)
depth=2 C = GB, O = OK, CN = {REMOVED} Root CA
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
0 s:/C=GB/O={REMOVED}/OU={REMOVED}/CN={REMOVED}
i:/C=GB/O={REMOVED}/CN={REMOVED} Issuing CA
1 s:/C=GB/O={REMOVED}/CN={REMOVED} Issuing CA
i:/C=GB/O={REMOVED}/CN={REMOVED} Root CA
2 s:/C=GB/O={REMOVED}/CN={REMOVED} Root CA
i:/C=GB/O={REMOVED}/CN={REMOVED} Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
{REMOVED}
-----END CERTIFICATE-----
subject=/C=GB/O={REMOVED}/OU={REMOVED}/CN={REMOVED}
issuer=/C=GB/O={REMOVED}/CN={REMOVED} Issuing CA
---
Acceptable client certificate CA names
/C=GB/O={REMOVED}/CN={REMOVED} Issuing CA
/C=GB/O={REMOVED}/CN={REMOVED} Root CA
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms:     RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5155 bytes and written 446 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID:
    Session-ID-ctx:
    Master-Key: {REMOVED}
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1527164830
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

Есть ли что-нибудь не так?

Я также посмотрел в журнале CAPI2 (как это предлагается в комментариях).Это показывает ошибки, связанные с тем, что корневой сертификат не является доверенным, например: enter image description here

Означает ли это, что мои обратные вызовы проверки не работают - и если да, то есть идеи, почему это будетбыть?

Дальнейшее обновление:

Если я удалю строку кода, которая прикрепляет сертификат, то ошибка исчезнет - я доберусь до конечной точки теста MTLS (но, конечно, провалите тест MTLS, который там проводится).

Что это говорит?Проблема с самим сертификатом?

1 Ответ

0 голосов
/ 28 июня 2018

В конце концов, проблема заключалась в выводе метода CertificateFromFileProvider пакета OpenSSL.X509Certificate2Provider NuGet.

По какой-то причине созданный сертификат не будет работать правильно.Взяв те же входные файлы и сгенерировав .pfx с OpenSSL , мы получили X509Certificate2, который работал нормально.

...