Partager via

Mettre à jour les certificats TLS client pour les clients d’application avec Azure Database pour PostgreSQL - Serveur flexible

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL : serveur flexible

Importer des certificats d’autorité de certification racine dans le magasin de clés Java sur le client pour les scénarios d’épinglage de certificats

Les applications Java écrites de façon personnalisées utilisent un magasin de clés par défaut, appelé cacerts, qui contient des certificats d’autorité de certification (CA) approuvée. Elle est également connue sous le nom de magasin d’approbation 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 d’environnement d’exécution (répertoire jre dans le 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 serveur flexible PostgreSQL :

  1. Vérifiez si le magasin de clés Java cacerts contient déjà les certificats requis. Vous pouvez répertorier les certificats dans un magasin de clés Java en utilisant la commande suivante :
  keytool -list -v -keystore ..\lib\security\cacerts > outputfile.txt

Si les certificats requis ne sont pas présents dans le magasin de clés Java sur le client, car ils peuvent être archivés dans la sortie, vous devez suivre les instructions suivantes :

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

  2. Téléchargez les certificats et enregistrez-les dans un emplacement local référençable.

  3. Générez un magasin de certificats d’autorité de certification combiné qui comprend tous les AC racine nécessaires. 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

  4. 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");

  5. Remplacez le fichier .pem d’origine de l’autorité de certification racine 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.

Remarque

Pour importer des certificats dans des magasins de certificats clients, vous allez peut-être devoir convertir des fichiers de certificat du format .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 programme

Comme indiqué ci-dessus, Java, par défaut, stocke les certificats approuvés dans un fichier spécial nommé cacerts qui se trouve dans le dossier d’installation Java sur le client. L’exemple ci-dessous lit d’abord cacerts et le charge 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 par défaut pour cacerts 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 d’autorité de certification racine lors de l’utilisation de clients dans Azure App Services avec Azure Database pour PostgreSQL - Serveur flexible pour les scénarios d’épinglage de certificats

Pour les services Azure App qui se connectent à Azure Database pour PostgreSQL, deux scénarios sur la mise à jour des certificats client sont possibles et dépendent de la façon dont vous utilisez SSL avec votre application déployée vers les services Azure App.

  • De nouveaux certificats sont ajoutés à App Service au niveau de la plateforme avant les modifications apportées à Azure Database pour PostgreSQL - Serveur flexible. Si vous utilisez les certificats SSL inclus sur la plateforme App Service dans votre application, aucune action n’est nécessaire. Consultez la documentation relative à Azure App Service suivante pour plus d’informations.
  • 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 de façon à ce qu’il utilise le nouveau certificat. Un bon exemple de ce scénario est lorsque vous utilisez des conteneurs personnalisés dans App Service de la manière décrite dans la documentation d’App Service

Mettre à jour les certificats d’autorité de certification racine lors de l’utilisation de clients dans Azure Kubernetes Services (AKS) avec Azure Database pour PostgreSQL - Serveur flexible pour les scénarios d’épinglage de certificats

Si vous essayez de vous connecter au serveur Azure Database pour PostgreSQL à l’aide d’applications hébergées dans Azure Kubernetes Services (AKS) et l’épinglage de certificats, cela est similaire à un accès à partir d’un environnement d’hôte de clients dédié. Reportez-vous aux étapes indiquées ici.

Mise à jour des certificats d’autorité de certification racine pour les utilisateurs .NET (Npgsql) sur Windows avec Azure Database pour PostgreSQL - Serveur flexible pour les scénarios d’épinglage de certificats

Pour les utilisateurs .NET (Npgsql) sur Windows qui se connectent à Azure Database pour PostgreSQL - Serveurs flexibles, veillez à ce que les trois certificats (Microsoft RSA Root Certificate Authority 2017, DigiCert Global Root G2 et l’AC racine global Digicert) existent dans le Magasin de certificats Windows et (autorités de certification racines de confiance). S’il n’existe aucun certificat, importez le certificat manquant.

Mise à jour des certificats d’autorité de certification racine pour d’autres clients pour les scénarios d’épinglage de certificats

Les autres utilisateurs du client PostgreSQL peuvent fusionner deux fichiers de certificat d’autorité de certification comme ci-dessous.



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

Contenu connexe