Erro após aplicar a atualização do SQL Server 2008 R2 10.50.6542 (compilação mais recente)

Finalmente! depois de 3 dias tentando de tudo sob o sol, encontrei a causa raiz do meu problema.

O ah! momento foi quando me juntei a um grupo tentando entender por que esse patch estava sendo implantado bem em outros servidores e não neste em particular.

Percebemos que algo diferente (entre outras coisas... que listamos em um bloco de notas bem organizado) foi que esse SQL Server 2008 R2 foi configurado para criptografia em trânsito (também conhecido como criptografia SSL) por meio de certificados e algumas configurações no gerenciador de configuração do SQL Server, a saber :

1. Em Protocols for [Instance_Name] e depois em Properties (aba certificados) tivemos que selecionar o certificado que criamos para fins de comunicações criptografadas.

2. Nessa mesma janela (guia de sinalizadores), definimos a opção ForceEncryption para o Mecanismo de Banco de Dados como Sim

Então começamos a pensar... e se o problema for o próprio certificado?. Então fomos em frente e removemos a configuração de criptografia (o patch para o SQL Server Build 10.50.6542 ainda aplicado) e a conexão começou a funcionar, confirmando que a combinação do patch com nossa configuração SSL estava maluca.

Após mais investigações e por meio de um processo de eliminação, reduzimos o problema aos certificados que estávamos usando. O certificado foi criado naquela época com makecert (para criar um certificado autoassinado) e NÃO estava usando o parâmetro -a. Este parâmetro informa ao makecert qual algoritmo de Hash deve ser usado. Se não for fornecido, o makecert usará o algoritmo de hash de assinatura MD5 padrão que não é compatível com o TLS 1.2.

Também no TLS 1.2 RFC você pode ver isso explicitamente…

MD5
  MD5 [MD5] is a hashing function that converts an arbitrarily long
  data stream into a hash of fixed size (16 bytes).  Due to
  significant progress in cryptanalysis, at the time of publication
  of this document, MD5 no longer can be considered a 'secure'
  hashing function.

Portanto, para corrigir esse problema, a solução é adicionar o parâmetro -a SHA256 ao makecert (certifique-se de usar o makecert versão 6.3.9600.17298 e não o antigo 5.1313790.0 porque esse não suporta SHA256 como parâmetro ).

Estou escrevendo tudo isso já que todo o enigma me levou 3 dias para descobrir e espero que algum dia alguém se beneficie disso. Se apenas a Microsoft tivesse incluído em letras BIG BOLD que o MD5 não é mais suportado no artigo em que o patch é descrito!

Obrigado a @Mr.Brownstone e @sepupic por toda a ajuda!

O TLS 1.2 não se tornou o protocolo de segurança padrão até o .NET 4.6 e nem era uma opção com suporte até o .NET 4.5, portanto, se você estiver usando um cliente direcionado a um tempo de execução do .NET inferior a 4.5, ele não poderá comunicar usando TLS 1.2 por padrão.

Em seu cenário específico, o cliente é o SQL Server Management Studio. As versões do estúdio de gerenciamento até 2014, inclusive, usavam o .NET 3.5 SP1 como o tempo de execução de destino - o que, infelizmente, impedirá que você se conecte usando o TLS 1.2 como está.

Para solucionar seu problema, atualize sua instalação do estúdio de gerenciamento para a versão mais recente, pois isso é direcionado ao .NET 4.6.1 e usará o TLS 1.2 como o protocolo de segurança padrão.

Página de download do SSMS

Uma segunda solução, se você não conseguir atualizar para a versão mais recente do SSMS, é fazer algumas alterações no registro que forçarão o Windows Server a ignorar o protocolo especificado pelo .NET 3.5 e usar o TLS 1.2. Eu não recomendaria isso (e se você não puder atualizar o SSMS, provavelmente não terá permissão para alterar as configurações do registro), mas incluí as informações para ser completa.

Detalhes sobre como forçar o .NET 3.5 a usar o TLS 1.2 e quais chaves de registro precisam ser alteradas podem ser encontrados abaixo:

Suporte para versões padrão do sistema TLS incluídas no .NET Framework 3.5 no Windows Server 2012