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

432

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?

Simon Dugré
fonte
3
Verifique isso também stackoverflow.com/questions/1600743/…
Oskar Kjellin
51
É 2018 e esta pergunta foi vista 308.056 vezes, mas ainda não há uma correção adequada para isso !! Eu recebo esse problema aleatoriamente e nenhuma das correções mencionadas aqui ou em outros tópicos resolveu o meu problema.
Nigel Fds 03/04/19
3
@NigelFds O erro The request was aborted: Could not create SSL/TLS secure channelé muito genérico. Basicamente, "a inicialização da conexão SSL / TLS / HTTPS falhou por um dos muitos motivos possíveis". Portanto, se você obtê-lo regularmente em uma situação específica, sua melhor opção é fazer uma pergunta específica, fornecendo detalhes específicos sobre essa situação. E verificando o Visualizador de Eventos para obter mais informações. E / ou habilite a depuração do lado do cliente .NET para obter mais detalhes (o certificado do servidor não é confiável? Existe uma incompatibilidade de cifra? Incompatibilidade de versão do protocolo SSL / TLS etc.)
MarnixKlooster ReinstateMonica
4
@ MarnixKlooster Eu já verifiquei tudo isso, não pode haver um problema com o certificado, como se eu o tentasse novamente, ele funciona. E duvido que seria capaz de fazer essa pergunta no SO sem que alguém viesse marcá-la como duplicada ou algo assim.
Nigel Fds 11/04/19
1
Estou lutando contra essa questão pela quarta vez. A mesma base de código que estou executando funciona bem na produção e também no ambiente de desenvolvimento de alguns dos meus colegas desenvolvedores. Na última vez, fui instruído a adicionar um valor de registro Computer \ HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Microsoft \ .NETFramework \ v4.7.02046 \ SchUseStrongCrypto [DWORD] = 1. E funcionou por um tempo. Comecei a trabalhar em um projeto diferente por um tempo e agora estou de volta a esse projeto e a solicitação falha novamente, mesmo com essa correção da chave do Registro. Muito irritante.
Miguel

Respostas:

598

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.

Simon Dugré
fonte
5
Descer para SecurityProtocolType.Tls12 realmente corrigiu esse problema para mim. Veja minha resposta abaixo.
Bryan Legend
24
SSLv3 tem 18 anos e agora suscetíveis à POODLE explorar - como @LoneCoder recomenda SecurityProtocolType.Tls12 é a substituição apropriado para SecurityProtocolType.Ssl3
gary
4
SecurityProtocolType.Tls pode realmente ser uma alternativa melhor até que um exploit é encontrado para que (nem todos os sites apoiar Tls12 como da escrita)
gary
3
O PayPal definiu uma data de 30 de junho de 2017 para desativar o SSL3 e implementar o TLS1.2. Ele já é aplicada em seu ambiente sandbox paypal-knowledge.com/infocenter/...
Robin French
11
Veja isso também. Você não precisa defini-lo exclusivamente para um único tipo, você pode simplesmente anexar também. System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls12;
Nae
153

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;
Andrej Z
fonte
10
Obrigado! Preciso usar o .net 4.0 e não sabia como resolver isso. Isso parece funcionar aqui. :)
Fabiano
Não funciona em Windows Server 2008R2 (e possivelmente em 2012, bem)
Misam
@billpg, leia este para resposta mais exata
Vikrant
Para tipos VB (desde esta resposta aparece no Google), o código equivalente éServicePointManager.SecurityProtocol = DirectCast(3072, SecurityProtocolType)
ConfusionTowers
@Andrej Z está trabalhando na estrutura .net 4. Obrigado.
Fav #
107

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;
hogarth45
fonte
4
Qual é a diferença entre Works e Fails que você mencionou acima?
Chandy Kunhu
5
Impressionante. Meu pedido só funcionou após a segunda tentativa, o que não fazia sentido e depois vi sua postagem, movi o protocolo de segurança antes do pedido e pronto, resolvido. Obrigado @ hogarth45 #
deanwilliammills #
2
Exatamente! Quando coloquei o ServicePointManager pouco antes da criação da solicitação, funcionou para mim. Obrigado, homem. Você salvou meu dia.
1
Perfeito ... isso é maravilhoso #
Maryam Bagheri
1
No nosso caso, a solicitação falhou pela primeira vez e funcionou depois. Isso foi exatamente por causa do motivo declarado nesta resposta!
Mohammad Dehghan
34

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

