Could not create ssl tls secure channel windows 7

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

26

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

5

ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
       | SecurityProtocolType.Tls11
       | SecurityProtocolType.Tls12
       | SecurityProtocolType.Ssl3;

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
       | SecurityProtocolType.Tls11
       | SecurityProtocolType.Tls12
       | SecurityProtocolType.Ssl3;

8

<httpRuntime targetFramework="4.5" />

<httpRuntime targetFramework="4.7" />

6

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");

3

3

3

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

5

3

ServicePointManager.Expect100Continue = true;
        ServicePointManager.DefaultConnectionLimit = 9999;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

5

1

public string DownloadSite(string RefinedLink)
{
    try
    {
        Uri address = new Uri(RefinedLink);

        ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

        System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

        using (WebClient webClient = new WebClient())
        {
            var stream = webClient.OpenRead(address);
            using (StreamReader sr = new StreamReader(stream))
            {
                var page = sr.ReadToEnd();

                return page;
            }
        }

    }
    catch (Exception e)
    {
        log.Error("DownloadSite - error Lin = " + RefinedLink, e);
        return null;
    }
}

3

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

1

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

0

1

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

0

<httpRuntime targetFramework="4.5.2" />

<httpRuntime targetFramework="4.6.1" />

1

1

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...

1

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

1

1

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

3

2

4

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss

1

   var certificate = new X509Certificate2(bytes, pass);

   var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);

// I'm not even sure the first two lines are necessary:
ServicePointManager.Expect100Continue = true; 
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

request = (HttpWebRequest)WebRequest.Create(string.Format("https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", server));
request.Method = "GET";
request.Referer = string.Format("https://hercules.sii.cl/cgi_AUT2000/autInicio.cgi?referencia=https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", servidor);
request.UserAgent = "Mozilla/4.0";
request.ClientCertificates.Add(certificate);
request.CookieContainer = new CookieContainer();

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
    // etc...
}

2

1

Оглавление

• Проблема
• Windows 7 и Windows 2008 R2
• Windows RT 8.1, Windows 8.1, Windows Server 2012 R2
• Windows 2008 (не путать с R2)
• Другая ОС
• Проблема с корневыми сертификатами в ОС

Мы не можем подключиться к серверу HTTPS с помощью WebRequest из-за этого сообщения об ошибке:

The request was aborted: Could not create SSL/TLS secure channel.

Мы знаем, что сервер не имеет действительного сертификата HTTPS с указанным путем, но чтобы обойти эту проблему, мы используем следующий код, который мы взяли из другого сообщения StackOverflow:

private void Somewhere() {
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
}

private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) {
return true;
}

Проблема в том, что сервер никогда не проверяет сертификат и не выполняет вышеуказанную ошибку. Кто-нибудь знает, что мне делать?

Я должен упомянуть, что несколько лет назад мы с коллегой проводили тесты, и он отлично работал с чем-то похожим на то, что я написал выше. Единственное “основное отличие”, которое мы обнаружили, это то, что я использую Windows 7, и он использовал Windows XP. Это что-то меняет?

Я, наконец, нашел ответ (я не заметил свой источник, но это был поиск);

Хотя код работает в Windows XP, в Windows 7, вы должны добавить это в начале:

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

И теперь он работает отлично.

ДОПОЛНЕНИЕ

Как упоминал Робин Франс; если вы получаете эту проблему при настройке PayPal, обратите внимание, что они не будут поддерживать SSL3, начиная с 3 декабря 2018 года. Вам нужно будет использовать TLS. Здесь страница Paypal об этом.

Решение этого в.NET 4.5 является

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Если у вас нет.NET 4.5, используйте

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Убедитесь, что настройки ServicePointManager заданы до создания HttpWebRequest, иначе он не будет работать.

Работает:

        ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
| SecurityProtocolType.Tls11
| SecurityProtocolType.Tls12
| SecurityProtocolType.Ssl3;

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

Сбой:

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
| SecurityProtocolType.Tls11
| SecurityProtocolType.Tls12
| SecurityProtocolType.Ssl3;

