Requisitos de certificado para o SQL Server

Este artigo descreve os requisitos de certificado para o SQL Server e como verificar se um certificado atende a esses requisitos.

Requisitos de certificado para criptografia do SQL Server

Para usar o Transport Layer Security (TLS) para criptografia do SQL Server, você precisa provisionar um certificado (um dos três tipos digitais) que atenda às seguintes condições:

• O certificado deve estar no armazenamento de certificados do computador local ou no armazenamento de certificados da conta de serviço do SQL Server. Recomendamos o armazenamento de certificados do computador local, pois ele evita a reconfiguração de certificados com alterações na conta de inicialização do SQL Server.

• A conta de serviço do SQL Server deve ter a permissão necessária para acessar o certificado TLS. Para obter mais informações, consulte Criptografar conexões com o SQL Server importando um certificado.

• A hora atual do sistema deve ser após o valor da propriedade Valid de e antes do valor da propriedade Valid para do certificado. Para obter mais informações, consulte Certificados expirados.

  Observação

  O certificado deve ser destinado à autenticação do servidor. Isso requer a propriedade Uso Avançado de Chave do certificado para especificar a Autenticação do Servidor (1.3.6.1.5.5.7.3.1).

• O certificado deve ser criado usando a KeySpec opção de AT_KEYEXCHANGE. Isso requer um certificado que use um provedor de armazenamento criptográfico herdado para armazenar a chave privada. Normalmente, a propriedade de uso de chave (KEY_USAGE) do certificado também inclui codificação de chave (CERT_KEY_ENCIPHERMENT_KEY_USAGE) e uma assinatura digital (CERT_DIGITAL_SIGNATURE_KEY_USAGE).

• O Nome Alternativo da Entidade deve incluir todos os nomes que seus clientes podem usar para se conectar a uma instância do SQL Server.

O cliente deve ser capaz de verificar a propriedade do certificado usado pelo servidor. Se o cliente tiver o certificado de chave pública da autoridade de certificação que assinou o certificado do servidor, nenhuma configuração adicional será necessária. O Microsoft Windows inclui os certificados de chave pública de muitas autoridades de certificação. Se o certificado do servidor foi assinado por uma autoridade de certificação pública ou privada para a qual o cliente não tem o certificado de chave pública, você deve instalar o certificado de chave pública da autoridade de certificação que assinou o certificado do servidor em cada cliente que vai se conectar ao SQL Server.

Grupo de disponibilidade "Always On"

Se sua instância do SQL Server fizer parte de um grupo de disponibilidade Always On, você poderá usar um dos seguintes métodos para criar seu certificado:

• Método 1: Use um certificado em todas as réplicas do grupo de disponibilidade. O nome comum é arbitrário, portanto, pode ser qualquer valor substituível. O nome do host e o FQDN de todas as réplicas do SQL Server no grupo de disponibilidade, bem como os nomes de ouvinte do grupo de disponibilidade, devem ser incluídos no Nome Alternativo da Entidade do certificado. Se réplicas adicionais forem adicionadas ao grupo de disponibilidade depois que o certificado original for gerado, o certificado deverá ser regenerado com os nomes de todas as réplicas e reimportado para cada réplica. O certificado também deve ser importado para o armazenamento de certificados em todos os clientes que se conectam à réplica do grupo de disponibilidade ou ao ouvinte do grupo de disponibilidade, a menos que o certificado seja assinado por uma autoridade de certificação (CA) pública ou oficial. Se você não incluir as réplicas do grupo de disponibilidade e os nomes de ouvinte no certificado, precisará incluir um dos valores do Nome Alternativo da Entidade no HostNameInCertificate ou o caminho para o certificado nos ServerCertificate valores da cadeia de conexão ao se conectar ao grupo de disponibilidade. Especificar nomes no certificado é a abordagem recomendada.

  Veja a seguir um exemplo das propriedades que definem um certificado configurado corretamente para um grupo de disponibilidade com dois servidores nomeados test1.<your company>.com e test2.<your company>.com, e um ouvinte de grupo de disponibilidade chamado aglistener.<your company>.com:

  CN = <hostname is recommended but not required when certificates are configured using SQL Server Configuration Manager>
  DNS Name = aglistener.<your company>.com 
  DNS Name = test1.<your company>.com
  DNS Name = test2.<your company>.com
  DNS Name = aglistener
  DNS Name = test1
  DNS Name = test2
  

• Método 2: Use um certificado separado para cada réplica do grupo de disponibilidade. Adicionar réplicas a um grupo de disponibilidade depois que um certificado é gerado é mais fácil ao usar certificados separados, pois você só precisa gerar um certificado para a nova réplica, em vez de modificar todos os certificados em todas as réplicas existentes. O nome comum é arbitrário, portanto, pode ser qualquer valor substituível. O nome do host e o FQDN da respetiva instância do SQL Server e os nomes de ouvinte do grupo de disponibilidade devem ser incluídos no Nome Alternativo da Entidade do certificado para cada réplica respetiva. Importe cada certificado para sua respetiva réplica e, a menos que o certificado seja assinado por uma Autoridade de Certificação (CA) pública ou oficial, importetodos os certificados para todos os armazenamentos de certificados em todos os clientes que se conectam às réplicas ou ouvinte do grupo de disponibilidade.

  A seguir estão exemplos das propriedades que definem certificados configurados corretamente para um grupo de disponibilidade com duas instâncias nomeadas test1.<your company>.com e test2.<your company>.com, e um ouvinte de grupo de disponibilidade chamado aglistener.<your company>.com:

  Certificado do teste1:

  CN= <hostname is recommended but not required when certificates are configured using SQL Server Configuration Manager>
  DNS Name= test1.<your company>.com 
  DNS Name= aglistener.<your company>.com
  DNS Name= aglistener
  DNS Name= test1
  

  Certificado em test2

  CN= <hostname is recommended but not required when certificates are configured using SQL Server Configuration Manager>
  DNS Name= test2.<your company>.com 
  DNS Name= aglistener.<your company>.com 
  DNS Name= aglistener
  DNS Name= test2 
  