Avitus
fonte
Eu tentei executar o winhttpcertcfg.exe ... observe que estou no Windows 7. Pode mudar alguma coisa?
Simon Dugré 19/05/10
Não tenho certeza se está relacionado, mas este post me deu a ideia de executar o VS como administrador ao fazer essa chamada do VS e isso corrigiu o problema para mim.
PFranchise
2
No Windows 7 e, mais tarde, o certificado deve ser na loja para o computador local, em vez de usuário atual, a fim de "gerir privados Chaves"
Lukos
1
Sim, este foi o meu problema. use mmc.exe, adicione o snap-in de certificados (para mim, escolhi 'computador local'). Clique com o botão direito do mouse em certificado, todas as tarefas, gerencie chaves privadas. Adicione 'everyone' (para desenvolvedores locais, isso é mais fácil - o produto obviamente precisa do pool / usuário explícito de aplicativos do site do IIS)
Ian Yates
@Ian Yates, esta solução só funcionou para mim (y)
Usman Younas
31

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 .

Remus Rusanu
fonte
Onde está o caminho para Schannel event logginga do Windows 7-8-10 ?
PreguntonCojoneroCabrón
solucionar problemas de TLS / SSL programaticamente em c #?
Kanjet
27

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");
Bryan Legend
fonte
Obrigado Lone ... isso é loucura, como parece haver muitas possibilidades diferentes de problemas, dependendo da situação ... E, como posso ver, não há documentação real disso. Bem, obrigado por apontar para alguém que poderá enfrentar o mesmo problema.
Simon Dugré 15/10
Isso funcionou para mim. Eu enfrentei o erro quando mudei da LAN do escritório para a minha rede doméstica. Mesmo código, mesmo laptop!
Amal
Você recebe o erro sempre (em todas as solicitações) ou algumas vezes ?
PreguntonCojoneroCabrón
24

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.

Nick Gotch
fonte
3
Esta resposta deve ter mais votos positivos. Após uma semana de pesquisa, esta é a única solução que funcionou para mim. Obrigado!!
precisa saber é o seguinte
Isso funcionou para mim. perfeito obrigado.
Emy Stats
18

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?

simplesmente bom
fonte
17

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;
SpoiledTechie.com
fonte
8
Eu não recomendaria o protocolo SSL3 adicionado.
Peter de Bruijn
O SSL3 tem um grave problema de segurança chamado 'Poodle'.
Peter de Bruijn
@PeterdeBruijn Tls and Tls11são obsoletos ?
Kanjet
1
@Kiquenet - sim. Em junho de 2018, o PCI (Payment Card Industries) não permitirá protocolos inferiores ao TLS1.2. (Esta foi originalmente previsto para 06/2017, mas foi adiada por um ano)
GlennG
Existem cinco protocolos na família SSL / TLS: SSL v2, SSL v3, TLS v1.0, TLS v1.1 e TLS v1.2 : github.com/ssllabs/research/wiki/… SSL v2 unsecure, SSL v3 is insecure when used with HTTP (the POODLE attack), TLS v1.0, TLS v1.1 obsoletes Somente a opção válida será ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12?
Kiquenet
14

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.

caixa de diálogo de importação de certificado

Sherlock
fonte
Um cliente continuava tendo que reinstalar o certificado para usar um programa cliente. Repetidas vezes, eles teriam que reinstalar o certificado antes de usar o programa. Espero que esta resposta resolva esse problema.
Pangamma
11

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".

Jon Schneider
fonte
1
Meu agendador de tarefas é executado todos os dias (não nos finais de semana). Eu recebo o mesmo erro, mas às vezes ( 2 errors in 2 months). Quando recebo o erro, alguns minutos depois, tento novamente manualmente e tudo está OK.
Kiquenet
10

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

