Sdílet prostřednictvím


Řešení potíží se selháním připojení TLS

Důležité

Společnost Microsoft zahájila obměnu certifikátů TLS pro Službu Azure Database for PostgreSQL za účelem aktualizace zprostředkujících certifikátů CA a výsledného řetězu certifikátů. Kořenové certifikační autority zůstanou stejné.

Pokud konfigurace klienta používá doporučené konfigurace protokolu TLS, nemusíte provádět žádnou akci.

Plán obměně certifikátů

  • Oblasti Azure – střed USA – středozápad, Východní Asie a Velká Británie – jih zahájily obměnu certifikátů TLS 11. listopadu 2025.
  • Od 19. ledna 2026 se plánuje tato obměně certifikátů rozšířit na zbývající oblasti (s výjimkou Číny), včetně Azure Government.
  • Po Jarním festivalu (Čínský nový rok) 2026 projdou regiony v Číně také obměnou certifikátu, která zahrnuje změnu jednoho z kořenových certifikačních autorit.

Ověření konfigurace klienta

Pokud chcete před plánovaným obměnám ověřit konfiguraci klienta, ujistěte se, že implementujete doporučené konfigurace protokolu TLS.

Kontrola úložiště kořenových certifikátů

Ujistěte se, že kořenové úložiště certifikátů klienta obsahuje minimální požadované kořenové certifikáty nebo úplnou sadu kořenových certifikátů.

Upozornění

Používejte pouze certifikáty kořenové certifikační autority Azure v úložišti kořenových certifikátů vašich klientů. Nedůvěřujte přechodným certifikačním autoritám ani jednotlivým certifikátům serveru. Pokud těmto certifikátům důvěřujete, může dojít k neočekávaným problémům s připojením, když Microsoft aktualizuje řetěz certifikátů nebo otočí jednotlivé certifikáty serveru.

Určení stavu připojení TLS

Pokud chcete zjistit aktuální stav připojení TLS, načtěte rozšíření sslinfo a potom volejte funkci ssl_is_used(), abyste zjistili, jestli se protokol TLS používá. Funkce vrátí t , pokud připojení používá protokol TLS. V opačném případě vrátí f. Všechny informace o využití protokolu TLS instance flexibilního serveru Azure Database for PostgreSQL můžete také shromažďovat pomocí procesu, klienta a aplikace pomocí následujícího dotazu:

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;

Testování připojení TLS pomocí OpenSSL

K testování se pomocí openssl příkazu připojte ke službě Azure Database for PostgreSQL a zobrazte certifikáty TLS.

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

Tento příkaz vytiskne informace protokolu nízké úrovně, jako je verze protokolu TLS a šifra. Musíte použít možnost -starttls postgres. Jinak tento příkaz hlásí, že se nepoužívá žádný protokol TLS. Použití tohoto příkazu vyžaduje alespoň OpenSSL 1.1.1.

Čtení replik

Při migraci kořenové certifikační autority do kořenové certifikační autority Microsoft RSA 2017 můžou nově vytvořené repliky používat novější kořenový certifikát certifikační autority než primární server, pokud byl primární server vytvořen dříve. U klientů, kteří používají sslmode=verify-ca a sslmode=verify-full konfigurační nastavení, musíte přijmout nové a předchozí certifikáty kořenové certifikační autority, dokud se obměna nedokončí na nových a existujících serverech.

Troubleshoot

  1. Reprodukujte problém.
  2. Shromážděte diagnostická data, jako jsou chybové zprávy na straně klienta, výstup psql, openSSL s_client výstup a protokoly serveru.
  3. Ověřte parametry serveru, včetně require_secure_transport, ssl_min_protocol_versiona ssl_max_protocol_version.
  4. Zkontrolujte řetězec certifikátů a nastavení klienta, identifikujte nesrovnalosti ve verzích protokolu, šifrovacích sadách nebo chybějících či obměněných certifikátech.

