A solicitação foi abortada: não foi possível criar o canal seguro SSL / TLS

Não foi possível conectar-se a um servidor HTTPS usando WebRequestdevido a esta mensagem de erro:

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

Sabemos que o servidor não possui um certificado HTTPS válido com o caminho usado, mas para contornar esse problema, usamos o seguinte código que retiramos de outra postagem do StackOverflow:

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

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

O problema é que o servidor nunca valida o certificado e falha com o erro acima. Alguém tem alguma idéia do que devo fazer?

Devo mencionar que um colega e eu realizamos testes há algumas semanas e estava funcionando bem com algo semelhante ao que escrevi acima. A única "grande diferença" que encontramos é que estou usando o Windows 7 e ele estava usando o Windows XP. Isso muda alguma coisa?

Finalmente encontrei a resposta (não anotei minha fonte, mas era de uma pesquisa);

Enquanto o código funciona no Windows XP, no Windows 7, você deve adicioná-lo no início:

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

E agora, funciona perfeitamente.

TERMO ADITIVO

Como mencionado por Robin French; se você está tendo esse problema ao configurar o PayPal, observe que eles não suportam SSL3 a partir de 3 de dezembro de 2018. Você precisará usar o TLS. Aqui está a página Paypal sobre isso.

A solução para isso, no .NET 4.5 é

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Se você não possui o .NET 4.5, use

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Verifique se as configurações do ServicePointManager são feitas antes da criação do HttpWebRequest, caso contrário, não funcionará.

Trabalho:

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

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

Falha:

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

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

O problema que você está tendo é que o usuário aspNet não tem acesso ao certificado. Você precisa dar acesso usando o winhttpcertcfg.exe

Um exemplo de como configurar isso está em: http://support.microsoft.com/kb/901183

Na etapa 2 em mais informações

EDIT: nas versões mais recentes do IIS, esse recurso é incorporado à ferramenta do gerenciador de certificados - e pode ser acessado clicando com o botão direito do mouse no certificado e usando a opção para gerenciar chaves privadas. Mais detalhes aqui: /server/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

O erro é genérico e há muitos motivos pelos quais a negociação SSL / TLS pode falhar. O mais comum é um certificado de servidor inválido ou expirado, e você cuidou disso fornecendo seu próprio gancho de validação de certificado de servidor, mas não é necessariamente o único motivo. O servidor pode exigir autenticação mútua, pode ser configurado com um conjunto de cifras não suportadas pelo seu cliente, pode ter um desvio de tempo muito grande para que o handshake seja bem-sucedido e muitos outros motivos.

A melhor solução é usar o conjunto de ferramentas de solução de problemas do SChannel. O SChannel é o provedor SSPI responsável pelo SSL e TLS e seu cliente o utilizará para o handshake. Dê uma olhada nas Ferramentas e configurações TLS / SSL .

Consulte também Como habilitar o log de eventos do Schannel .

Eu tive esse problema ao tentar acessar https://ct.mob0.com/Styles/Fun.png , que é uma imagem distribuída pelo CloudFlare em sua CDN que suporta coisas loucas como SPDY e certificados SSL de redirecionamento estranho.

Em vez de especificar o Ssl3 como na resposta de Simons, eu era capaz de corrigi-lo descendo para o Tls12 assim:

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

Depois de muitas horas com esse mesmo problema, descobri que a conta do ASP.NET em que o serviço do cliente estava sendo executado não tinha acesso ao certificado. Eu o corrigi indo para o Pool de aplicativos IIS em que o aplicativo Web é executado, acessando Configurações avançadas e alterando a identidade para a LocalSystemconta NetworkService.

Uma solução melhor é fazer com que o certificado funcione com a NetworkServiceconta padrão , mas isso funciona para testes funcionais rápidos.

A abordagem com a configuração

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Parece estar bem, porque o Tls1.2 é a versão mais recente do protocolo seguro. Mas eu decidi olhar mais profundamente e responder se realmente precisamos codificá-lo.

Especificações: Windows Server 2012R2 x64.

Na internet, é dito que o .NetFramework 4.6+ deve usar o Tls1.2 por padrão. Mas quando atualizei meu projeto para 4.6, nada aconteceu. Encontrei algumas informações que indicam que preciso fazer manualmente algumas alterações para ativar o Tls1.2 por padrão

https://support.microsoft.com/en-in/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

Mas a atualização proposta do Windows não funciona para a versão R2

Mas o que me ajudou foi adicionar 2 valores ao registro. Você pode usar o próximo script PS para que eles sejam adicionados automaticamente

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