Jon Schneider
fonte
1
No meu caso, esta resposta é útil. Além disso, como suspeitei que meu PC cliente perdeu alguns conjuntos de códigos, peguei um atalho e instalei este Windows Update diretamente para tentar a minha sorte ( support.microsoft.com/en-hk/help/3161639 , precisa da reinicialização do Windows) antes de realmente iniciar o O Message Analyzer pesquisou e tive a sorte de resolver o meu problema, poupando uma pesquisa para mim.
sken130
1
Observe que, quando você testa um link HTTPS em navegadores como o Firefox, mesmo que você obtenha uma cifra diferente da fornecida por qualquer Windows Update, ainda vale a pena tentar o Windows Update, pois a instalação de novas cifras afetará a negociação da cifra. entre o PC cliente e o servidor, aumentando assim a esperança de encontrar uma correspondência.
sken130
Ao ponto, responda pelo meu problema. Duas coisas que me ajudaram a encontrar as mudanças a serem feitas. 1. Conjuntos de cifras suportados pelo servidor da web: ssllabs.com/ssltest 2. Conjuntos de cifras suportados por diferentes versões do Windows: docs.microsoft.com/en-us/windows/win32/secauthn/…
Paul B.
10

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.)
Tyler Forsythe
fonte
2
Ao contrário da regra geral, adicionarei que há uma exceção quando você DEVE configurá-la para TLS 1.2, em vez de deixar o padrão executar. Se você estiver em uma estrutura anterior ao .NET 4.6 e desabilitar protocolos não seguros no servidor (SSL ou TLS 1.0 / 1.1), não poderá emitir solicitações a menos que force o programa no TLS 1.2.
Paul
10

Eu tive esse problema porque meu web.config tinha:

<httpRuntime targetFramework="4.5.2" />

e não:

<httpRuntime targetFramework="4.6.1" />
Terje Solem
fonte
Eu tive esse mesmo problema e adicionamos uma resposta mais detalhada abaixo, que aborda mais os meandros desse problema.
JLRishe
9

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 ...
TCC
fonte
2
Uau! Obrigado por mencionar isso. Não conseguia acreditar nisso e tentei várias coisas diferentes primeiro. Finalmente, defina o tempo limite para 10 segundos e a exceção desapareceu! Esta é a solução para mim. (y)
derFunk 11/08
9

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).

APW
fonte
9

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" />
JLRishe
fonte
8

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;
        }
    }
Arun Prasad ES
fonte
2
Substituir ServerCertificateValidationCallback introduziria nova falha de segurança?
7

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

insira a descrição da imagem aqui

cnom
fonte
qualquer problema em marcar todos eles?
Nigel Fds 03/04/19
sem problemas, até onde eu sei ... exceto que o ssl não é mais recomendado ... eles não são considerados suficientemente seguros.
cnom
como fazê-lo programaticamente no PowerShell?
Kiquenet
Isso é algo que afeta as versões mais antigas do Windows, faça algumas pesquisas, descubra quais opções de segurança estão em uso no momento. A partir de hoje, veja este link: tecadmin.net/enable-tls-on-windows-server-and-iis
Tod
7

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
Dinesh Rajan
fonte
7

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

bplus
fonte
Infelizmente não para mim!
benedict_w
Este é o único que ajudou no meu caso! Obrigado!!!
alexander ostrikov
6

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

um fantasma
fonte
5
O motivo pelo qual isso funcionou pode ter sido porque versões diferentes do .NET suportam versões diferentes do protocolo SSL / TLS. Mais informações: blogs.perficient.com/microsoft/2016/04/tsl-1-2-and-net-support
Jon Schneider
4

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
capdragon
fonte
3
Aqui PS para edição rápida: New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo
2
Aqui PS para edição rápida2:New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value "1" -Type DWord
Tilo
4

Tente o seguinte:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Muhammad Awais
fonte
Eu adicionei esta linha. Às vezes ele falha e eu recebo o mesmo erroSystem.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
Joseph Katzman
4

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".

jayasurya_j
fonte
3

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?

Danny Cullen
fonte
Sim, idem. Para corrigi-lo, fiz o que a resposta de Nick Gotch disse: alterei a identidade do pool de aplicativos para LocalSystem. Isso resolveu para mim.
Judah Gabriel Himango
1
Obrigado por isso
Denis Pitcher
3

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
joeydood
fonte
3

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.

Michael Silver
fonte
Além disso, verifique se você está configurando apenas o ServicePointManager.SecurityProtocol uma vez no seu aplicativo. Descobrimos uma segunda chamada em nosso aplicativo (que é bastante complexa com os assemblies opcionais sendo carregados em tempo de execução) que a definiam como SSL3, que emitiu a mesma mensagem de erro.
Michael Silver
3

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.

HeyJude
fonte
2

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.

Mark Reid
fonte
1
Não use links na resposta, pois eles podem não funcionar no futuro, apontam os aspectos mais relevantes sobre ele dentro de sua resposta
Rodrigo López