Comprendre les modifications liées au changement d’autorité de certification racine pour Azure Database pour MySQL – Serveur unique

S’APPLIQUE À : Azure Database pour MySQL – Serveur unique

Azure Database pour MySQL serveur unique dans le cadre des meilleures pratiques de maintenance et de sécurité standard terminent la modification du certificat racine à partir d’octobre 2022. 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 une mise à jour du certificat racine est-elle nécessaire ?

Les clients Azure Database pour MySQL peuvent uniquement utiliser le certificat prédéfini pour se connecter à leur serveur MySQL, 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 pour les autorités de certification non conformes, exigeant que les serveurs utilisent des certificats émis par des autorités de certification conformes et signés par des certificats d’autorité de certification de ces autorités de certification conformes. Étant donné que Azure Database pour MySQL utilisé l’un de ces certificats non conformes, nous avons besoin de faire pivoter le certificat vers la version conforme pour réduire la menace potentielle pour vos serveurs MySQL.

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

Si vous avez suivi les étapes mentionnés sous Créer un certificat d’autorité de certification combiné ci-dessous, vous pouvez continuer à vous connecter tant que le certificat BaltimoreCyberTrustRoot n’est pas supprimé du certificat d’autorité de certification combiné. Afin de maintenir la connectivité, nous vous recommandons de conserver BaltimoreCyberTrustRoot dans votre certificat d’autorité de certification combiné jusqu’à nouvel ordre.

Créer un certificat d’autorité de certification combiné

Pour éviter toute interruption de la disponibilité de votre application en raison de la révocation inattendue de certificats, ou pour mettre à jour un certificat qui a été révoqué, effectuez les étapes suivantes. L’idée est de créer un fichier .pem, qui combine le certificat actuel et le nouveau. Lors de la validation du certificat SSL, l’une des valeurs autorisées sera utilisée. Reportez-vous aux étapes suivantes :

1. Téléchargez l’autorité de certification racine BaltimoreCyberTrustRootDigiCertGlobalRootG2 à partir des liens suivants :

   • https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem
   • https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem

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

   • Pour les utilisateurs Java (MySQL Connector/J), exécutez :

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

     keytool -importcert -alias MySQLServerCACert2 -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 (MySQL Connector/NET, MySQLConnector), assurez-vous que BaltimoreCyberTrustRoot et DigiCertGlobalRootG2 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.

   • Si vous utilisez .NET sur Linux en utilisant 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.

   • Si vous utilisez d’autres solutions (MySQL Client/MySQL Workbench/C/C++/Go/Python/Ruby/PHP/NodeJS/Perl/Swift), vous pouvez fusionner deux fichiers de certificat d’autorité de certification dans le format suivant :

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

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

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

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

Vous commencez à rencontrer des erreurs de connectivité lors de la connexion à votre serveur Azure Database pour MySQL. Vous devez à nouveau configurer SSL avec le certificat BaltimoreCyberTrustRoot pour maintenir la connectivité.

Forum aux questions

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.

Quand mon instance de serveur unique subit-elle un changement de certificat racine ?

La migration de BaltimoreCyberTrustRoot vers DigiCertGlobalRootG2 sera effectuée progressivement dans toutes les régions d’Azure à partir d’octobre 2022. Pour vous assurer que vous ne perdez pas la connectivité à votre serveur, suivez les étapes mentionnées sous Créer un certificat d’autorité de certification combiné. Le certificat d’autorité de certification combiné autorise la connectivité via SSL à votre instance de serveur unique à l’aide de l’un de ces deux certificats.

Quand pourrai-je supprimer complètement le certificat BaltimoreCyberTrustRoot ?

Une fois la migration terminée avec succès dans toutes les régions Azure, nous envoyons un billet de communication que vous êtes sûr de modifier un certificat DigiCertGlobalRootG2 d’autorité de certification unique.

Je ne spécifie aucun certificat d’autorité de certification lorsque je me connecte à mon instance de serveur unique via SSL, dois-je toujours suivre les étapes mentionnées ci-dessus ?

