Partilhar via

Criptografar conexões com o SQL Server no Linux

Aplica-se a:SQL Server em Linux

O SQL Server no Linux pode usar TLS (Transport Layer Security) para criptografar dados transmitidos por uma rede entre um aplicativo cliente e uma instância do SQL Server. O SQL Server oferece suporte aos mesmos protocolos TLS no Windows e Linux: 1.2, 1.1 e 1.0.

Observação

A partir do SQL Server 2025 (17.x), o TLS 1.3 está ativado por defeito.

As etapas para configurar o TLS são específicas para o sistema operacional no qual o SQL Server está sendo executado.

Requisitos aplicáveis aos certificados

Certifique-se de que os seus certificados seguem estes requisitos:

  • A hora atual do sistema deve ser após a data indicada pela propriedade Valid from do certificado e antes da data indicada pela propriedade Valid to do certificado.

  • O certificado deve ser destinado à autenticação do servidor. Isso requer a propriedade Enhanced Key Usage do certificado para especificar Server Authentication (1.3.6.1.5.5.7.3.1).

  • O certificado deve ser criado usando a opção KeySpec de AT_KEYEXCHANGE. Normalmente, a propriedade de uso de chave do certificado (KEY_USAGE) também inclui codificação de chave (CERT_KEY_ENCIPHERMENT_KEY_USAGE).

  • A propriedade Subject do certificado deve indicar que o nome comum (CN) é o mesmo que o nome do host ou nome de domínio totalmente qualificado (FQDN) do computador servidor.

    Observação

    Certificados wildcard são suportados.

Configurar as bibliotecas OpenSSL para uso (opcional)

Você pode criar links simbólicos no diretório /opt/mssql/lib/ que fazem referência a quais bibliotecas libcrypto.so e libssl.so devem ser usadas para criptografia. Isso é útil se você quiser forçar o SQL Server a usar uma versão específica do OpenSSL diferente do padrão fornecido pelo sistema. Se esses links simbólicos não estiverem presentes, o SQL Server carregará as bibliotecas OpenSSL configuradas padrão no sistema.

Esses links simbólicos devem ser nomeados libcrypto.so e libssl.so e colocados no diretório /opt/mssql/lib/.

Observação

Para obter um exemplo de como usar o Let's Encrypt para gerar um certificado, consulte a postagem do blog Desbloqueie o poder dos dados no Azure com o SQL Server em VMs do Azure no Linux e a pesquisa do Azure AI.

Visão geral

O TLS é usado para criptografar conexões de um aplicativo cliente para o SQL Server. Quando configurado corretamente, o TLS fornece privacidade e integridade de dados para comunicações entre o cliente e o servidor. As conexões TLS podem ser iniciadas pelo cliente ou pelo servidor.

A seção a seguir descreve a configuração da criptografia iniciada pelo cliente.

Gerar certificado

/CN deve corresponder ao nome de domínio totalmente qualificado do host do SQL Server.

Atenção

Este exemplo usa um certificado autoassinado. Os certificados autoassinados não devem ser usados para cenários de produção. Você deve usar certificados de CA.

Certifique-se de que as pastas onde você salva seus certificados e chaves privadas, estão acessíveis pelo usuário/grupo mssql e têm permissão definida como 700 (drwx-----). Você pode criar pastas manualmente com a permissão definida como 700 (drwx------) e de propriedade do usuário/grupo mssql, ou definir a permissão para 755 (drwxr-xr-x), de propriedade de outro usuário, mas ainda acessível ao grupo de usuários mssql. Por exemplo, você pode criar uma pasta chamada sslcert sob o caminho /var/opt/mssql/e salvar o certificado e a chave privada com permissões nos arquivos definidos como 600, conforme mostrado no exemplo a seguir.

openssl req -x509 -nodes -newkey rsa:2048 -subj '/CN=mssql.contoso.com' -keyout mssql.key -out mssql.pem -days 365
sudo chown mssql:mssql mssql.pem mssql.key
sudo chmod 600 mssql.pem mssql.key
#Saving the certificate to the certs folder under /etc/ssl/ which has the following permission 755(drwxr-xr-x)
sudo mv mssql.pem /etc/ssl/certs/ drwxr-xr-x
#Saving the private key to the private folder under /etc/ssl/ with permissions set to 755(drwxr-xr-x)
sudo mv mssql.key /etc/ssl/private/

Configurar o SQL Server

Para SQL Server 2022 (16.x) e versões anteriores:

systemctl stop mssql-server
sudo cat /var/opt/mssql/mssql.conf
sudo /opt/mssql/bin/mssql-conf set network.tlscert /etc/ssl/certs/mssql.pem
sudo /opt/mssql/bin/mssql-conf set network.tlskey /etc/ssl/private/mssql.key
sudo /opt/mssql/bin/mssql-conf set network.tlsprotocols 1.2
sudo /opt/mssql/bin/mssql-conf set network.forceencryption 0
systemctl restart mssql-server