Isso é o que eu estava procurando. Mas ainda não consigo responder à pergunta por que o NetFramework 4.6+ não define isso ... Valor do protocolo automaticamente?

Algo que a resposta original não tinha. Eu adicionei um pouco mais de código para torná-lo à prova de balas.

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

Outra possibilidade é a importação incorreta de certificado na caixa. Certifique-se de marcar a caixa de seleção cercada. Inicialmente, eu não o fiz, então o código estava atingindo o tempo limite ou lançava a mesma exceção que a chave privada não pôde ser localizada.

A exceção "A solicitação foi interrompida: não foi possível criar canal seguro SSL / TLS" pode ocorrer se o servidor estiver retornando uma resposta HTTP 401 não autorizada à solicitação HTTP.

Você pode determinar se isso está acontecendo ativando o log System.Net em nível de rastreio para seu aplicativo cliente, conforme descrito nesta resposta .

Depois que essa configuração de log estiver em vigor, execute o aplicativo e reproduza o erro e procure na saída de log uma linha como esta:

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

Na minha situação, falhei ao definir um cookie específico que o servidor esperava, levando o servidor a responder à solicitação com o erro 401, o que levou à exceção "Não foi possível criar canal seguro SSL / TLS".

Outra causa possível do The request was aborted: Could not create SSL/TLS secure channelerro é uma incompatibilidade entre os valores cipher_suites configurados do PC cliente e os valores que o servidor está configurado como disposto e capaz de aceitar . Nesse caso, quando seu cliente envia a lista de valores cipher_suites que ele pode aceitar na mensagem inicial "Cliente Olá" de handshaking / negociação SSL, o servidor vê que nenhum dos valores fornecidos é aceitável e pode retornar um "Alerta "em vez de prosseguir para a etapa" Server Hello "do handshake SSL.

