Comprendre les modifications liées au changement d’autorité de certification racine pour Azure SQL Database et SQL Managed Instance
La base de données Azure SQL et SQL Managed Instance vont modifier le certificat racine d’application cliente/de pilote activé à l’aide du protocole SSL ou du protocole TLS, et que vous utilisez pour établir une connexion TDS sécurisée. Le certificat racine actuel est configuré pour expirer le 26 octobre 2020 dans le cadre de la maintenance standard et conformément aux bonnes pratiques de sécurité. Cet article vous donne plus de détails sur les modifications à venir, les ressources qui seront affectées et les étapes nécessaires pour garantir que votre application maintient sa connectivité à votre serveur de base de données.
Quelle mise à jour va se produire ?
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é que la base de données Azure SQL et SQL Managed Instance utilisent actuellement l’un de ces certificats non conformes utilisés par les applications clientes pour valider leurs connexions TSL, nous devons veiller à ce que les actions appropriées (décrites ci-dessous) soient entreprises afin de réduire au maximum l’impact potentiel sur vos serveurs Azure SQL.
Le nouveau certificat sera utilisé à partir du 26 octobre 2020. Si vous utilisez la validation complète du certificat de serveur lors de la connexion à partir d’un client SQL (TrustServerCertificate=false), vous devez vous assurer que votre client SQL sera en mesure de valider le nouveau certificat racine avant le 26 octobre 2020.
Comment puis-je savoir si mon application peut être affectée ?
Toutes les applications qui utilisent SSL/TLS et vérifient le certificat racine doivent mettre à jour le certificat racine pour pouvoir se connecter à la base de données Azure SQL et Azure SQL Managed Instance.
Si vous n’utilisez pas SSL/TLS actuellement, il n’y a aucun impact sur la disponibilité de votre application. Vous pouvez vérifier si votre application cliente tente de vérifier le certificat racine en examinant la chaîne de connexion. Si TrustServerCertificate est explicitement réglée sur « vrai », alors cela ne vous concerne pas.
Si votre pilote client utilise le magasin de certificats du système d’exploitation, comme c’est le cas de la majorité des pilotes, et que votre système d’exploitation fait l’objet d’une maintenance régulière, ce changement ne vous affectera probablement pas, car le certificat racine sur lequel nous basculons devrait être déjà disponible dans votre magasin de certificats racine de confiance. Vérifiez, puis validez la présence de Baltimore CyberTrust Root et de DigiCert GlobalRoot G2 Root.
Si votre pilote client utilise un magasin de certificats local, 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é, reportez-vous à la section Procédure à suivre pour maintenir la connectivité.
Procédure à suivre pour maintenir la connectivité
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é, procédez comme suit :
Téléchargez Baltimore CyberTrust Root DigiCert GlobalRoot G2 Root CA :
Générez un magasin de certificats d’autorité de certification combiné où les certificats BaltimoreCyberTrustRoot et DigiCertGlobalRootG2 sont inclus.
Quel peut être l’impact ?
Si vous validez des certificats de serveur comme indiqué ici, la disponibilité de votre application peut être interrompue, car la base de données ne sera pas accessible. Selon votre application, vous pouvez recevoir différents messages d’erreur tels que :
- Certificat non valide/certificat révoqué
- Délai de connexion dépassé
- Erreur, le cas échéant
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 concernant ce changement si vous n’utilisez pas SSL/TLS. Toutefois, vous devez définir un plan pour commencer à utiliser la dernière version de TLS, car nous prévoyons d’imposer le protocole TLS dans un avenir proche.
Que se passera-t-il si je ne mets pas à jour le certificat racine avant le 26 octobre 2020 ?
Si vous ne mettez pas à jour le certificat racine avant le 30 novembre 2020, vos applications qui se connectent via SSL/TLS et effectuent une vérification pour le certificat racine ne pourront pas communiquer avec la base de données Azure SQL et SQL Managed Instance. Par ailleurs, l’application rencontrera des problèmes de connectivité avec vos instances Azure SQL Database et SQL Managed Instance.
Dois-je prévoir un temps d’arrêt lié à la maintenance pour effectuer cette modification ?
Non. Étant donné que la modification est uniquement côté client pour la connexion au serveur, aucun temps d’arrêt pour maintenance n’est nécessaire ici lors de cette modification.
Que se passe-t-il si je ne peux pas prévoir un temps d’arrêt planifié pour cette modification avant le 26 octobre 2020 ?
Étant donné que les clients utilisés pour la connexion au serveur doivent mettre à jour les informations de certificat comme décrit dans la section de correction disponible ici, aucun temps d’arrêt n’est requis pour le serveur dans ce cas.
Si je crée un nouveau serveur après le 30 novembre 2020, est-ce que je serai impacté ?
Pour les serveurs créés après le 26 octobre 2020, vous pouvez utiliser le certificat récemment émis pour que vos applications se connectent à l’aide de SSL/TLS.
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 SQL Database et SQL Managed Instance sont fournis par des autorités de certification approuvées. Par conséquent, la prise en charge de ces certificats sur Azure SQL Database et SQL Managed Instance est liée à la prise en charge de ces certificats par l’autorité de certification. Toutefois, comme dans le cas présent, il peut y avoir des bogues imprévus dans ces certificats prédéfinis et ceux-ci doivent être corrigés au plus tôt.
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, nous devons également appliquer les modifications pour ces clients.
Existe-t-il une requête côté serveur pour vérifier si SSL/TLS est utilisé ?
Étant donné que cette configuration s’effectue côté client, ces informations ne sont pas disponibles côté serveur.
Que se passe-t-il si j’ai d’autres questions ?
Si vous avez un plan de support et que vous avez besoin d’une assistance technique, créez une demande de support Azure. Pour cela, consultez Créer une demande de support Azure.