Mettre à jour les certificats clients d’application dans Azure HorizonDB (préversion)

Lorsque vous connectez des applications à Azure HorizonDB, 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, ce qui est un scénario courant pour les applications qui se connectent à une instance horizonDB Azure.

Importer des certificats d’autorité de certification racine dans le magasin de clés Java côté client, pour les scénarios de verrouillage de certificat

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 Java magasin de clés à 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 du client, comme vous pouvez le constater dans la sortie, suivez 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 Transport Layer Security (TLS) dans Azure HorizonDB (préversion).

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 d’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 Services se connectant à une instance Azure HorizonDB, deux scénarios sont possibles concernant la mise à jour des certificats clients, et cela dépend de la manière 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 HorizonDB Azure. 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 d’autorité de certification racine lors de l’utilisation de clients dans Azure Kubernetes Service (AKS), pour les scénarios d’épinglage de certificat

Si vous essayez de vous connecter à Azure HorizonDB à l’aide d’applications hébergées dans Azure Kubernetes Services (AKS) avec épinglage des certificats, cela est similaire à un accès depuis l’environnement hôte d’un 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) sous Windows se connectant à Azure HorizonDB, veillez à ce que ces trois autorités Autorité de certification racine Microsoft RSA 2017, DigiCert Global Root G2 et DigiCert Global Root CA existent bien dans le magasin de certificats Windows, Autorités de certification racine de confiance. Si aucun certificat n’existe, importez le certificat manquant.

Mettre à jour les certificats d’autorité de certification racine pour d’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-----

Secure your Azure HorizonDB (preview)

Commentaires

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

Last updated on 2026-07-07