Si vos deux certificats racines d’autorité de certification se trouvent dans votre magasin racine approuvé, aucune action supplémentaire n’est requise. Cela s’applique également à vos pilotes clients qui utilisent le magasin local pour accéder au certificat d’autorité de certification racine.

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. Ce certificat racine est 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.

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-identity, 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.

Quel est l’impact de l’utilisation d’App Service avec Azure Database pour MySQL ?

Pour les services Azure App Service qui se connectent à Azure Database pour MySQL, deux scénarios sont possibles selon la manière 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. Il s’agit du scénario le plus courant.
• Si vous incluez explicitement le chemin du fichier de certificat SSL dans votre code, vous devez télécharger le nouveau certificat, générer un certificat combiné comme indiqué ci-dessus, et utiliser le fichier de 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. Il s’agit d’un scénario rare, mais nous l’avons déjà observé chez certains utilisateurs.

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

Si vous essayez de vous connecter au serveur Azure Database pour MySQL à 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.

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

Le connecteur qui utilise Azure Integration Runtime utilise des 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 un connecteur utilisant le runtime d’intégration auto-hébergé dans lequel 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 le chaîne de connexion pour l’utiliser.

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.

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 for MySQL sont fournis par des autorités de certification approuvées. Par conséquent, la prise en charge de ces certificats est liée à la prise en charge de ces certificats 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. En outre, en cas de bogues imprévus dans ces certificats prédéfinis, Microsoft devra effectuer la rotation des certificats au plus tôt similaire à la modification effectuée le 15 février 2021 pour garantir que le service est toujours sécurisé et conforme.

Si j’utilise des réplicas en lecture, dois-je effectuer cette mise à jour uniquement sur le serveur source ou sur les réplicas de 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.

Si j’utilise la réplication des données entrantes, dois-je effectuer une action particulière ?

Si vous utilisez la réplication des données entrantes pour vous connecter à Azure Database pour MySQL, deux éléments sont à prendre en compte :

• Si la réplication des données s'effectue entre une machine virtuelle (locale ou Azure) et Azure Database pour MySQL, vous devez vérifier si SSL est utilisé pour créer le réplica. Exécutez SHOW SLAVE STATUS et vérifiez le paramètre suivant.

  Master_SSL_Allowed            : Yes
  Master_SSL_CA_File            : ~\azure_mysqlservice.pem
  Master_SSL_CA_Path            :
  Master_SSL_Cert               : ~\azure_mysqlclient_cert.pem
  Master_SSL_Cipher             :
  Master_SSL_Key                : ~\azure_mysqlclient_key.pem
  

  Si vous constatez que le certificat est fourni pour le CA_file, SSL_Cert et SSL_Key, vous devez mettre à jour le fichier en ajoutant le nouveau certificat et en créant un fichier de certificat combiné.

• Si la réplication des données se trouve entre deux serveurs Azure Database pour MySQL, vous devez réinitialiser le réplica en exécutant CALL mysql.az_replication_change_master et fournir le nouveau certificat racine double comme dernier paramètre master_ssl_ca.

Existe-t-il une requête côté serveur permettant de déterminer si SSL est utilisé ?

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

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.

Pourquoi dois-je mettre à jour mon certificat racine si j’utilise le pilote PHP avec enableRedirect ?

Pour répondre aux exigences de conformité, les certificats d’autorité de certification du serveur hôte ont été changés, passant de BaltimoreCyberTrustRoot à DigiCertGlobalRootG2. Avec cette mise à jour, les connexions de base de données utilisant le pilote client PHP avec enableRedirect ne peuvent plus se connecter au serveur, car les appareils clients ne connaissent pas le changement de certificat et les nouveaux détails de l’autorité de certification racine. Les appareils clients qui utilisent des pilotes de redirection PHP se connectent directement au serveur hôte, en contournant la passerelle. Reportez-vous à ce lien pour obtenir plus d’informations sur l’architecture d’Azure Database pour MySQL – Serveur unique.

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, contactez-nous.