Ошибка является общей и существует много причин, по которым переговоры SSL/TLS могут завершиться неудачей. Наиболее распространенным является недействительный или устаревший сертификат сервера, и вы позаботились об этом, предоставив свой собственный сертификат проверки подлинности сертификата сервера, но это не обязательно единственная причина. Сервер может требовать взаимной аутентификации, он может быть настроен с наборами шифров, не поддерживаемых вашим клиентом, у него может быть слишком большой дрейф времени, чтобы рукопожатие преуспело и еще много причин.

Лучшим решением является использование набора инструментов устранения неполадок SChannel. SChannel – поставщик SSPI, ответственный за SSL и TLS, и ваш клиент будет использовать его для рукопожатия. Посмотрите TLS/SSL-инструменты и настройки.

Также см. Как включить ведение журнала событий Schannel.

У меня была эта проблема с попыткой нажать https://ct.mob0.com/Styles/Fun.png, который представляет собой изображение, распространяемое CloudFlare на нем CDN, которое поддерживает сумасшедшие вещи, такие как SPDY и странные перенаправления сертификатов SSL.

Вместо того, чтобы указывать Ssl3, как в ответе Саймонса, я смог исправить его, перейдя к Tls12 следующим образом:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");

После долгих часов с этой же проблемой я обнаружил, что учетная запись ASP.NET, на которой работает клиентская служба, не имела доступа к сертификату. Я исправил его, перейдя в пул приложений IIS, с которым работает веб-приложение, перейдя в “Дополнительные настройки” и изменив идентификатор на LocalSystem с NetworkService.

Лучшим решением является получение сертификата, работающего с учетной записью по умолчанию NetworkService, но это работает для быстрого функционального тестирования.

Что-то, чего не было в первоначальном ответе. Я добавил еще один код, чтобы сделать его пуленепробиваемым.

ServicePointManager.Expect100Continue = true;
ServicePointManager.DefaultConnectionLimit = 9999;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

Другая возможность – это неправильный импорт сертификата в поле. Обязательно установите флажок в окружении. Первоначально я этого не делал, поэтому код либо выходил из строя, либо выдавал такое же исключение, что и закрытый ключ.

“Запрос был прерван: не удалось создать безопасный канал SSL/TLS”. Исключение может возникнуть, если сервер возвращает ответ HTTP <4 > Неавторизованный запрос HTTP.

Вы можете определить, происходит ли это, включив ведение журнала System.Net на уровне трассировки для вашего клиентского приложения, как описано в этом ответе.

Как только эта конфигурация регистрации будет на месте, запустите приложение и воспроизведите ошибку, а затем посмотрите в выводе журнала для такой строки:

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

В моей ситуации я не смог установить конкретный файл cookie, ожидаемый сервером, что привело к тому, что сервер ответил на запрос с ошибкой 401, что в свою очередь привело к созданию “Не удалось создать безопасный канал SSL/TLS”, исключение.

Корень этого исключения в моем случае состоял в том, что в какой-то момент кода вызывалось следующее:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Это действительно плохо. Он не только инструктирует .NET использовать небезопасный протокол, но это влияет на каждый новый запрос WebClient (и аналогичный), сделанный впоследствии в вашем приложении. (Обратите внимание, что входящие веб-запросы не затрагиваются в вашем приложении ASP.NET, но новые запросы WebClient, например, для общения с внешней веб-службой).

В моем случае это было фактически не нужно, поэтому я мог просто удалить инструкцию, и все мои другие веб-запросы снова начали работать отлично. Основываясь на моем чтении в другом месте, я узнал несколько вещей:

• Это глобальная настройка в вашем приложении, и если у вас есть одновременная деятельность, вы не можете надежно установить ее на одно значение, выполнить свое действие и затем установить его обратно. Другое действие может иметь место во время этого маленького окна и быть затронутым.
• Правильная настройка – оставить ее по умолчанию. Это позволяет .NET продолжать использовать все, что является самым безопасным значением по умолчанию, с течением времени и обновлять фреймворки. Установка его в TLS12 (который является самым безопасным на момент написания этой статьи) будет работать сейчас, но через 5 лет может возникнуть таинственные проблемы.
• Если вам действительно нужно установить значение, вы должны подумать об этом в отдельном специализированном приложении или приложении домена и найти способ поговорить между ним и вашим основным пулом. Поскольку это единственное глобальное значение, попытка управлять им в пределах загруженного пула приложений приведет только к неприятностям. Этот ответ: qaru.site/questions/45920/… предоставляет возможное решение с помощью специального прокси. (Примечание. Я лично не реализовал его.)

