Partage via

Connecter des clients avec la sécurité TLS à votre base de données

Aperçu

Les connexions entre vos applications clientes et le serveur de base de données sont toujours chiffrées à l’aide du protocole TLS (Transport Layer Security), précédemment appelé SSL (Secure Sockets Layer).

Note

PostgreSQL open source utilise le nom SSL hérité dans ses commandes, variables et documentation pour éviter d’interrompre les implémentations existantes. Ce document utilise l’acronyme TLS lors de l’utilisation du protocole SSL dans les noms de commandes et les variables.

Azure Database pour PostgreSQL prend en charge les connexions chiffrées à l’aide de TLS 1.2 et 1.3. Toutes les connexions entrantes qui tentent de chiffrer le trafic à l’aide de TLS 1.0 et TLS 1.1 sont refusées.

Par défaut, la connectivité sécurisée entre le client et le serveur est appliquée. Si vous souhaitez désactiver l'application de TLS, en autorisant les communications client chiffrées et non chiffrées, vous pouvez modifier le paramètre de serveur require_secure_transport en OFF. Vous pouvez également définir la version TLS en définissant le paramètre de serveur ssl_max_protocol_version. Nous vous déconseillons vivement de désactiver TLS.

Important

Nous avons démarré une rotation des certificats TLS pour Azure Database pour PostgreSQL afin de mettre à jour de nouveaux certificats d’autorité de certification intermédiaires et la chaîne de certificats résultante. Les autorités de certification racines restent les mêmes.

Aucune action n’est requise si votre configuration client implémente les configurations recommandées pour TLS.

Planification de la rotation des certificats

  • Les régions Azure USA Centre Ouest, Asie Est et Royaume-Uni Sud ont démarré leur rotation des certificats TLS le 11 novembre 2025.
  • À compter du 19 janvier 2026, cette rotation des certificats est prévue pour s’étendre aux régions restantes (à l’exception de la Chine), y compris Azure Government.
  • Après le Festival de printemps (Nouvel an chinois) 2026, les régions chinoises effectueront également une rotation de certificats qui inclut une modification de l’une des autorités de certification racine.

Configuration TLS du client

Par défaut, PostgreSQL n’effectue aucune vérification du certificat de serveur. Pour cette raison, il est possible d’usurper l’identité d’un serveur (par exemple, en modifiant un enregistrement DNS ou en prenant l’adresse IP du serveur) sans que le client le sache. Pour empêcher cette usurpation d’identité, la vérification du certificat TLS sur le client doit être utilisée.

Il existe de nombreux paramètres de connexion pour configurer le client pour TLS. En voici quelques-uns qui sont importants :

  • ssl: Se connecter à l’aide de TLS. Cette propriété n’a pas besoin d’une valeur associée. La simple présence de celui-ci spécifie une connexion TLS. Pour la compatibilité avec les futures versions, la valeur true est préférable. Dans ce mode, lorsque vous établissez une connexion TLS, le pilote client valide l’identité du serveur pour empêcher les attaques man-in-the-middle.

  • sslmode : si vous avez besoin d’un chiffrement et souhaitez que la connexion échoue si elle ne peut pas être chiffrée, définissez sslmode=require. Ce paramètre garantit que le serveur est configuré pour accepter les connexions TLS pour cette adresse hôte/IP et que le serveur reconnaît le certificat client. Si le serveur n’accepte pas les connexions TLS ou si le certificat client n’est pas reconnu, la connexion échoue. Le tableau suivant répertorie les valeurs de ce paramètre :

    sslmode Explanation
    disable Le chiffrement n’est pas utilisé. Azure Database pour PostgreSQL nécessite des connexions TLS ; par conséquent, ce paramètre ne doit pas être utilisé.
    allow Le chiffrement est utilisé si les paramètres du serveur l’exigent ou l’appliquent. Azure Database pour PostgreSQL nécessite des connexions TLS ; par conséquent, ce paramètre équivaut à prefer.
    prefer Le chiffrement est utilisé si les paramètres de serveur l’autorisent. Azure Database pour PostgreSQL nécessite des connexions TLS.
    require Le chiffrement est utilisé. Il garantit que le serveur est configuré pour accepter les connexions TLS.
    verify-ca Le chiffrement est utilisé. Vérifiez le certificat de serveur par rapport aux certificats racines approuvés stockés sur le client.
    verify-full Le chiffrement est utilisé. Vérifiez le certificat de serveur par rapport au certificat stocké sur le client. Il valide également que les certificats de serveur utilisent le même nom d’hôte que la connexion. Nous vous recommandons ce paramètre, sauf si les résolveurs DNS privés utilisent un autre nom pour référencer le serveur Azure Database pour PostgreSQL.

