Partage via

Résoudre les échecs de connexion TLS

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.

Valider la configuration du client

Pour valider la configuration de votre client avant toute rotation planifiée, veillez à implémenter les configurations recommandées pour TLS.

Vérification de votre répertoire de certificats racine

Vous devez avoir les certificats racines requis au minimum ou l’ensemble complet de certificats racines installés dans le magasin de certificats racines de votre client.

Caution

Ne faites confiance qu’aux certificats racine d'Azure dans le dépôt de certificats racine des clients. Évitez d’approuver des autorités de certification intermédiaires ou des certificats de serveur individuels, car ces pratiques peuvent entraîner des problèmes de connexion inattendus lorsque Microsoft met à jour la chaîne de certificats ou fait pivoter des certificats serveur individuels.

Déterminer l’état de la connexion TLS

Pour déterminer l’état actuel de votre connexion TLS, vous pouvez charger l’extension sslinfo , puis appeler la ssl_is_used() fonction pour déterminer si TLS est utilisé. La fonction retourne t si la connexion utilise TLS. Sinon, fest retourné. Vous pouvez également collecter toutes les informations relatives à l’utilisation TLS de votre instance de serveur flexible Azure Database pour PostgreSQL par processus, client et application à l’aide de la requête suivante :

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

Tester la connexion TLS avec OpenSSL

Pour les tests, vous pouvez utiliser la openssl commande pour vous connecter à votre instance Azure Database pour PostgreSQL et afficher les certificats TLS.

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

Cette commande imprime des informations de protocole de bas niveau, telles que la version de TLS et le chiffrement. Vous devez utiliser l'option -starttls postgres. Dans le cas contraire, cette commande signale qu’aucun protocole TLS n’est utilisé. L’utilisation de cette commande nécessite au moins OpenSSL 1.1.1.

Réplicas en lecture

Avec la migration de l’autorité de certification racine vers Microsoft RSA Root CA 2017, il est possible que les réplicas nouvellement créés soient sur un certificat d’autorité de certification racine plus récent que le serveur primaire créé plus tôt. Pour les clients qui utilisent sslmode=verify-ca et sslmode=verify-full les paramètres de configuration, il est impératif d’accepter les certificats d’autorité de certification racine nouveaux et précédents jusqu’à ce que la rotation soit terminée sur les serveurs nouveaux et existants.

Troubleshoot

  1. Commencez par reproduire le problème
  2. Collecte de données de diagnostic (messages d’erreur côté client, sortie psql, sortie OpenSSL s_client, et journaux du serveur).
  3. Vérifier les paramètres du serveur (require_secure_transport, ssl_min_protocol_version, ssl_max_protocol_version)
  4. Vérifiez la chaîne de certificats et les paramètres sslmode/sslrootcert client pour identifier les incompatibilités dans les versions de protocole, les suites de chiffrement ou les certificats manquants/pivotés.

Erreurs de connectivité TLS

  1. La première étape pour résoudre les problèmes de compatibilité des versions du protocole TLS consiste à identifier les messages d’erreur que vous ou vos utilisateurs voyez lorsqu’ils essaient d’accéder à votre instance de serveur flexible Azure Database pour PostgreSQL sous le chiffrement TLS du client. Les messages d’erreur peuvent être différents en fonction de l’application de et la plateforme. Dans de nombreux cas, ils pointent vers le problème sous-jacent.
  2. Pour être certain de la compatibilité des versions du protocole TLS, vérifiez la configuration TLS du serveur de base de données et du client d’application pour vous assurer qu’ils prennent en charge les versions compatibles et les suites de chiffrement.
  3. Analysez les différences ou les lacunes entre le serveur de base de données et les versions TLS du client et les suites de chiffrement. Essayez de les résoudre en activant ou en désactivant certaines options, en mettant à niveau ou en rétrogradant des logiciels, ou en modifiant des certificats ou des clés. Par exemple, vous devrez peut-être activer ou désactiver des versions TLS spécifiques sur le serveur ou le client, en fonction des exigences de sécurité et de compatibilité. Par exemple, vous devrez peut-être désactiver TLS 1.0 et TLS 1.1, qui sont considérés comme non sécurisés et déconseillés, et activer TLS 1.2 et TLS 1.3, qui sont plus sécurisés et modernes.
  4. Le certificat le plus récent émis avec Microsoft RSA Root CA 2017 a un intermédiaire dans la chaîne avec signature croisée par l’autorité de certification Global Root G2 CA. Certaines des bibliothèques de client Postgres, lors de l’utilisation du paramètre sslmode=verify-full ou sslmode=verify-ca, peuvent rencontrer des échecs de connexion avec des certificats d’autorité de certification racine qui sont signés avec des certificats intermédiaires. Le résultat est la présence d’autres chemins d’accès d’approbation.

Pour contourner ces problèmes, ajoutez tous les certificats nécessaires au magasin de certificats client ou spécifiez explicitement le sslrootcert paramètre. Ou alors, modifiez la valeur par défaut (PGSSLROOTCERT) de la variable d’environnement %APPDATA%\postgresql\root.crt et affectez-lui le chemin d’accès local où le certificat d’autorité de certification racine Microsoft RSA Root CA 2017 est placé.

Problèmes liés à l’autorité de certification

Note

Si vous n’utilisez pas ou si vous n’utilisez sslmode=verify-full pas de sslmode=verify-ca paramètres dans votre chaîne de connexion d’application cliente, 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.

  1. Produisez votre liste de certificats qui se trouvent dans votre entrepôt racine de confiance
    1. Par exemple, vous pouvez obtenir la liste des certificats approuvés dans le magasin de clés Java par programme.
    2. Par exemple, vous pouvez vérifier le magasin de clés Java cacerts pour voir s’il contient déjà des certificats requis.
  2. Vous utilisez l’épinglage de certificat si vous avez des certificats intermédiaires individuels ou des certificats de serveur PostgreSQL individuels. Il s’agit d’une configuration non prise en charge.
  3. Pour supprimer l’épinglage de certificat, supprimez tous les certificats de votre répertoire des autorités racines de confiance et ajoutez uniquement des certificats d’autorité de certification racine.

Si vous rencontrez des problèmes même après ces étapes, contactez le support Microsoft. Inclure dans le titre ICA Rotation 2026.

Problèmes d’épinglage de certificat

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

  1. Vérifiez si vous utilisez la validation de certificat dans votre application.
  2. Créez votre liste de certificats qui se trouvent dans votre magasin racine approuvé. Par exemple:
    1. Obtenez la liste des certificats approuvés dans le magasin de clés Java par programmation.
    2. Vérifiez le magasin de clés Java cacerts pour voir s’il contient déjà des certificats requis.
  3. Vous utilisez l’épinglage de certificat si vous possédez des certificats intermédiaires individuels ou des certificats de serveur PostgreSQL spécifiques.
  4. Pour supprimer l’épinglage de certificat, retirez tous les certificats de votre répertoire racine de confiance et ajoutez les nouveaux certificats.
  5. Vous pouvez télécharger les certificats mis à jour à partir du dépôt officiel de Microsoft : détails de l’autorité de certification Azure.

Si vous rencontrez des problèmes même après ces étapes, contactez le support Microsoft. Inclure dans le titre ICA Rotation 2026.

Vérifier la chaîne de certificats

Ancienne chaîne

  • DigiCert Global Root G2
    • Microsoft Azure Autorité de Certification Émettrice RSA TLS 03 / 04 / 07 / 08
    • Certificat serveur

Nouvelle chaîne

  • 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

Contenu connexe

  • Last updated on