Compartilhar via

Conecte clientes com segurança TLS ao banco de dados

As conexões entre seus aplicativos cliente e o servidor de banco de dados sempre usam criptografia com o TLS (Transport Layer Security) padrão do setor, anteriormente conhecido como SSL (Secure Sockets Layer).

Observação

O PostgreSQL de código aberto usa o nome herdado SSL em seus comandos, variáveis e documentação para evitar o rompimento de implementações existentes. Este artigo usa o acrônimo TLS ao usar SSL em nomes de comando e variáveis.

O Banco de Dados do Azure para PostgreSQL dá suporte a conexões criptografadas usando o TLS 1.2 e 1.3. O servidor nega todas as conexões de entrada que tentam criptografar o tráfego usando o TLS 1.0 e o TLS 1.1.

Por padrão, o servidor impõe conectividade segura entre o cliente e o servidor. Para desabilitar essa imposição e permitir comunicações de cliente criptografadas e não criptografadas, altere o parâmetro require_secure_transport do servidor para OFF. Você também pode definir a versão do TLS definindo o parâmetro do ssl_max_protocol_version servidor. Não desabilite TLS.

Importante

A Microsoft iniciou uma rotação de certificados TLS para o Banco de Dados do Azure para PostgreSQL para atualizar certificados de autoridade certificadora intermediária e a cadeia de certificação resultante. Os CAs raiz permanecem os mesmos.

Se a configuração do cliente usar as configurações recomendadas para TLS, você não precisará executar nenhuma ação.

Programação de rotação de certificado

  • As regiões do Azure Centro-Oeste dos EUA, Leste da Ásia e Sul do Reino Unido iniciaram sua rotação de certificados TLS em 11 de novembro de 2025.
  • A partir de 19 de janeiro de 2026, essa rotação de certificados está prevista para se estender para as regiões restantes (exceto a China), incluindo o Azure Government.
  • Após o Festival da Primavera (Ano Novo Chinês) de 2026, as regiões da China também passarão por uma rotação de certificados que inclui uma mudança em um dos ACs raiz.

Configuração do TLS do cliente

Por padrão, o PostgreSQL não verifica o certificado do servidor. Devido a esse comportamento padrão, o cliente não poderá detectar se a identidade do servidor é falsificada (por exemplo, se alguém modificar um registro DNS ou assumir o endereço IP do servidor). Para evitar esse tipo de falsificação, habilite a verificação de certificado TLS no cliente.

Você pode configurar muitos parâmetros de conexão para a configuração do TLS do cliente. Algumas importantes incluem:

  • ssl: conecte-se usando O TLS. Essa propriedade não precisa de um valor. Sua presença especifica uma conexão TLS. Para compatibilidade com versões futuras, use o valor true. Nesse modo, quando você estabelece uma conexão TLS, o driver cliente valida a identidade do servidor para evitar ataques man-in-the-middle.

  • sslmode: defina esse parâmetro para require se você precisar de criptografia e quiser que a conexão falhe se ela não puder ser criptografada. Essa configuração garante que o servidor esteja configurado para aceitar conexões TLS para esse host ou endereço IP e que o servidor reconheça o certificado do cliente. Se o servidor não aceitar conexões TLS ou o certificado do cliente não for reconhecido, a conexão falhará. A tabela a seguir lista os valores para essa configuração:

    sslmode Explanation
    disable A criptografia não é usada. O Banco de Dados do Azure para PostgreSQL requer conexões TLS, portanto, não use essa configuração.
    allow A criptografia será usada se as configurações do servidor a exigirem ou aplicá-la. O Banco de Dados do Azure para PostgreSQL requer conexões TLS, portanto, essa configuração é equivalente a prefer.
    prefer A criptografia será usada se as configurações do servidor permitirem isso. O Banco de Dados do Azure para PostgreSQL requer conexões TLS.
    require A criptografia é usada. Ele garante que o servidor esteja configurado para aceitar conexões TLS.
    verify-ca A criptografia é usada. Verifique o certificado do servidor em relação aos certificados raiz confiáveis armazenados no cliente.
    verify-full A criptografia é usada. Verifique o certificado do servidor no certificado armazenado no cliente. Ele também valida que os certificados do servidor usam o mesmo nome de host que a conexão. Use essa configuração, a menos que resolvedores DNS privados usem um nome diferente para fazer referência ao servidor do Banco de Dados do Azure para PostgreSQL.