Le mode par défaut sslmode utilisé est différent entre les clients basés sur libpq (tels que PSQL et JDBC). Les clients libpq utilisent par défaut prefer. JDBC clients utilisent par défaut verify-full.

  • sslcert, sslkey et sslrootcert : ces paramètres peuvent remplacer l’emplacement par défaut du certificat client, la clé client PKCS-8 et le certificat racine. Ils sont par défaut /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8et /defaultdir/root.crt, respectivement, où defaultdir se trouve ${user.home}/.postgresql/ dans les systèmes Linux et %appdata%/postgresql/ sur Windows.

Important

Certaines des bibliothèques de client Postgres, lors de l’utilisation du paramètre sslmode=verify-full, peuvent rencontrer des échecs de connexion avec des certificats d’autorité de certification racine qui sont signés avec des certificats intermédiaires. Le résultat est la présence d’autres chemins d’accès d’approbation. Dans ce cas, nous vous recommandons de spécifier explicitement le paramètre sslrootcert. Ou alors, modifiez la valeur par défaut (PGSSLROOTCERT) de la variable d’environnement %APPDATA%\postgresql\root.crt et affectez-lui un chemin d’accès local où le certificat d’autorité de certification racine Microsoft RSA Root CA 2017 est placé.

Installer les autorités de certification de base approuvées

Télécharger et convertir des certificats CA racine

Pour les clients Windows qui utilisent le magasin de certificats système pour les certificats racines approuvés, aucune action n’est nécessaire, car Windows déploie de nouveaux certificats d’autorité de certification racine via Windows Update.

Pour les clients Java, l’extension de Visual Studio Code et d’autres clients (par exemple, PSQLPerl, ...) n’utilisant pas le magasin système, et les clients fonctionnant sous Linux, vous devez télécharger et combiner les certificats d'autorité racine dans un fichier PEM. Inclut, au minimum, les certificats d’autorité de certification racine suivants :

Note

Pour les régions de Chine et pour les clients disposant d’extensions de rotation : l’autorité de certification racine globale Digicert (fichier pem) est toujours valide ; incluez-le dans le fichier PEM combiné.

Nous vous recommandons vivement d’inclure tous les certificats d’autorité de certification racine Azure pour réduire la nécessité de mises à jour ultérieures du fichier combiné s’il existe des modifications apportées aux autorités de certification racines utilisées par Azure Database pour PostgreSQL. La liste des certificats d’autorité de certification racine Azure se trouve dans les détails de l’autorité de certification Azure.

Pour importer des certificats dans des magasins de certificats clients, vous devrez peut-être convertir les certificats de format CRT au format PEM et concaténer les fichiers PEM en un seul fichier. Vous pouvez utiliser l’utilitaire OpenSSL X509 pour convertir les fichiers CRT en PEM.

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

Combiner les certificats d’autorité de certification racine dans un seul fichier PEM

Pour certains clients, vous concatènez tous les fichiers PEM en un seul fichier à l’aide d’un éditeur de texte ou d’un outil en ligne de commande.

-----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-----

Pour les régions de Chine et pour les clients avec des extensions de rotation :

-----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-----

Combiner et mettre à jour des certificats d’autorité de certification racine pour les applications Java

