Mettre à jour les certificats du client d’application

Lors de la connexion d’applications à Azure Database pour PostgreSQL, le client d’application doit installer des certificats racines approuvés. Les sections suivantes vous guident tout au long de la mise à jour des certificats racines approuvés pour les applications, qui est un scénario courant pour les applications qui se connectent à une instance de serveur flexible Azure Database pour PostgreSQL.

Important

Microsoft effectue la rotation des certificats TLS pour Azure Database pour PostgreSQL afin de mettre à jour l’autorité de certification et la chaîne de certificats résultante.

Si votre configuration client utilise les configurations recommandées pour TLS, vous n’avez pas besoin d’agir.

Planification de rotation des certificats intermédiaires :

Les mises à jour des régions Azure USA Centre Ouest et Asie Est sont terminées.
Les mises à jour pour les régions du Royaume-Uni sud et du gouvernement des États-Unis commencent le 21 janvier 2026.
Les mises à jour pour les États-Unis centre commencent le 26 janvier 2026.
Les mises à jour de toutes les autres régions commencent le 28 janvier 2026.

Planification de rotation des certificats racine :

Les mises à jour des certificats d’autorité de certification racine de DigiCert Global Root CA (G1) à DigiCert Global Root G2 dans les régions chinoises débuteront le 9 mars 2026.

Importer les certificats de CA racine dans le magasin de clés Java sur le client, pour les scénarios d'épinglage de certificats

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. Elle est également connue sous le nom de magasin de confiance Java. 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 :

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 :
Effectuez une copie de sauvegarde de votre magasin de clés personnalisé.
Téléchargez des certificats et enregistrez-les localement où vous pouvez les référencer.

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 JDBC PostgreSQL.

    keytool -importcert -alias PostgreSQLServerCACert  -file D:\ DigiCertGlobalRootG2.crt.pem   -keystore truststore -storepass password -noprompt

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

    keytool -importcert -alias PostgreSQLServerCACert  -file D:\ DigiCertGlobalRootCA.crt.pem   -keystore truststore -storepass password -noprompt

Remplacez le fichier de magasin de clés d’origine par le nouveau fichier généré :

System.setProperty("javax.net.ssl.trustStore","path_to_truststore_file");
System.setProperty("javax.net.ssl.trustStorePassword","password");

Remplacez le fichier pem d’autorité de certification racine d’origine par le fichier d’autorité de certification racine combiné et redémarrez votre application/client.

Pour plus d’informations sur la configuration des certificats clients avec le pilote JDBC PostgreSQL, consultez cette documentation.

Note

Pour importer des certificats dans des magasins de certificats clients, vous devrez peut-être convertir des fichiers de certificats .crt au format .pem. Vous pouvez utiliser l’utilitaire OpenSSL pour effectuer ces conversions de fichiers.

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

Mettre à jour les certificats de l'autorité de certification racine lors de l'utilisation de clients dans Azure App Services, pour les scénarios d’épinglage de certificat

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. Un bon exemple de ce scénario est que vous utilisez des conteneurs personnalisés dans App Service, comme décrit dans le tutoriel : Configurer un conteneur side-car pour un conteneur personnalisé dans Azure App Service, dans la documentation Azure App Service.

Mettre à jour les certificats de CA racine lors de l'utilisation de clients dans Azure Kubernetes Service (AKS), pour les scénarios d'épinglage de certificats

Si vous essayez de vous connecter à Azure Database for PostgreSQL en utilisant des applications hébergées dans Azure Kubernetes Services (AKS) et l'épinglage de certificats, ce processus s'apparente à un accès depuis un environnement client dédié. Reportez-vous aux étapes ci-dessous.

Mettre à jour les certificats d'autorité de certification racine pour les utilisateurs .NET (Npgsql) sur Windows, pour les scénarios d'épinglage de certificat

Pour les utilisateurs .NET (Npgsql) sur Windows qui se connectent à Azure Database pour des instances de serveurs flexibles PostgreSQL, veillez à ce que les trois certificats (Microsoft RSA Root Certificate Authority 2017, DigiCert Global Root G2 et Digicert Global Root CA) existent dans le Magasin de certificats Windows, Autorités de certification racines de confiance. Si aucun certificat n’existe, importez le certificat manquant.

Mettre à jour les certificats de CA racine pour les autres clients, pour les scénarios d'épinglage de certificats

Pour les autres utilisateurs clients PostgreSQL, vous pouvez fusionner deux fichiers de certificat d’autorité de certification au format suivant :

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

Sécurité dans Azure Database pour PostgreSQL

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-02-18