Comprendre les modifications liées au changement d’autorité de certification racine pour le serveur unique Azure Database pour PostgreSQL

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL – Serveur unique versions

Important

Azure Database pour PostgreSQL - Serveur unique est en voie de mise hors service. Nous vous recommandons vivement de procéder à une mise à niveau vers un serveur flexible Azure Database pour PostgreSQL. Pour plus d’informations sur la migration vers le Serveur flexible Azure Database pour PostgreSQL, consultez l’article Qu’arrive-t-il au Serveur unique Azure Database pour PostgreSQL ?.

Azure Database pour PostgreSQL pour serveur unique prévoit un changement de certificat racine à partir de décembre 2022 (12/2022) dans le cadre de la maintenance standard et des meilleures pratiques de sécurité. Cet article fournit davantage de détails sur les changements, les ressources affectées et les étapes nécessaires pour garantir que votre application maintient sa connectivité à votre serveur de base de données.

Pourquoi la mise à jour du certificat racine est obligatoire ?

Historiquement, les utilisateurs Azure Database por PostgreSQL peuvent utiliser uniquement le certificat prédéfini pour se connecter à un serveur PostgreSQL, qui est situé ici. Toutefois, le forum Certificate Authority (CA) Browser a récemment publié des rapports indiquant que plusieurs certificats émis par les fournisseurs d’autorité de certification n’étaient pas conformes.

Conformément aux exigences de conformité du secteur, les fournisseurs d’autorité de certification ont commencé à révoquer les certificats d’autorité de certification non conformes, en demandant aux serveurs d’utiliser des certificats émis par des autorités de certification conformes et signés par des certificats d’autorité de certification provenant de ces dernières. Dans la mesure où Azure Database pour PostgreSQL utilisait l’un de ces certificats non conformes, nous avons dû remplacer le certificat par une version conforme afin de réduire la menace potentielle sur vos serveurs Postgres.

Le nouveau certificat est déployé et prend effet à compter de décembre 2022 (12/2022).

Quelle modification devait être effectuée à partir de décembre 2022 (12/2022) ?

À compter de décembre 2022, le certificat racine BaltimoreCyberTrustRoot est remplacé par une version conforme appelée « certificat racine DigiCertGlobalRootG2 ». Si vos applications tirent parti de verify-ca ou verify-full comme valeur du paramètre sslmode dans la connectivité du client de base de données, vous devez suivre les instructions pour ajouter de nouveaux certificats au magasin de certificats pour maintenir la connectivité.

Est-ce que je dois apporter des modifications à mon client pour maintenir la connectivité ?

Aucune modification de code ou d’application n’est requise côté client. Si vous avez suivi notre recommandation de mise à jour de certificat ci-dessous, vous pourrez toujours continuer à vous connecter tant que le certificat BaltimoreCyberTrustRoot n’est pas supprimé du certificat d’autorité de certification combiné. Nous vous recommandons de ne pas supprimer BaltimoreCyberTrustRoot de votre certificat d’autorité de certification combiné tant que vous n’y aurez pas été invité, afin de maintenir la connectivité.

Dois-je apporter des modifications aux certificats clients ?

Par défaut, PostgreSQL n’effectue aucune vérification du certificat de serveur. Cela signifie qu’il est toujours théoriquement possible d’usurper l’identité du 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 toute usurpation potentielle, la vérification du certificat SSL sur le client doit être utilisée. Cette vérification peut être définie via la valeur du ssl mode de la chaîne de connexion du client de l’application - verify-ca ou verify-full. Si ces valeurs de ssl-mode sont choisies, vous devez suivre les instructions de la section suivante.

