Início / coding / Perguntas / 79564468
Accepted
Mike
Asked: 2025-04-09 21:30:37 +0800 CST

SqlConnection.Open funciona para System.Data.SqlClient e falha para Microsoft.Data.SqlClient com a mesma string de conexão

  • 772

Atualizei uma biblioteca do .NET 4.7 para o .NET 8.0.

Ao fazer isso, tive que atualizar minhas System.Data.SqlClientreferências para Microsoft.Data.SqlClient.

Tenho os dois projetos abertos, em diferentes sessões do VS, lado a lado.

Ambos estão passando exatamente a mesma string de conexão para o Openmétodo em suas respectivas versões de SqlConnection:

Data Source=MyDbServer;Initial Catalog=MyDatabase;Application Name=MyApplication;Pooling='true';Connection Lifetime=500;Integrated Security=SSPI;Persist Security Info=True;

A System.Data.SqlClientversão de SqlConnectionabre sem problemas.

A Microsoft.Data.SqlClientversão de SqlConnectionlevanta esta exceção em Open():

Uma conexão foi estabelecida com sucesso com o servidor, mas ocorreu um erro durante o processo de login. (provedor: Provedor SSL, erro: 0 - A cadeia de certificados foi emitida por uma autoridade não confiável.)'

Duas perguntas:

  1. Por que a System.*versão dá certo e a Microsoft.*versão não?

  2. O que preciso mudar na minha string de conexão para que isso funcione? (por exemplo, não quero mudar nada no servidor do banco de dados ou no próprio banco de dados para que isso funcione... só quero mudar a string de conexão)

Obrigado

migration

3 respostas

  1. Best Answer

    Para a questão 1,

    Microsoft.Data.SqlClient impõe padrões de segurança mais rigorosos em comparação ao System.Data.SqlClient.

    System.Data.SqlClient ignora silenciosamente alguns cenários de validação SSL/TLS, enquanto Microsoft.Data.SqlClient requer certificados confiáveis ​​por padrão e, se o seu SQL Server estiver usando um certificado interno ou autoassinado que não é confiável para sua máquina cliente, ele gera exatamente esse erro.

    Para a pergunta 2, adicione TrustServerCertificate=true; na sua string de conexão.

    • 2

  2. Há um bom guia sobre como migrar de System.Data.SqlClient para Microsoft.Data.SqlClient
    aqui que espero que explique a mudança:
    https://github.com/dotnet/SqlClient/blob/main/porting-cheat-sheet.md#functionality-changes

    A parte relevante está abaixo:
    insira a descrição da imagem aqui

    • 2

  3. A versão anterior era mais tolerante com a segurança, enquanto a versão mais recente é mais rigorosa. Portanto, a resposta pode ser encontrada na documentação desta última. Na seção sobre segurança aprimorada do TDS 8, podemos ver o seguinte:

    Para usar o TDS 8, especifique Encrypt=Strict na string de conexão. O modo Strict desabilita o TrustServerCertificate (sempre tratado como False no modo Strict). HostNameInCertificate foi adicionado para ajudar em alguns cenários do modo Strict. O TDS 8 inicia e continua toda a comunicação do servidor dentro de uma conexão TLS segura e criptografada.

    Novos valores de criptografia foram adicionados para esclarecer o comportamento da criptografia de conexão. Encrypt=Mandatory é equivalente a Encrypt=True e criptografa conexões durante a negociação da conexão TDS. Encrypt=Optional é equivalente a Encrypt=False e criptografa a conexão somente se o servidor informar ao cliente que a criptografia é necessária durante a negociação da conexão TDS.

    Para obter mais informações sobre como criptografar conexões com o servidor, consulte Criptografia e validação de certificado.

    HostNameInCertificate pode ser especificado na string de conexão ao usar aliases para conectar-se com criptografia a um servidor que possui um certificado de servidor com um nome diferente ou nome de assunto alternativo ao nome usado pelo cliente para identificar o servidor (aliases de DNS, por exemplo). Exemplo de uso: HostNameInCertificate=MyDnsAliasName

    A seção Valor padrão do Encrypt definido como verdadeiro explica que isso Encrypté verdadeiro por padrão:

    O valor padrão da configuração Criptografar conexão foi alterado de falso para verdadeiro. Com o uso crescente de bancos de dados em nuvem e a necessidade de garantir a segurança dessas conexões, chegou a hora dessa mudança que quebra a compatibilidade com versões anteriores.

    Resumidamente:

    • com o crescimento dos servidores em nuvem e as crescentes preocupações com a segurança, a criptografia tornou-se realidade por padrão
    • se a criptografia for verdadeira, sua antiga string de conexão não funcionará na ausência de uma criptografia
    • TrustServerCertificatedesabilita o strict more e confia no certificado do servidor, ignorando assim a medida de segurança
    • portanto, quando você o define como falso, ele começa a funcionar
    • Mas a questão da segurança não é resolvida. Para lidar com a questão da segurança, você precisará criptografar corretamente, o que felizmente está bem documentado.
    • 1

relate perguntas