O modo padrão sslmode difere entre clientes baseados em libpq (como PSQL e JDBC). Os clientes baseados em libpq usam prefer como padrão. JDBC clientes são configurados para usar verify-full.

  • sslcert, sslkeye sslrootcert: esses parâmetros substituem o local padrão do certificado do cliente, a chave do cliente PKCS-8 e o certificado raiz. Eles são padrão para /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8, e /defaultdir/root.crt, respectivamente, onde defaultdir corresponde a ${user.home}/.postgresql/ em sistemas Linux e a %appdata%/postgresql/ no Windows.

Importante

Algumas bibliotecas de clientes do Postgres podem falhar ao se conectar ao usar a configuração sslmode=verify-full com certificados de autoridade certificadora raiz que assinam certificações intermediárias entre sinais. Essa configuração resulta em caminhos de confiança alternativos. Nesse caso, especifique explicitamente o sslrootcert parâmetro. Ou defina a variável de ambiente PGSSLROOTCERT para um caminho local em que o certificado de AC raiz Microsoft RSA Root CA 2017 seja definido, do valor padrão de %APPDATA%\postgresql\root.crt.

Instalar autoridades de certificação raiz confiáveis (CAs)

Baixar e converter certificados de autoridade de certificação raiz (AC raiz)

Para clientes Windows que usam o repositório de certificados do sistema para certificados raiz confiáveis, nenhuma ação é necessária, pois o Windows implanta novos certificados de autoridade certificadora raiz por meio do Windows Update.

Para clientes Java, a extensão do VS Code e outros clientes (por exemplo, PSQL, Perl) que não utilizam o repositório do sistema, assim como para clientes no Linux, é necessário baixar e combinar os certificados de CA raiz em um arquivo PEM. No mínimo, inclua os seguintes certificados de autoridade certificadora (CA) raiz:

Observação

Para regiões da China e para clientes com extensões de rotação: a AC raiz global Digicert (arquivo PEM) ainda é válida; inclua-a no arquivo PEM combinado.

Inclua todos os certificados de CA raiz do Azure para reduzir a necessidade de atualizações futuras no arquivo combinado, caso haja alterações nos CAs raiz utilizados pelo Banco de Dados do Azure para PostgreSQL. Você pode encontrar a lista de certificados CA raiz do Azure nos detalhes da Autoridade de Certificação do Azure.

Para importar certificados para repositórios de certificados do cliente, talvez seja necessário converter todos os certificados de formato CRT no formato PEM e concatenar os arquivos PEM em um único arquivo. Você pode usar o utilitário OpenSSL X509 para converter os arquivos CRT em PEM.

openssl x509 -inform DER -in certificate-filename.crt -out certificate-filename.pem -outform PEM

Combinar certificados de CA raiz em um único arquivo PEM

Para alguns clientes, você concatena todos os arquivos PEM em um único arquivo usando qualquer editor de texto ou ferramenta de linha de comando.

-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

Para regiões da China e para clientes com extensões de rotação:

