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

Article
04/10/2023

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

Important

Azure Database pour MySQL serveur unique se trouve sur le chemin de mise hors service. Nous vous recommandons vivement de procéder à la mise à niveau vers Azure Database pour MySQL serveur flexible. Pour plus d’informations sur la migration vers Azure Database pour MySQL serveur flexible, consultez Ce qui se passe pour Azure Database pour MySQL serveur unique ?

Azure Database pour MySQL – Serveur unique, dans le cadre de la maintenance standard et des meilleures pratiques de sécurité, effectuera un changement de certificat racine à compter 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.

Notes

Cet article s’applique UNIQUEMENT à Azure Database pour MySQL - Serveur unique. Pour Azure Database pour MySQL - Serveur flexible, le certificat nécessaire pour communiquer par le biais de SSL est DigiCert Global Root CA.

Cet article contient des références au terme esclave, un terme que Microsoft n’utilise plus. Lorsque le terme sera supprimé du logiciel, nous le supprimerons de cet article.

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 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. Étant donné qu’Azure Database pour MySQL utilisait l’un de ces certificats non conformes, nous avions besoin de procéder à la permutation du certificat vers la version conforme afin de réduire la menace potentielle envers 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 :

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

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 le changement effectué, et il sera alors possible de supprimer le certificat Baltimore en toute sécurité.

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

Vous commencerez à rencontrer des erreurs lors de la connexion à votre serveur Azure Database pour MySQL. Vous devrez reconfigurer 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 le changement de certificat racine interviendra-t-il pour mon instance de serveur unique ?

La migration de BaltimoreCyberTrustRoot vers DigiCertGlobalRootG2 sera effectuée progressivement dans toutes les régions d’Azure à partir d’octobre 2022. Pour éviter toute perte de 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 effectuée dans toutes les régions Azure, nous enverrons un message pour vous informer que vous pouvez modifier le certificat DigiCertGlobalRootG2 d’autorité de certification unique en toute tranquillité.

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 le connecteur utilisant 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.

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

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 ces clients.

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 CA_file, SSL_Cert et SSL_Key, vous devez mettre à jour le fichier en ajoutant le nouveau certificat et créer un fichier de certificat combiné.
Si la réplication des données s’effectue entre deux serveurs Azure Database pour MySQL, vous devez réinitialiser le réplica en exécutant CALL mysql.az_replication_change_master et en fournissant 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.

Share via