Recommandation de mise à jour de certificat client

  • Téléchargez l’autorité de certification racine BaltimoreCyberTrustRootDigiCertGlobalRootG2 à partir des liens ci-dessous :

  • Si vous le souhaitez, pour éviter toute interruption future, il est également recommandé d’ajouter les racines suivantes au magasin approuvé :

  • Générez un magasin de certificats d’autorité de certification combiné où les certificats BaltimoreCyberTrustRoot et DigiCertGlobalRootG2 sont inclus.

    • Si vous utilisez Java (PostgreSQL JDBC) avec DefaultJavaSSLFactory, exécutez :

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

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

      Remplacez ensuite 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");

    • Si vous utilisez .NET (Npgsql) sous Windows, assurez-vous que Baltimore CyberTrust Root et DigiCert Global Root G2 existent dans le magasin de certificats Windows et dans les autorités de certification racines de confiance. S’il n’existe aucun certificat, importez le certificat manquant.

      Certificat .net Azure Database pour PostgreSQL

    • Si vous utilisez .NET (Npgsql) sur Linux avec SSL_CERT_DIR, assurez-vous que BaltimoreCyberTrustRoot et DigiCertGlobalRootG2 existent tous deux dans le répertoire indiqué par SSL_CERT_DIR. S’il n’existe aucun certificat, créez le fichier de certificat manquant.

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


      -----BEGIN CERTIFICATE-----
      (Root CA1: BaltimoreCyberTrustRoot.crt.pem)
      -----END CERTIFICATE-----
      -----BEGIN CERTIFICATE-----
      (Root CA2: DigiCertGlobalRootG2.crt.pem)
      -----END CERTIFICATE-----

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

  • Ensuite, après le déploiement du nouveau certificat côté serveur, vous pouvez remplacer votre fichier .pem d’autorité de certification par DigiCertGlobalRootG2.crt.pem.

Notes

Ne supprimez pas ni ne modifiez le certificat Baltimore tant que le changement de certificat n’est pas effectué. Nous enverrons une communication une fois la modification effectuée, après quoi il sera possible de supprimer le certificat Baltimore en toute sécurité.

Que se passe-t-il si nous avons supprimé le certificat BaltimoreCyberTrustRoot ?

Vous risquez de recevoir des erreurs lors de la connexion à votre serveur Azure Database pour PostgreSQL. Vous devez reconfigurer SSL avec le certificat BaltimoreCyberTrustRoot pour maintenir la connectivité.

Forum aux questions

1. Si je n’utilise pas SSL/TLS, dois-je quand même mettre à jour l’autorité de certification racine ?

Aucune action n’est requise si vous n’utilisez pas SSL/TLS.

2. Si j’utilise SSL/TLS, dois-je redémarrer mon serveur de base de données pour mettre à jour l’autorité de certification racine ?

Non, vous n’avez pas besoin de redémarrer le serveur de base de données pour commencer à utiliser le nouveau certificat. Il s’agit d’une modification côté client et les connexions clientes entrantes doivent utiliser le nouveau certificat pour s’assurer qu’elles peuvent se connecter au serveur de base de données.

3. Comment savoir si j’utilise SSL/TLS avec la vérification du certificat racine ?

Vous pouvez déterminer si vos connexions vérifient le certificat racine en examinant votre chaîne de connexion.

  • Si votre chaîne de connexion inclut sslmode=verify-ca ou sslmode=verify-full, vous devez mettre à jour le certificat.
  • Si votre chaîne de connexion inclut sslmode=disable, sslmode=allow, sslmode=prefer ou sslmode=require, vous n’avez pas besoin de mettre à jour les certificats.
  • Si votre chaîne de connexion ne spécifie pas sslmode, vous n’avez pas besoin de mettre à jour les certificats.

Si vous utilisez un client qui abstrait la chaîne de connexion, consultez la documentation du client pour savoir s’il vérifie les certificats. Pour comprendre PostgreSQL sslmode, consultez les descriptions du mode SSL dans la documentation PostgreSQL.

4. Quel est l’impact de l’utilisation d’App Service avec Azure Database pour PostgreSQL ?

Pour les services Azure App Service qui se connectent à Azure Database pour PostgreSQL, deux scénarios sont possibles et dépendent de la façon dont vous utilisez SSL avec votre application.

  • Ce nouveau certificat a été ajouté à App Service au niveau de la plateforme. Si vous utilisez les certificats SSL inclus sur la plateforme App Service dans votre application, aucune action n’est nécessaire.
  • 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 comme partagés dans ladocumentation App Service.

5. Quel est l’impact de l’utilisation d’Azure Kubernetes Services (AKS) avec Azure Database pour PostgreSQL ?

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