-----BEGIN CERTIFICATE-----
(Root CA0 content: DigiCertGlobalRootCA.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

Combinar e atualizar certificados de CA raiz para aplicativos Java

Os aplicativos Java personalizados usam um repositório de chaves padrão chamado cacerts, que contém certificados de autoridade de certificação confiável (AC). O arquivo de certificados cacerts está localizado no diretório de propriedades de segurança em java.home\lib\security, onde java.home é o diretório do ambiente de execução (o diretório jre no SDK ou o diretório raiz do Ambiente de Execução do Java™ 2). Para atualizar certificados de autoridade certificadora raiz do cliente para cenários de pinning de certificado do cliente com PostgreSQL, siga as seguintes instruções:

  1. Verifique o repositório cacerts de chaves Java para ver se ele já contém os certificados necessários. Você pode listar certificados no repositório de chaves Java usando o seguinte comando:

    keytool -list -v -keystore ..\lib\security\cacerts > outputfile.txt

    Se os certificados necessários não estiverem presentes no repositório de chaves Java no cliente, como você pode verificar na saída, prossiga com as seguintes instruções:

  2. Faça uma cópia de backup do repositório de chaves personalizado.

  3. Baixe os arquivos de certificado e salve-os localmente onde você pode referenciá-los.

  4. Gere um repositório de certificados de AC combinado que inclua todos os certificados de AC raiz necessários. O exemplo a seguir mostra o uso do DefaultJavaSSLFactory para usuários Java do PostgreSQL.

    keytool -importcert -alias PostgreSQLServerCACert  -file "DigiCertGlobalRootG2.crt.pem" -keystore truststore -storepass password -noprompt

keytool -importcert -alias PostgreSQLServerCACert2  -file "Microsoft ECC Root Certificate Authority 2017.crt.pem" -keystore truststore -storepass password  -noprompt

...

Atualizar Certificados de AC raiz nos Serviços de Aplicativos do Azure

Para os Serviços de Aplicativo do Azure se conectarem a uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, existem dois cenários possíveis para atualizar certificados de cliente. Os cenários dependem de como você está usando o SSL com seu aplicativo implantado nos Serviços de Aplicativo do Azure.

  • Adicione novos certificados ao Serviço de Aplicativo no nível da plataforma antes que ocorram alterações em sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. Se você estiver usando os certificados SSL incluídos na plataforma do Serviço de Aplicativo em seu aplicativo, nenhuma ação será necessária. Para obter mais informações, consulte Adicionar e gerenciar certificados TLS/SSL no Serviço de Aplicativo do Azure na documentação do Serviço de Aplicativo do Azure.
  • Se você estiver incluindo explicitamente o caminho para um arquivo de certificado SSL em seu código, será necessário baixar o novo certificado e atualizar o código para usá-lo.

Atualize os certificados de autoridade certificadora raiz ao usar clientes no Azure Kubernetes Service (AKS)

Se você estiver tentando se conectar ao Banco de Dados do Azure para PostgreSQL usando aplicativos hospedados no AKS (Serviços de Kubernetes do Azure), será semelhante ao acesso do ambiente de host de um cliente dedicado. Consulte as instruções detalhadas na documentação do AKS.

Atualizar certificados de CA Raiz para usuários do .NET (Npgsql) no Windows

Para usuários do .NET (Npgsql) no Windows que se conectam às instâncias de servidor flexível do Banco de Dados do Azure para PostgreSQL, verifique se todos os certificados de AC raiz estão incluídos no Repositório de Certificados do Windows em Autoridades de Certificação Raiz Confiáveis. Windows Update mantém a lista padrão de CAs raiz do Azure. Se os certificados listados na configuração recomendada não forem incluídos, importe os certificados ausentes.

Como usar o TLS com validação de certificado

Algumas estruturas de aplicativo que usam o PostgreSQL para seus serviços de banco de dados não habilitam o TLS por padrão durante a instalação. Sua instância do Banco de Dados do Azure para PostgreSQL impõe conexões TLS, mas se o aplicativo não estiver configurado para TLS, o aplicativo poderá falhar. Confira a documentação de seu aplicativo para saber como habilitar conexões TLS.

Conectar usando PSQL

O exemplo a seguir mostra como se conectar ao servidor usando a PSQL interface de linha de comando. Use a configuração de cadeia de conexão sslmode=verify-full ou sslmode=verify-ca para garantir a verificação de certificado TLS. Passe o caminho do arquivo de certificado local para o parâmetro sslrootcert.

 psql "sslmode=verify-full sslrootcert=<path-of-pem-file> host=mydemoserver.postgres.database.azure.com dbname=postgres user=myadmin"

Testar a conectividade do TLS

Antes de tentar acessar o servidor habilitado para TLS de um aplicativo cliente, verifique se você pode acessá-lo por meio de PSQL. Se você estabeleceu uma conexão TLS, deverá ver uma saída semelhante ao seguinte exemplo:

psql (14.5)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

Você também pode carregar a extensão sslinfo e, em seguida, chamar a ssl_is_used() função para determinar se o TLS está sendo usado. A função retornará t se a conexão estiver usando TLS. Caso contrário, ele retornará f.

Obter uma lista de certificados confiáveis no Repositório de Chaves Java programaticamente

Por padrão, o Java armazena os certificados confiáveis em um arquivo especial chamado cacerts que está localizado dentro da pasta de instalação java no cliente. O exemplo a seguir lê cacerts e carrega-o em um objeto KeyStore :

private KeyStore loadKeyStore() {
    String relativeCacertsPath = "/lib/security/cacerts".replace("/", File.separator);
    String filename = System.getProperty("java.home") + relativeCacertsPath;
    FileInputStream is = new FileInputStream(filename);
    KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
    String password = "changeit";
    keystore.load(is, password.toCharArray());

    return keystore;
}

A senha cacerts padrão é changeit, mas deve ser diferente em um cliente real. Os administradores recomendam alterar a senha imediatamente após a instalação do Java. Depois de carregar o objeto KeyStore , você poderá usar a classe PKIXParameters para ler os certificados presentes.

public void whenLoadingCacertsKeyStore_thenCertificatesArePresent() {
    KeyStore keyStore = loadKeyStore();
    PKIXParameters params = new PKIXParameters(keyStore);
    Set<TrustAnchor> trustAnchors = params.getTrustAnchors();
    List<Certificate> certificates = trustAnchors.stream()
      .map(TrustAnchor::getTrustedCert)
      .collect(Collectors.toList());

    assertFalse(certificates.isEmpty());
}

Conteúdo relacionado

  • Last updated on