Instância de cluster de tolerância a falhas

Se o SQL Server estiver configurado como uma instância de cluster de failover, você deverá instalar o certificado do servidor com o nome do host ou o FQDN (nome DNS totalmente qualificado) do servidor virtual em todos os nós do cluster de failover. e os certificados devem ser provisionados em todos os nós do cluster de failover. Por exemplo, se você tiver um cluster de dois nós, com nós nomeados test1.<your company>.com e test2.<your company>.com, e tiver um servidor virtual chamado virtsql, precisará instalar um certificado para virtsql.<your company>.com em ambos os nós.

Importe o certificado para o cluster de failover na sequência documentada em Configurar o Mecanismo de Banco de Dados do SQL Server para criptografar conexões.

Veja a seguir um exemplo das propriedades que definem um certificado configurado corretamente para uma instância de cluster de failover:

CN = virtsql.<your company>.com
DNS Name = virtsql.<your company>.com
DNS Name = virtsql

Para obter mais informações sobre clusters SQL, consulte Antes de instalar o cluster de alta disponibilidade.

Verificar se um certificado cumpre os requisitos

No SQL Server 2019 (15.x) e versões posteriores, o SQL Server Configuration Manager valida automaticamente todos os requisitos de certificado durante a própria fase de configuração. Se o SQL Server for iniciado com êxito depois de configurar um certificado, é uma boa indicação de que o SQL Server pode usar esse certificado. Mas alguns aplicativos cliente ainda podem ter outros requisitos para certificados que podem ser usados para criptografia, e você pode enfrentar erros diferentes, dependendo do aplicativo que está sendo usado. Nesse cenário, você precisa verificar a documentação de suporte do aplicativo cliente para obter mais informações sobre o assunto.

Você pode usar um dos seguintes métodos para verificar a validade do certificado para uso com o SQL Server:

• sqlcheck tool: sqlcheck é uma ferramenta de linha de comando que examina as configurações atuais do computador e da conta de serviço e produz um relatório de texto para a janela Console que é útil para solucionar vários erros de conexão. A saída tem as seguintes informações sobre certificados:

  Details for SQL Server Instance: This Certificate row in this section provides more details regarding the certificate being used by SQL Server (Self-generated, hard-coded thumbprint value, etc.).
  
  Certificates in the Local Computer MY Store: This section shows detailed information regarding all the certificates found in the computer certificate store.
  

  Para obter mais informações sobre os recursos da ferramenta e instruções de download, consulte Bem-vindo ao wiki CSS_SQL_Networking_Tools.

• ferramenta certutil: certutil.exe é um programa de linha de comando, instalado como parte dos Serviços de Certificados. Você pode usar certutil.exe para despejar e exibir informações de certificado. Use a -v opção para obter informações detalhadas. Para obter mais informações, consulte certutil.

• Snap-in de certificados: também pode usar a janela do snap-in de Certificados para exibir mais informações sobre certificados em vários repositórios de certificados no computador. Mas esta ferramenta não mostra KeySpec informações. Para obter mais informações sobre como exibir certificados com o snap-in do MMC, consulte Como exibir certificados com o snap-in do MMC.

Importar um certificado com um nome diferente para o nome do host

Atualmente, você só pode importar um certificado usando o SQL Server Configuration Manager se o nome do assunto do certificado corresponder ao nome do host do computador.

Se pretender utilizar um certificado com um nome de entidade diferente, siga estes passos:

1. Importe o certificado para o repositório de certificados do computador local utilizando o Snap-in Certificados.

2. No SQL Server Configuration Manager, expanda Configuração de Rede do SQL Server, clique com o botão direito sobre a instância do SQL Server e escolha Propriedades para abrir a caixa de diálogo Protocolos para <instance_name> Propriedades.

3. No separador Certificado, selecione o certificado que importou para o repositório de certificados na lista suspensa Certificado:

   

Importar um certificado com um nome diferente para o nome do host resulta na seguinte mensagem de erro:

The selected certificate name does not match FQDN of this hostname. This property is required by SQL Server
Certificate name: random-name
Computer name: sqlserver.domain.com

Certificados expirados

O SQL Server só verifica a validade dos certificados no momento da configuração. Por exemplo, você não pode usar o SQL Server Configuration Manager no SQL Server 2019 (15.x) e versões posteriores para provisionar um certificado expirado. O SQL Server continuará a ser executado sem problemas se o certificado expirar depois de já ter sido provisionado. Mas, alguns aplicativos cliente, como o Power BI, verificam a validade do certificado em cada conexão e geram um erro se a instância do SQL Server estiver configurada para usar um certificado expirado para criptografia. Recomendamos que você não use um certificado expirado para criptografia do SQL Server.

Próximo passo

• Configure o Mecanismo de Banco de Dados do SQL Server para criptografar conexões importando um certificado.

Conteúdo relacionado

• Suporte para TLS 1.3
• Configurar o TLS 1.3