Как вы можете сказать, есть много причин, которые могут произойти. Думаю, я бы добавил причину, с которой я столкнулся…

Если вы установите значение WebRequest.Timeout на 0, это будет исключение. Ниже приведен код, который у меня был… (За исключением жестко закодированного 0 для значения таймаута у меня был параметр, который был непреднамеренно установлен на 0).

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...

Этот работает для меня в веб-клиенте MVC

    public string DownloadSite(string RefinedLink)
{
try
{
Uri address = new Uri(RefinedLink);

ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

using (WebClient webClient = new WebClient())
{
var stream = webClient.OpenRead(address);
using (StreamReader sr = new StreamReader(stream))
{
var page = sr.ReadToEnd();

return page;
}
}

}
catch (Exception e)
{
log.Error("DownloadSite - error Lin = " + RefinedLink, e);
return null;
}
}

Другая возможная причина The request was aborted: Could not create SSL/TLS secure channel ошибку The request was aborted: Could not create SSL/TLS secure channel – это несоответствие между вашими значениями cipher_suites вашего клиентского ПК и значениями, которые сервер настроил как желающий и способный принять. В этом случае, когда ваш клиент отправляет список значений cipher_suites, которые он может принять в своем первоначальном сообщении об установлении связи/согласовании SSL “Клиент Hello”, сервер видит, что ни одно из предоставленных значений не является приемлемым и может возвращать “Предупреждение” “вместо того, чтобы перейти к шагу” Приветствие Сервера “SSL-квитирования.