6. Quel est l’impact de l’utilisation d’Azure Data Factory pour se connecter à Azure Database pour PostgreSQL ?

Le connecteur qui utilise Azure Integration Runtime exploite les certificats du magasin de certificats Windows dans l’environnement hébergé par Azure. Comme ces certificats sont déjà compatibles avec les certificats récemment appliqués, aucune action n’est nécessaire.

Pour le connecteur qui utilise le runtime d’intégration auto-hébergé où vous incluez explicitement le chemin d’accès au fichier de certificat SSL dans votre chaîne de connexion, vous devez télécharger le nouveau certificat et mettre à jour la chaîne de connexion de façon à ce qu’elle l’utilise.

7. Dois-je prévoir un temps d’arrêt lié à la maintenance du serveur de base de données pour effectuer cette modification ?

Non. Étant donné que la modification est uniquement côté client pour la connexion au serveur de base de données, aucun temps d’arrêt lié à la maintenance n’est nécessaire pour le serveur de base de données lors de cette modification.

8. Si je crée un nouveau serveur après le 30 novembre 2022, est-ce que je serai affecté ?

Pour les serveurs créés après le 30 novembre 2022, vous continuerez à utiliser BaltimoreCyberTrustRoot avec de nouveaux certificats racines DigiCertGlobalRootG2 dans votre magasin de certificats SSL client de base de données pour que vos applications se connectent à l’aide de SSL.

9. Quelle est la fréquence à laquelle Microsoft met à jour ses certificats ou quelle est la stratégie d’expiration ?

Les certificats utilisés par Azure Database pour PostgreSQL sont fournis par des autorités de certification approuvées. Par conséquent, la prise en charge de ces certificats est liée à leur prise en charge par l’autorité de certification. L’expiration du certificat BaltimoreCyberTrustRoot est prévue pour 2025. Microsoft doit donc procéder à un changement de certificat avant l’expiration. De plus, en cas de bogues imprévus dans ces certificats prédéfinis, Microsoft doit procéder à la permutation de certificat au plus tôt, d’une manière similaire au changement effectué le 15 février 2021, afin de garantir que le service demeure sécurisé et conforme à tout moment.

10. Si j’utilise des réplicas en lecture, dois-je effectuer cette mise à jour uniquement sur le serveur principal ou sur les réplicas en lecture ?

Étant donné que cette mise à jour est une modification côté client, si le client avait l’habitude de lire les données du serveur de réplica, vous devez également appliquer les modifications pour ce client.

11. Existe-t-il une requête côté serveur pour vérifier si SSL est utilisé ?

Pour vérifier si vous utilisez une connexion SSL pour vous connecter au serveur, consultez Vérification SSL.

12. Une action est-elle nécessaire si je dispose déjà de DigiCertGlobalRootG2 dans mon fichier de certificat ?

Non. Aucune action n’est nécessaire si votre fichier de certificat contient déjà DigiCertGlobalRootG2.

13. Comment puis-je vérifier le certificat envoyé par le serveur ?

Il existe de nombreux outils que vous pouvez utiliser. Par exemple, DigiCert dispose d’un outil pratique qui vous montre la chaîne de certificats d’un nom de serveur. (Cet outil fonctionne uniquement avec un serveur accessible publiquement ; il ne peut pas se connecter à un serveur situé dans un réseau virtuel (VNET)). Un autre outil que vous pouvez utiliser est OpenSSL dans la ligne de commande. Vous pouvez utiliser cette syntaxe pour vérifier les certificats :

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

14. Que se passe-t-il si j’ai d’autres questions ?

Si vous avez des questions, posez-les aux experts de la communauté dans Microsoft Q&A. Si vous disposez d’un plan de support et que vous avez besoin d’une aide technique, créez une demande de support :

  • Pour Type de problème, sélectionnez Technique.
  • Pour Abonnement, sélectionnez votre abonnement.
  • Pour Service, sélectionnez Mes services, puis Azure Database pour PostgreSQL – Serveur unique.
  • Pour Type de problème, sélectionnez Sécurité.
  • Pour Sous-type de problème, sélectionnez Azure Encryption et Infrastructure Double Encryption