Partager via

Tls (Transport Layer Security) dans Azure Database pour PostgreSQL

Présentation

Azure Database pour PostgreSQL nécessite toutes les connexions clientes pour utiliser le protocole TLS (Transport Layer Security), un protocole standard qui chiffre les communications entre votre serveur de base de données et les applications clientes. TLS remplace l’ancien protocole SSL, avec uniquement les versions TLS 1.2 et 1.3 reconnues comme sécurisées. L’intégrité de la sécurité TLS repose sur trois piliers :

  • Utilisation uniquement de TLS versions 1.2 ou 1.3.
  • Le client valide le certificat TLS du serveur émis par une autorité de certification dans une chaîne d’autorités de certification démarrée par une autorité de certification racine approuvée.
  • Négociation d’une suite de chiffrement sécurisée entre le serveur et le client.

Certificats racine de confiance et rotation des certificats

Important

Nous avons démarré une rotation des certificats TLS pour Azure Database pour PostgreSQL afin de mettre à jour de nouveaux certificats d’autorité de certification intermédiaires et la chaîne de certificats résultante. Les autorités de certification racines restent les mêmes.

Aucune action n’est requise si votre configuration client implémente les configurations recommandées pour TLS.

Planification de la rotation des certificats

  • Les régions Azure USA Centre Ouest, Asie Est et Royaume-Uni Sud ont démarré leur rotation des certificats TLS le 11 novembre 2025.
  • À compter du 19 janvier 2026, cette rotation des certificats est prévue pour s’étendre aux régions restantes (à l’exception de la Chine), y compris Azure Government.
  • Après le Festival de printemps (Nouvel an chinois) 2026, les régions chinoises effectueront également une rotation de certificats qui inclut une modification de l’une des autorités de certification racine.

Autorités de certification racines utilisées par Azure Database pour PostgreSQL

Les autorités de certification racines sont les autorités de niveau supérieur dans la chaîne de certificats. Azure Database pour PostgreSQL utilise actuellement des certificats double signés émis par une ICA ancrée par les autorités de certification racine suivantes :

Les régions de Chine utilisent actuellement les autorités de certification suivantes :

À propos des autorités de certification intermédiaires

Azure Database pour PostgreSQL utilise des autorités de certification intermédiaires (ICA) pour émettre des certificats de serveur. Microsoft fait pivoter régulièrement ces icAs et les certificats serveur qu’ils émettent pour maintenir la sécurité. Ces rotations sont courantes et ne sont pas annoncées à l’avance.

La rotation actuelle des autorités de certification intermédiaires pour DigiCert Global Root CA (voir rotation des certificats) a commencé en novembre 2025 et est prévue pour être terminée en Q1 2026, remplaçant les autorités de certification intermédiaires comme suit. Si vous avez suivi les pratiques recommandées, cette modification ne nécessite aucune modification dans votre environnement.

Ancienne chaîne d’autorité de certification

Ces informations sont fournies uniquement pour référence. N’utilisez pas d’autorités de certification intermédiaires ou de certificats de serveur dans votre magasin racine approuvé.

  • DigiCert Global Root G2
    • Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08
      • Certificat serveur

Nouvelle chaîne d’autorité de certification

Ces informations sont fournies uniquement pour référence. N’utilisez pas d’autorités de certification intermédiaires ou de certificats de serveur dans votre stockage racine de confiance.

  • DigiCert Global Root G2
    • Microsoft TLS RSA Root G2
      • Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16
        • Certificat serveur

Réplicas en lecture

La migration de l'autorité de certification Racine DigiCert Global de DigiCert Global Root CA vers DigiCert Global Root G2 n'est pas terminée dans toutes les régions. Par conséquent, il est possible que les répliques de lecture nouvellement créées aient un certificat d'autorité de certification racine plus récent que celui du serveur principal. Par conséquent, vous devez ajouter DigiCert Global Root CA au magasin de confiance des réplicas en lecture.

Chaînes de certificats

Une chaîne de certificats est une séquence hiérarchique de certificats émis par les autorités de certification approuvées, en commençant par l’autorité de certification racine, qui émet des certificats d’autorité de certification intermédiaire (ICA). Les ICAs peuvent émettre des certificats pour les ICAs inférieures. L’ICA la plus basse dans la chaîne émet des certificats de serveur individuels. La chaîne de confiance est établie en vérifiant chaque certificat de la chaîne jusqu’au certificat d’autorité de certification racine.

Réduction des échecs de connexion

L’utilisation des configurations TLS recommandées permet de réduire le risque d’échecs de connexion en raison de rotations de certificats ou de modifications apportées aux autorités de certification intermédiaires. Plus précisément, évitez d’approuver des autorités de certification intermédiaires ou des certificats serveur individuels, car ces pratiques peuvent entraîner des problèmes de connexion inattendus lorsque Microsoft met à jour la chaîne de certificats.

Important

Les modifications apportées aux autorités de certification racines sont annoncées à l’avance pour vous aider à préparer vos applications clientes ; toutefois, les rotations de certificats de serveur et les modifications apportées aux autorités de certification intermédiaires sont courantes et ne sont donc pas annoncées.

Caution

L’utilisation de configurations non prises en charge (client) provoque des échecs de connexion inattendus.

Meilleure configuration

  • Appliquez la version TLS la plus récente et la plus sécurisée en définissant le paramètre du serveur ssl_min_protocol_version sur TLSv1.3.
  • Utilisez sslmode=verify-all les connexions PostgreSQL pour garantir la vérification complète du certificat et du nom d’hôte. Selon la configuration de votre DNS avec des points de terminaison privés ou une intégration au Réseau Virtuel, verify-all pourrait ne pas être possible ; vous pouvez donc utiliser verify-ca à la place.
  • Conservez toujours l’ensemble complet de certificats racines Azure dans votre magasin racine approuvé.