Les applications Java écrites personnalisées utilisent un magasin de clés par défaut, appelé cacerts, qui contient des certificats d’autorité de certification approuvées. Un fichier de certificats nommé cacerts réside dans le répertoire des propriétés de sécurité, java.home\lib\security, où java.home est le répertoire de l’environnement d’exécution (répertoire jre du Kit de développement logiciel (SDK) ou le répertoire de niveau supérieur de l’environnement runtime Java™ 2. Vous pouvez utiliser les instructions suivantes pour mettre à jour les certificats d’autorité de certification racine du client pour les scénarios d’épinglage de certificats clients avec le PostgreSQL :

  1. Vérifiez le cacerts magasin de clés Java pour voir s’il contient déjà des certificats requis. Vous pouvez répertorier les certificats dans le magasin de clés Java à l’aide de la commande suivante :

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

    Si les certificats nécessaires ne sont pas présents dans le magasin de clés Java sur le client, comme vous pouvez le vérifier, vous devez suivre les instructions suivantes :

  2. Effectuez une copie de sauvegarde de votre magasin de clés personnalisé.

  3. Téléchargez les fichiers de certificat et enregistrez-les localement où vous pouvez les référencer.

  4. Générez un magasin de certificats CA combiné, avec tous les certificats CA racine nécessaires inclus. L’exemple ci-dessous montre l’utilisation de DefaultJavaSSLFactory pour les utilisateurs Java 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

...

Mettre à jour les certificats d’autorité de certification racine dans Azure App Services

Pour les services Azure App, en vous connectant à une instance de serveur flexible Azure Database pour PostgreSQL, nous pouvons avoir deux scénarios possibles sur la mise à jour des certificats clients et cela dépend de la façon dont vous utilisez SSL avec votre application déployée sur Azure App Services.

  • De nouveaux certificats sont ajoutés à App Service au niveau de la plateforme avant que les modifications ne se produisent dans votre instance de serveur flexible Azure Database pour PostgreSQL. Si vous utilisez les certificats SSL inclus sur la plateforme App Service dans votre application, aucune action n’est nécessaire. Pour plus d’informations, consultez Ajouter et gérer des certificats TLS/SSL dans Azure App Service, dans la documentation Azure App Service.
  • Si vous incluez explicitement le chemin d’accès au fichier de certificat SSL dans votre code, vous devez télécharger le nouveau certificat et mettre à jour le code pour l’utiliser.

Mettre à jour les certificats d’autorité de certification racine lors de l’utilisation des clients dans Azure Kubernetes Service (AKS)

Si vous essayez de vous connecter à Azure Database pour PostgreSQL à l’aide d’applications hébergées dans Azure Kubernetes Services (AKS), il est similaire à l’accès à partir de l’environnement hôte d’un client dédié. Consultez des instructions détaillées dans la documentation AKS.

Mettre à jour les certificats d’autorité de certification racine pour les utilisateurs .NET (Npgsql) sur Windows

Pour les utilisateurs .NET (Npgsql) sur Windows, se connectant à des instances de serveur flexible Azure Database pour PostgreSQL, vérifiez que tous les certificats d’autorité de certification racine sont inclus dans le Magasin de certificats Windows, autorités de certification racines approuvées. Windows Update gère la liste d’autorité de certification racine Azure standard. Si des certificats répertoriés dans notre configuration recommandée ne sont pas inclus, importez les certificats manquants.

Comment utiliser TLS avec la validation de certificat

Certaines infrastructures d’application qui utilisent PostgreSQL pour leurs services de base de données n’activent pas TLS par défaut pendant l’installation. Votre instance Azure Database pour PostgreSQL applique des connexions TLS, mais si l’application n’est pas configurée pour TLS, l’application risque d’échouer. Consultez la documentation de votre application pour savoir comment activer les connexions TLS.

Se connecter à l’aide de PSQL

L’exemple suivant montre comment se connecter à votre serveur à l’aide de l’interface PSQL de ligne de commande. Utilisez le paramètre de chaîne de connexion sslmode=verify-full ou sslmode=verify-ca pour appliquer la vérification des certificats TLS. Passez le chemin d’accès du fichier de certificat local au paramètre sslrootcert.

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

Tester la connectivité TLS

Avant d’essayer d’accéder à votre serveur compatible TLS à partir d’une application cliente, assurez-vous que vous pouvez y accéder via PSQL. Si vous avez établi une connexion TLS, vous devez voir une sortie similaire à l’exemple suivant :

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

Vous pouvez également charger l’extension sslinfo , puis appeler la ssl_is_used() fonction pour déterminer si TLS est utilisé. La fonction retourne t si la connexion utilise TLS. Sinon, fest retourné.

Obtenir la liste des certificats approuvés dans le magasin de clés Java par programmation

Par défaut, Java stocke les certificats approuvés dans un fichier spécial nommé cacerts situé dans le dossier d’installation Java sur le client. L’exemple ci-dessous lit cacerts et charge le fichier dans l’objet 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;
}

Le mot de passe cacerts par défaut est changeit , mais doit être différent sur le client réel, car les administrateurs recommandent de modifier le mot de passe immédiatement après l’installation de Java. Une fois que nous avons chargé l’objet KeyStore , nous pouvons utiliser la classe PKIXParameters pour lire les certificats présents.

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());
}

Contenu connexe

  • Last updated on