Chyby připojení TLS

  1. Identifikujte chybové zprávy, které uvidíte vy nebo vaši uživatelé při pokusu o přístup k instanci flexibilního serveru Azure Database for PostgreSQL v rámci šifrování TLS z klienta. V závislosti na aplikaci a platformě se můžou chybové zprávy lišit. V mnoha případech odkazují na základní problém.
  2. Zkontrolujte konfiguraci protokolu TLS databázového serveru a klienta aplikace a ujistěte se, že podporuje kompatibilní verze a šifrovací sady.
  3. Analyzujte případné nesrovnalosti nebo mezery mezi databázovým serverem a verzemi TLS klienta a šifrovacími sadami. Zkuste je vyřešit povolením nebo zakázáním určitých možností, upgradem nebo downgradováním softwaru nebo změnou certifikátů nebo klíčů. V závislosti na požadavcích na zabezpečení a kompatibilitu může být například potřeba povolit nebo zakázat konkrétní verze protokolu TLS na serveru nebo klientovi. Možná budete muset zakázat protokol TLS 1.0 a TLS 1.1, které jsou považovány za nezabezpečené a zastaralé, a povolit protokol TLS 1.2 a TLS 1.3, které jsou bezpečnější a modernější.
  4. Nejnovější certifikát vydaný Microsoft RSA Root CA 2017 má ve svém řetězci křížově podepsaný certifikát od Digicert Global Root G2 CA. U některých klientských knihoven Postgres při používání sslmode=verify-full nebo sslmode=verify-ca nastavení může docházet k chybám připojení s kořenovými certifikáty certifikační autority, které jsou křížově podepsané pomocí zprostředkujících certifikátů. Výsledkem jsou alternativní cesty důvěryhodnosti.

Chcete-li tyto problémy obejít, přidejte všechny potřebné certifikáty do úložiště klientských certifikátů nebo explicitně zadejte sslrootcert parametr. Nebo nastavte proměnnou PGSSLROOTCERT prostředí na místní cestu, kde je umístěn kořenový certifikát kořenové certifikační autority Microsoft RSA 2017 z výchozí hodnoty %APPDATA%\postgresql\root.crt.

Problémy certifikační autority

Poznámka:

Pokud v připojovacím řetězci klientské aplikace nepoužíváte sslmode=verify-full ani sslmode=verify-ca nastavení, obměna certifikátů vás neovlivní. Proto nemusíte postupovat podle kroků v této části.

  1. Vytvořte seznam certifikátů v důvěryhodném kořenovém úložišti.
  2. Používáte připnutí certifikátu, pokud máte jednotlivé zprostředkující certifikáty nebo jednotlivé certifikáty serveru PostgreSQL. Tato konfigurace není podporovaná.
  3. Pokud chcete odebrat připnutí certifikátu, odeberte všechny certifikáty z důvěryhodného kořenového úložiště a přidejte pouze kořenové certifikáty certifikační autority.

Pokud dojde k problémům i po provedení těchto kroků, obraťte se na podporu Microsoftu. Do názvu zahrňte ICA Rotation 2026 .

Problémy s připínáním certifikátu

Pokud v připojovacím řetězci klientské aplikace nepoužíváte sslmode=verify-full ani sslmode=verify-ca nastavení, obměna certifikátů vás neovlivní. Proto nemusíte postupovat podle kroků v této části.

  1. Ověřte, jestli ve své aplikaci používáte připnutí certifikátu.
  2. Vytvořte seznam certifikátů v důvěryhodném kořenovém úložišti. Například:
    • Získejte seznam důvěryhodných certifikátů v úložišti klíčů Java prostřednictvím kódu programu.
    • Zkontrolujte cacerts java keystore a zjistěte, jestli už obsahuje požadované certifikáty.
  3. Používáte připnutí certifikátu, pokud máte samostatné zprostředkující certifikáty nebo samostatné certifikáty serveru PostgreSQL.
  4. Pokud chcete odebrat připnutí certifikátu, odeberte všechny certifikáty z důvěryhodného kořenového úložiště a přidejte nové certifikáty.
  5. Aktualizované certifikáty si můžete stáhnout z oficiálního úložiště Microsoftu: podrobnosti o certifikační autoritě Azure.

Pokud dojde k problémům i po provedení těchto kroků, obraťte se na podporu Microsoftu. Do názvu zahrňte ICA Rotation 2026 .

Ověření řetězu certifikátů

Starý řetězec

  • DigiCert Global Root G2
    • Microsoft Azure RSA TLS vydávající certifikační autorita 03 / 04 / 07 / 08
    • Certifikát serveru

Nový řetězec

  • DigiCert Global Root G2
    • Microsoft TLS RSA Root G2
    • Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16
    • Certifikát serveru