Para investigar essa possibilidade, você pode baixar o Microsoft Message Analyzer e usá-lo para executar um rastreamento na negociação SSL que ocorre quando você tenta e falha ao estabelecer uma conexão HTTPS com o servidor (no aplicativo C #).

Se você conseguir estabelecer uma conexão HTTPS bem-sucedida de outro ambiente (por exemplo, a máquina Windows XP que você mencionou - ou possivelmente pressionando a URL HTTPS em um navegador que não seja da Microsoft que não usa as configurações do conjunto de cifras do sistema operacional, como Chrome ou Firefox), execute outro rastreamento do Message Analyzer nesse ambiente para capturar o que acontece quando a negociação do SSL é bem-sucedida.

Felizmente, você verá alguma diferença entre as duas mensagens do Hello do cliente que permitirão identificar exatamente o que acontece com a falha na negociação SSL. Em seguida, você poderá fazer alterações na configuração do Windows que permitirão que ele seja bem-sucedido. O IISCrypto é uma ótima ferramenta para isso (mesmo para PCs clientes, apesar do nome "IIS").

As duas chaves de registro do Windows a seguir regem os valores cipher_suites que o seu PC usará:

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

Aqui está uma descrição completa de como eu investiguei e resolvi uma instância dessa variedade do Could not create SSL/TLS secure channelproblema: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html

A raiz dessa exceção no meu caso foi que, em algum momento do código, o seguinte estava sendo chamado:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Isso é muito ruim. Não apenas está instruindo o .NET a usar um protocolo não seguro, mas isso afeta todas as novas solicitações de WebClient (e similares) feitas posteriormente no domínio do aplicativo. (Observe que as solicitações da Web recebidas não são afetadas no aplicativo ASP.NET, mas novas solicitações do WebClient, como conversar com um serviço da Web externo, são).

No meu caso, ele não era realmente necessário, então eu poderia simplesmente excluir a declaração e todas as minhas outras solicitações da web começaram a funcionar bem novamente. Com base em minhas leituras em outros lugares, aprendi algumas coisas:

• Essa é uma configuração global no domínio do aplicativo e, se você tiver atividade simultânea, não poderá defini-lo com um valor confiável, executar sua ação e, em seguida, restaurá-lo. Outra ação pode ocorrer durante essa pequena janela e sofrer impacto.
• A configuração correta é deixá-lo como padrão. Isso permite que o .NET continue usando o valor padrão mais seguro à medida que o tempo passa e você atualiza as estruturas. Configurá-lo para TLS12 (que é o mais seguro até o momento em que este documento foi escrito) funcionará agora, mas em cinco anos poderá começar a causar problemas misteriosos.
• Se você realmente precisar definir um valor, considere fazê-lo em um aplicativo ou domínio de aplicativo especializado separado e encontre uma maneira de conversar entre ele e seu pool principal. Por ser um valor global único, tentar gerenciá-lo em um pool de aplicativos ocupados só causará problemas. Esta resposta: https://stackoverflow.com/a/26754917/7656 fornece uma solução possível por meio de um proxy personalizado. (Observe que eu não o implementei pessoalmente.)

Eu tive esse problema porque meu web.config tinha:

<httpRuntime targetFramework="4.5.2" />

e não:

<httpRuntime targetFramework="4.6.1" />

Como você pode ver, existem muitas razões pelas quais isso pode acontecer. Pensei em adicionar a causa que encontrei ...

Se você definir o valor de WebRequest.Timeoutcomo 0, esta é a exceção lançada. Abaixo está o código que eu tinha ... (Exceto em vez de um código embutido 0para o valor do tempo limite, eu tinha um parâmetro que foi inadvertidamente definido como 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 ...

A resposta mais votada provavelmente será suficiente para a maioria das pessoas. No entanto, em algumas circunstâncias, você pode continuar recebendo o erro "Não foi possível criar canal seguro SSL / TLS" mesmo depois de forçar o TLS 1.2. Nesse caso, você pode consultar este artigo útilpara etapas adicionais de solução de problemas. Resumindo: independente do problema da versão TLS / SSL, o cliente e o servidor devem concordar com um "conjunto de criptografia". Durante a fase "handshake" da conexão SSL, o cliente listará seus conjuntos de cifras suportados para que o servidor verifique sua própria lista. Mas em algumas máquinas Windows, alguns conjuntos de cifras comuns podem ter sido desativados (aparentemente devido a tentativas bem-intencionadas de limitar a superfície de ataque), diminuindo a possibilidade de o cliente e o servidor concordarem com um conjunto de cifras. Se eles não concordarem, você poderá ver "código de alerta fatal 40" no visualizador de eventos e "Não foi possível criar canal seguro SSL / TLS" no seu programa .NET.

O artigo mencionado acima explica como listar todos os conjuntos de cifras potencialmente suportados de uma máquina e ativar conjuntos de cifras adicionais por meio do Registro do Windows. Para ajudar a verificar quais conjuntos de criptografia estão habilitados no cliente, tente visitar esta página de diagnóstico no MSIE. (O uso do rastreamento System.Net pode fornecer resultados mais definitivos.) Para verificar quais conjuntos de cifras são suportados pelo servidor, tente esta ferramenta online (supondo que o servidor seja acessível pela Internet). Não é necessário dizer que as edições do Registro devem ser feitas com cautela , especialmente nos casos em que a rede está envolvida. (Sua máquina é uma VM hospedada remota? Se você interromper a rede, a VM seria acessível?)

No caso da minha empresa, habilitamos vários pacotes "ECDHE_ECDSA" adicionais por meio da edição do Registro, para corrigir um problema imediato e proteger contra problemas futuros. Mas se você não pode (ou não deseja) editar o Registro, várias soluções alternativas (não necessariamente bonitas) vêm à mente. Por exemplo: seu programa .NET pode delegar seu tráfego SSL em um programa Python separado (que pode funcionar por si mesmo, pelo mesmo motivo que as solicitações do Chrome podem ser bem-sucedidas quando as solicitações do MSIE falham em uma máquina afetada).

Uma das maiores causas desse problema é a versão ativa do .NET Framework. A versão de tempo de execução do .NET framework afeta quais protocolos de segurança são ativados por padrão.

Não parece haver nenhuma documentação autorizada sobre como funciona especificamente em diferentes versões, mas parece que os padrões são determinados mais ou menos da seguinte maneira:

• .NET Framework 4.5 e versões anteriores - SSL 3.0, TLS 1.0
• .NET Framework 4.6.x - TLS 1.0, 1.1, 1.2, 1.3
• .NET Framework 4.7+ - Padrões do sistema (SO)

(Para versões mais antigas, sua milhagem pode variar um pouco com base em quais tempos de execução do .NET estão instalados no sistema. Por exemplo, pode haver uma situação em que você está usando uma estrutura muito antiga e o TLS 1.0 não é suportado ou o 4.6. x e TLS 1.3 não são suportados)

A documentação da Microsoft recomenda enfaticamente o uso do 4.7+ e os padrões do sistema:

Recomendamos que você:

• Segmente o .NET Framework 4.7 ou versões posteriores nos seus aplicativos. Segmente o .NET Framework 4.7.1 ou versões posteriores nos seus aplicativos WCF.
• Não especifique a versão do TLS. Configure seu código para permitir que o sistema operacional decida a versão do TLS.
• Execute uma auditoria de código completa para verificar se você não está especificando uma versão TLS ou SSL.

Para sites ASP.NET , verifique a versão do .NET framework no seu <httpRuntime>elemento, pois isso determina qual tempo de execução é realmente usado pelo seu site:

<httpRuntime targetFramework="4.5" />

Melhor:

<httpRuntime targetFramework="4.7" />

Este está trabalhando para mim no MVC webclient

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

Caso o cliente seja uma máquina Windows, um possível motivo pode ser que o protocolo tls ou ssl exigido pelo serviço não esteja ativado.

Isso pode ser definido em:

Painel de controle -> Rede e Internet -> Opções da Internet -> Avançado

Role as configurações até "Segurança" e escolha entre

• Use SSL 2.0
• Use SSL 3.0
• Use TLS 1.0
• Use TLS 1.1
• Use TLS 1.2

No meu caso, a conta de serviço executando o aplicativo não tinha permissão para acessar a chave privada. Depois de conceder essa permissão, o erro desapareceu

1. mmc
2. certificados
3. Expandir para pessoal
4. selecione cert
5. clique direito
6. Todas as tarefas
7. Gerenciar chaves privadas
8. Adicionar

Se você estiver executando seu código no Visual Studio, tente executar o Visual Studio como administrador. Corrigido o problema para mim.

Eu lutei com esse problema o dia todo.

Quando criei um novo projeto com o .NET 4.5, finalmente o fiz funcionar.

Mas se eu fiz o downgrade para 4.0, tive o mesmo problema novamente e era irreversível para esse projeto (mesmo quando tentei atualizar para o 4.5 novamente).

Estranha nenhuma outra mensagem de erro, mas "A solicitação foi abortada: não foi possível criar o canal seguro SSL / TLS". surgiu para este erro

System.Net.WebException: a solicitação foi interrompida: não foi possível criar o canal seguro SSL / TLS.

No nosso caso, usamos um fornecedor de software para não termos acesso para modificar o código .NET. Aparentemente, o .NET 4 não usará o TLS v 1.2, a menos que haja uma alteração.

A correção para nós foi adicionar a chave SchUseStrongCrypto ao registro. Você pode copiar / colar o código abaixo em um arquivo de texto com a extensão .reg e executá-lo. Serviu como nosso "patch" para o problema.

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

Tente o seguinte:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Isso corrigiu para mim, adicione o Serviço de Rede às permissões. Clique com o botão direito do mouse no certificado> Todas as tarefas> Gerenciar chaves privadas ...> Adicionar ...> Adicionar "Serviço de rede".

O problema para mim foi que eu estava tentando implantar no IIS como um serviço da Web, instalei o certificado no servidor, mas o usuário que executa o IIS não tinha as permissões corretas no certificado.

Como conceder ao ASP.NET acesso a uma chave privada em um certificado no armazenamento de certificados?

Eu estava tendo esse mesmo problema e achei que essa resposta funcionou corretamente para mim. A chave é 3072. Este link fornece os detalhes sobre a correção '3072'.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

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

No meu caso, dois feeds exigiram a correção:

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

Esta pergunta pode ter muitas respostas, pois se trata de uma mensagem de erro genérica. Encontramos esse problema em alguns de nossos servidores, mas não em nossas máquinas de desenvolvimento. Depois de arrancar a maioria dos cabelos, descobrimos que era um bug da Microsoft.

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

Essencialmente, a MS assume que você deseja uma criptografia mais fraca, mas o sistema operacional está corrigido para permitir apenas o TLS 1.2, para que você receba o temido "A solicitação foi abortada: não foi possível criar o canal seguro SSL / TLS".

Existem três correções.

1) Aplique um patch ao sistema operacional com a atualização adequada: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) Adicione uma configuração ao seu arquivo app.config / web.config.

3) Adicione uma configuração de registro que já foi mencionada em outra resposta.

Tudo isso é mencionado no artigo da base de conhecimento que publiquei.

Outra possibilidade é que o código que está sendo executado não tenha as premissas necessárias.

No meu caso, recebi esse erro ao usar o depurador do Visual Studio para testar uma chamada para um serviço web. O Visual Studio não estava sendo executado como administrador, o que causou essa exceção.

Isso estava acontecendo para mim em apenas um site, e acontece que ele só tinha a cifra RC4 disponível. Em um esforço anterior para proteger o servidor, desabilitei a cifra RC4. Depois de reativá-la, o problema foi resolvido.