Bonne configuration

  • Définissez le paramètre de ssl_min_protocol_version serveur sur TLSv1.3. Si vous devez prendre en charge TLS 1.2, ne définissez pas la version minimale.
  • Utilisez sslmode=verify-all ou sslmode=verify-ca pour les connexions PostgreSQL pour garantir une vérification complète ou partielle des certificats.
  • Vérifiez que le magasin racine approuvé contient le certificat d’autorité de certification racine actuellement utilisé par Azure Database pour PostgreSQL :

Nous vous recommandons vivement d’éviter les configurations suivantes :

  • Désactivez complètement TLS en définissant require_secure_transportOFF et en définissant le côté client sur sslmode=disable.
  • Empêcher les attaques man-in-the-middle en évitant les paramètres côté client sslmode, disable, allow, prefer ou require.

Configurations non prises en charge ; ne pas utiliser

Azure PostgreSQL n’annonce pas les modifications relatives aux modifications de l’autorité de certification intermédiaire ou aux rotations de certificats de serveur individuelles ; par conséquent, les configurations suivantes ne sont pas prises en charge lors de l’utilisation sslmode des paramètres verify-ca ou verify-all:

  • Vous utilisez des certificats d’autorité de certification intermédiaires dans votre magasin approuvé.
  • Vous utilisez l’épinglage de certificat, par exemple, à l’aide de certificats de serveur individuels dans votre magasin approuvé.

Caution

Vos applications ne parviennent pas à se connecter aux serveurs de base de données sans avertissement chaque fois que Microsoft modifie les autorités de certification intermédiaires de la chaîne de certificats ou fait pivoter le certificat de serveur.

Problèmes d’épinglage de certificat

Note

Si vous n’utilisez pas les paramètres sslmode=verify-full ou sslmode=verify-ca dans la chaîne de connexion de votre application cliente, alors les rotations de certificat ne vous affectent pas. Par conséquent, vous n’avez pas besoin de suivre les étapes décrites dans cette section.

N’utilisez jamais l’ancrage de certificat dans vos applications, car cela interrompt la rotation des certificats, comme c'est le cas avec le changement actuel de certificat des autorités de certification intermédiaires. Si vous ne savez pas ce qu'est le pinning des certificats, il est peu probable que vous l'utilisiez. Pour vérifier l’épinglage de certificat :

Si vous rencontrez des problèmes en raison du certificat intermédiaire, même après avoir suivi ces étapes, contactez le support Microsoft. Inclure dans le titre ICA Rotation 2026.

Autres considérations relatives au protocole TLS

Versions TLS non sécurisées et sécurisées

Plusieurs entités gouvernementales dans le monde tiennent à jour des instructions pour TLS concernant la sécurité réseau. Aux États-Unis, ces organisations incluent le Department of Health and Human Services ainsi que le National Institute of Standards and Technology. Le niveau de sécurité fourni par TLS est le plus affecté par la version du protocole TLS et les suites de chiffrement prises en charge.

Azure Database pour PostgreSQL prend en charge TLS version 1.2 et 1.3. Dans RFC 8996, internet Engineering Task Force (IETF) indique explicitement que TLS 1.0 et TLS 1.1 ne doivent pas être utilisés. Ces deux protocoles sont déconseillés depuis la fin de l’année 2019. Toutes les connexions entrantes qui utilisent des versions non sécurisées antérieures du protocole TLS, telles que TLS 1.0 et TLS 1.1, sont refusées par défaut.

L’IETF a publié la spécification TLS 1.3 dans RFC 8446 en août 2018 et TLS 1.3 est la version recommandée, car elle est plus rapide et plus sécurisée que TLS 1.2.

Bien que nous ne le recommandons pas, si nécessaire, vous pouvez désactiver TLS pour les connexions à votre instance Azure Database pour PostgreSQL. Vous pouvez mettre à jour le paramètre de serveur require_secure_transport sur OFF.

Important

Nous vous recommandons vivement d’utiliser les dernières versions de TLS 1.3 pour chiffrer vos connexions de base de données. Vous pouvez spécifier la version TLS minimale en définissant le paramètre du serveur sur ssl_min_protocol_versionTLSv1.3. Ne définissez pas le paramètre serveur de ssl_max_protocol_version.

Suites de chiffrements

Une suite de chiffrement est un ensemble d’algorithmes qui incluent un chiffrement, un algorithme d’échange de clés et un algorithme de hachage. Ils sont utilisés avec le certificat TLS et la version TLS pour établir une connexion TLS sécurisée. La plupart des clients et serveurs TLS prennent en charge plusieurs suites de chiffrement et parfois plusieurs versions TLS. Pendant l’établissement de la connexion, le client et le serveur négocient la version TLS et la suite de chiffrement à utiliser via une négociation. Lors de cette poignée de main, les opérations suivantes se produisent :

  • Le client envoie une liste de suites de chiffrement acceptables.
  • Le serveur sélectionne la meilleure suite de chiffrement (par sa propre définition) dans la liste et informe le client du choix.

Fonctionnalités TLS non disponibles dans Azure Database pour PostgreSQL

À ce stade, Azure Database pour PostgreSQL n’implémente pas les fonctionnalités TLS suivantes :

  • Authentification client basée sur un certificat TLS via TLS avec authentification mutuelle (mTLS).
  • Certificats de serveur personnalisés (apportez vos propres certificats TLS).

Contenu connexe

  • Last updated on