Чтобы изучить эту возможность, вы можете загрузить Microsoft Message Analyzer и использовать его для запуска трассировки в согласовании SSL, возникающего при попытке установить HTTPS-соединение с сервером (в вашем приложении С#).

Если вы можете сделать успешное соединение HTTPS из другой среды (например, упомянутой вами машины Windows XP, или, возможно, нажав URL-адрес HTTPS в браузере, отличном от Microsoft, который не использует настройки набора шифров ОС, например Chrome или Firefox), запустите еще одну трассировку анализатора сообщений в этой среде, чтобы зафиксировать, что происходит, когда переговоры по SSL успешно завершены.

Надеемся, вы увидите некоторую разницу между двумя сообщениями Hello Hello, которые позволят вам точно определить, что из-за неудачного согласования SSL приводит к сбою. Затем вы сможете внести изменения в конфигурацию Windows, что позволит ей добиться успеха. IISCrypto – отличный инструмент для этого (даже для клиентских компьютеров, несмотря на имя “IIS”).

Следующие два ключа реестра Windows управляют значениями cipher_suites, которые ваш компьютер будет использовать:

• HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002
• HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

Здесь полная запись того, как я исследовал и решил экземпляр этого многообразия. Could not create SSL/TLS secure channel проблему Could not create SSL/TLS secure channel: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in -windows.html

У меня была эта проблема, потому что у моего web.config было:

<httpRuntime targetFramework="4.5.2" />

и не:

<httpRuntime targetFramework="4.6.1" />

Я боролся с этой проблемой весь день.

Когда я создал новый проект с .NET 4.5, я, наконец, получил его для работы.

Но если я понизил до 4.0, я снова получил ту же проблему, и это было необратимо для этого проекта (даже когда я снова попытался обновить до 4.5).

Странное другое сообщение об ошибке, но “Запрос был прерван: не удалось создать безопасный канал SSL/TLS”. придумал эту ошибку

В случае, если клиент является машиной Windows, возможной причиной может быть то, что протокол tls или ssl, требуемый службой, не активирован.

Это можно установить в:

Панель управления → Сеть и Интернет → Свойства обозревателя → Дополнительно

Прокрутите настройки до “Безопасность” и выберите между

• Использовать SSL 2.0
• Использовать SSL 3.0
• Использовать TLS 1.0
• Использовать TLS 1.1
• Использовать TLS 1.2

В моем случае учетная запись службы, запускающая приложение, не имела права доступа к закрытому ключу. Как только я дал это разрешение, ошибка исчезла.

• ММС
• сертификаты
• Развернуть до личного
• выберите cert
• щелкните правой кнопкой мыши
• Все задачи
• Управление секретными ключами
• Добавить

У меня была такая же проблема, и я нашел, что этот ответ работал правильно для меня. Ключ – 3072. Эта ссылка содержит сведения об исправлении 3072.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

В моем случае два канала потребовали исправления:

https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss

System.Net.WebException: запрос был прерван: не удалось создать безопасный канал SSL/TLS.

В нашем случае мы используем поставщика программного обеспечения, поэтому у нас не было доступа для изменения кода.NET. По-видимому,.NET 4 не будет использовать TLS v 1.2, если не будет изменений.

Исправление для нас заключалось в добавлении ключа SchUseStrongCrypto в реестр. Вы можете скопировать/вставить приведенный ниже код в текстовый файл с расширением.reg и выполнить его. Это послужило нашим “патчем” к проблеме.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Попробуй это:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Ответа с наибольшим количеством голосов, вероятно, будет достаточно для большинства людей. Однако в некоторых случаях вы можете продолжить получать сообщение об ошибке “Не удалось создать безопасный канал SSL/TLS” даже после принудительного использования TLS 1.2. Если это так, вы можете обратиться к этой полезной статье за дополнительными шагами по устранению неполадок. Подводя итог: независимо от проблемы версии TLS/SSL, клиент и сервер должны договориться о “наборе шифров”. На этапе “рукопожатия” SSL-соединения клиент перечислит свои поддерживаемые комплекты шифров, которые сервер будет проверять по собственному списку. Но на некоторых компьютерах с Windows некоторые общие наборы шифров могут быть отключены (по-видимому, из-за благих намерений попыток ограничить поверхность атаки), уменьшая вероятность клиента & согласие сервера на набор шифров. Если они не могут согласиться, вы можете увидеть “код фатального оповещения 40” в средстве просмотра событий и “Не удалось создать безопасный канал SSL/TLS” в вашей .NET-программе.

В вышеупомянутой статье объясняется, как составить список всех потенциально поддерживаемых наборов шифров на компьютере и включить дополнительные наборы шифров через реестр Windows. Чтобы проверить, какие наборы шифров включены на клиенте, попробуйте посетить эту страницу диагностики в MSIE. (Использование трассировки System.Net может дать более точные результаты.) Чтобы проверить, какие наборы шифров поддерживаются сервером, попробуйте этот онлайн-инструмент (при условии, что сервер доступен через Интернет). Само собой разумеется, что изменения в реестре должны выполняться с осторожностью, особенно когда речь идет о работе в сети. (Является ли ваша машина виртуальной машиной с удаленным размещением? Если бы вы прервали работу сети, была бы она вообще доступна?)

В случае моей компании мы включили несколько дополнительных наборов “ECDHE_ECDSA” через редактирование реестра, чтобы исправить непосредственную проблему и защититься от будущих проблем. Но если вы не можете (или не хотите) редактировать реестр, то на ум приходят многочисленные обходные пути (не обязательно красивые). Например: ваша .NET-программа может делегировать свой SSL-трафик отдельной программе Python (которая может сама работать, по той же причине, по которой запросы Chrome могут выполняться успешно, когда запросы MSIE не выполняются на зараженной машине).

В моем случае у меня была эта проблема, когда служба Windows пыталась подключиться к веб-службе. В результате в Windows я обнаружил код ошибки.

Идентификатор события 36888 (Schannel) поднят:

The following fatal alert was generated: 40. The internal error state is 808.

Наконец, это связано с исправлением Windows. В моем случае: KB3172605 и KB3177186

Предлагаемое решение в форуме vmware – это добавить запись в Windows. После добавления следующего реестра все работает нормально.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Диффи-Хеллмана]

