Corrigir erro de criptografia do SQL Server - solução com um clique

Leia o erro – é um problema de confiança, não um problema de rede

Sua rede está boa e o servidor está funcionando. A conexão chegou ao SQL Server, o servidor ofereceu um canal criptografado para o login e seu PC recusou porque o certificado que comprova a identidade do servidor é assinado por ninguém em que seu PC confia. O erro completo que o SSMS mostra é:

Por padrão, o SQL Server protege o logon com um certificado autoassinado que ele mesmo cria. Um certificado autoassinado criptografa o tráfego, mas não pode provar que o servidor é realmente o seu servidor, portanto, os clientes que exigem criptografia verificada o rejeitam. Cada correção honesta é uma de duas coisas: fazer com que o cliente aceite esse servidor específico conscientemente (Etapas 2 e 3) ou fornecer ao servidor um certificado em que os clientes confiam por conta própria (Etapa 4).

A correção rápida do cliente no SSMS - certificado de servidor confiável

Este é o caminho rápido mostrado no vídeo. Não muda nada no servidor; diz a esta conexão para aceitar o certificado do servidor sem verificar quem o assinou. Na janela SSMS Conectar ao servidor, clique em Opções para abrir as guias extras, vá para a guia Propriedades da conexão, defina a criptografia como Obrigatória (ou deixe-a como oferecida), marque Confiar certificado do servidor e clique em Conectar. O login é feito imediatamente.

A mesma correção dentro de uma string de conexão de aplicativo

Se um aplicativo falhar em vez do SSMS, o mesmo switch permanecerá em sua cadeia de conexão. Adicione as duas configurações explicitamente - Encrypt=True ativa o canal protegido e TrustServerCertificate=True é a ortografia da cadeia de conexão da caixa de seleção SSMS:

Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;

Use seu próprio nome de servidor, banco de dados e login no lugar dos valores de exemplo. A compensação é exatamente a mesma da caixa de seleção na Etapa 2, com um perigo extra: inserida na configuração de um aplicativo enviado, a verificação ignorada se aplica a todos os usuários, de forma invisível e permanente. Mantenha-o nas configurações de desenvolvimento e preparação e, na produção, trate-o como tempo emprestado até que o certificado do servidor na Etapa 4 esteja em vigor.

A solução adequada – forneça ao servidor um certificado real

O reparo permanente acontece uma vez, no servidor, e depois cada cliente se conecta estritamente, sem caixa de seleção e sem aviso. Primeiro, obtenha um certificado para o nome DNS completo do servidor (por exemplo sql01.company.local) da sua autoridade de certificação interna ou de uma CA pública, com uso de Autenticação de servidor. Importe-o, com sua chave privada, para o armazenamento de certificados do Computador Local na máquina SQL Server. Em seguida, clique com o botão direito no certificado, escolha Todas as tarefas → Gerenciar chaves privadas e conceda à conta de serviço do SQL Server permissão Leitura na chave privada. Abra o SQL Server Configuration Manager, expanda SQL Server Network Configuration, clique com o botão direito em Protocolos para MSSQLSERVER, escolha Propriedades e selecione o certificado na guia Certificado. Na guia Sinalizadores você também pode definir ForceEncryption como Sim para que todos os clientes sejam obrigados a criptografar. Reinicie o serviço SQL Server - a alteração não fará nada até que você o faça.

Verifique a correção da maneira estrita

Um login bem-sucedido silenciosamente prova menos do que as pessoas pensam, porque algumas combinações de configurações se conectam sem proteção real. Prove as duas metades. Primeiro, reconecte-se de um cliente da maneira estrita: conecte-se usando o nome DNS do servidor - o nome dentro do certificado - defina a criptografia como Obrigatória e deixe Certificado de servidor confiável desmarcado. O login deve ser bem-sucedido sem aviso prévio. Então, nessa mesma sessão, pergunte ao servidor se a conexão está realmente criptografada executando esta consulta no SSMS:

SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

encrypt_option mostrando TRUE é a nota de aprovação. FALSE com um login funcional significa que a conexão foi bem-sucedida ao eliminar a proteção e o trabalho não foi concluído. Essa aprovação no teste é a verdadeira linha de chegada: qualquer cliente configurado corretamente, incluindo versões futuras do SSMS, agora se conecta com validação completa e sem configurações especiais.