Para SQL Server 2025 (17.x):

systemctl stop mssql-server
sudo cat /var/opt/mssql/mssql.conf
sudo /opt/mssql/bin/mssql-conf set network.tlscert /etc/ssl/certs/mssql.pem
sudo /opt/mssql/bin/mssql-conf set network.tlskey /etc/ssl/private/mssql.key
sudo /opt/mssql/bin/mssql-conf set network.forceencryption 0
systemctl restart mssql-server

Registre o certificado em sua máquina cliente (Windows, Linux ou macOS)

  • Se você estiver usando o certificado assinado pela autoridade de certificação, precisará copiar o certificado da autoridade de certificação (CA) em vez do certificado do usuário para a máquina cliente.

  • Se você estiver usando o certificado autoassinado, copie o arquivo de .pem para as seguintes pastas respetivas à distribuição e execute os comandos para habilitá-los:

  • Ubuntu: Copie o certificado para /usr/share/ca-certificates/, renomeie sua extensão para .crte use dpkg-reconfigure ca-certificates para habilitá-lo como certificado de CA do sistema.

  • RHEL: Copie o certificado para /etc/pki/ca-trust/source/anchors/ e use update-ca-trust para habilitá-lo como certificado de autoridade de certificação do sistema.

  • SUSE: copie o certificado para /usr/share/pki/trust/anchors/ e use update-ca-certificates para o habilitar como certificado CA do sistema.

  • Windows: importe o ficheiro .pem como um certificado em Usuário Atual > Autoridades de Certificação Raiz Confiáveis > Certificados.

  • macOS:

    • Copie o certificado para /usr/local/etc/openssl/certs

    • Execute o seguinte comando para obter o valor de hash:

      /usr/local/Cellar/openssl/1.0.2l/openssl x509 -hash -in mssql.pem -noout

    • Renomeie o certificado para o novo valor. Por exemplo: mv mssql.pem dc2dd900.0. Certifique-se de que dc2dd900.0 está em /usr/local/etc/openssl/certs

Exemplo de cadeias de conexão

Atenção

Sua senha deve seguir a política de senha de padrão do SQL Server. Por padrão, a senha deve ter pelo menos oito caracteres e conter caracteres de três dos quatro conjuntos a seguir: letras maiúsculas, letras minúsculas, dígitos de base 10 e símbolos. As palavras-passe podem ter até 128 caracteres. Use senhas tão longas e complexas quanto possível.

  • SQL Server Management Studio (Estúdio de Gestão do Servidor SQL)

    Captura de tela da caixa de diálogo de conexão do SQL Server Management Studio.

  • sqlcmd

    sqlcmd -S <sqlhostname> -N -U sa -P '<password>'

  • ADO.NET

    "Encrypt=True; TrustServerCertificate=False;"

  • ODBC

    "Encrypt=Yes; TrustServerCertificate=no;"

  • JDBC

    "encrypt=true; trustServerCertificate=false;"

Erros comuns de conexão

Mensagem de erro Corrigir
The certificate chain was issued by an authority that is not trusted. Este erro ocorre quando os clientes não conseguem verificar a assinatura no certificado apresentado pelo SQL Server durante o handshake TLS. Verifique se o cliente confia diretamente no certificado do SQL Server ou na autoridade de certificação que assinou o certificado do SQL Server.
The target principal name is incorrect. Verifique se o campo Nome Comum no certificado do SQL Server corresponde ao nome do servidor especificado na cadeia de conexão do cliente.
An existing connection was forcibly closed by the remote host. Este erro pode ocorrer quando o cliente não suporta a versão do protocolo TLS exigida pelo SQL Server. Por exemplo, se o SQL Server estiver configurado para exigir TLS 1.2, certifique-se de que seus clientes também oferecem suporte ao protocolo TLS 1.2.

Ubuntu 20.04 e outros lançamentos recentes de distribuição Linux

Sintoma

Quando uma instância do SQL Server no Linux carrega um certificado que foi criado com um algoritmo de assinatura usando menos de 112 bits de segurança (exemplos: MD5, SHA-1), você pode observar um erro de falha de conexão, como este exemplo:

Uma conexão foi estabelecida com êxito com o servidor, mas ocorreu um erro durante o processo de login. (provedor: Provedor SSL, erro: 0 - Uma conexão existente foi fechada à força pelo host remoto.) (Microsoft SQL Server, erro: 10054)

O erro é devido ao nível de segurança OpenSSL 2 ser ativado por padrão no Ubuntu 20.04 e versões posteriores. O nível de segurança 2 proíbe o estabelecimento de conexões TLS com menos de 112 bits de segurança.

Solução

Instale um certificado com um algoritmo de assinatura usando pelo menos 112 bits de segurança. Os algoritmos de assinatura que satisfazem esse requisito incluem SHA-224, SHA-256, SHA-384 e SHA-512.

  • Last updated on