“ClientMinKeyBitLength” = DWORD: 00000200

По-видимому, это связано с отсутствующим значением в рукопожатии https на стороне клиента.

Список Windows HotFix:

wmic qfe list

Решение Тема:

https://communities.vmware.com/message/2604912#2604912

Надеюсь, что это поможет.

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

https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect

По сути, MS предполагает, что вам нужно более слабое шифрование, но ОС исправлена только для разрешения TLS 1.2, поэтому вы получаете страшное сообщение “Запрос был прерван: не удалось создать безопасный канал SSL/TLS”.

Есть три исправления.

1) Исправьте ОС с соответствующим обновлением: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) Добавьте настройку в файл app.config/web.config.

3) Добавьте параметр реестра, который уже упоминался в другом ответе.

Все они упомянуты в статье базы знаний, которую я разместил.

Ни один из ответов не сработал для меня.

Вот что сработало:

Вместо инициализации моего X509Certifiacte2 вот так:

   var certificate = new X509Certificate2(bytes, pass);

Я сделал это так:

   var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);

Обратите внимание на X509KeyStorageFlags.Exportable !!

Я не изменил остальную часть кода (сам WebRequest):

// I'm not even sure the first two lines are necessary:
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

request = (HttpWebRequest)WebRequest.Create(string.Format("https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", server));
request.Method = "GET";
request.Referer = string.Format("https://hercules.sii.cl/cgi_AUT2000/autInicio.cgi?referencia=https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", servidor);
request.UserAgent = "Mozilla/4.0";
request.ClientCertificates.Add(certificate);
request.CookieContainer = new CookieContainer();

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
// etc...
}

На самом деле я даже не уверен, что первые две строки необходимы…

Пока это относительно “живая” ссылка, я думал, что добавлю новый вариант. Эта возможность заключается в том, что служба больше не поддерживает SSL 3.0 из-за проблемы с атакой пуделя. Ознакомьтесь с инструкцией Google по этому вопросу. Я столкнулся с этой проблемой сразу с несколькими веб-службами и понял, что что-то должно было произойти. Я переключился на TLS 1.2, и все снова работает.

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

• Remove From My Forums

• Question

• On my new development machine (which is running Windows 7 Utlimate) I have a WCF web service running which requires a secure SSL/TLS connection.  When I try to connect to the web service using my own test client running on the same machine I am
  unable to estabish the connection.   The exact same test client and web service can successfully communicate on other development machines in the office running Vista or XP.  Additionally, I am also able to successfully establish
  a connection to my web service by typing the uri into IE8 running on my Windows 7 development machine (web service provides a REST interface).

  The connection requires a certificate on the client side.  To the best of my knowledge, the certificate has been installed correctly on my development computer and all the necessary permissions given.  Using mmc.exe, the following users have ‘Full
  Control’ — SYSTEM, NETWORK SERVICE, Administrators.

  The test client application receives the following exception while issuing HttpWebRequest.GetResponse() method:

  The request was aborted: Could not create SSL/TLS secure channel.

  Additionally in the event viewer, the following error can be found in the system log:

  A fatal error occurred when attempting to access the SSL client credential private key. The error code returned from the cryptographic module is 0x8009030d. The internal error state is 10003.

  The relevant code from the test client application is as follows:

  // Create the request
  HttpWebRequest request = (HttpWebRequest)WebRequest.Create(requestUri);
  
  // Get the certificate
  X509Store store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
  store.Open(OpenFlags.ReadOnly);
  
  X509Certificate2Collection certificates = store.Certificates.Find(X509FindType.FindBySubjectName, "XXX Client", true);
  store.Close();
  
  // Add certificate to the request
  request.ClientCertificates.Add(certificates[0]);
  
  // Issue the request
  using (HttpWebResponse response = request.GetResponse() as HttpWebResponse)
  {
     ...
  }
  

  I have been banging my head on the wall for 2-3 days on this problem so any insight you can provide will be greatly appreciated.

  Thanks,

  Terry