Sdílet prostřednictvím

Zabezpečené připojení pomocí protokolu TLS ve službě Azure Database for PostgreSQL

Azure Database for PostgreSQL vynucuje připojení klientských aplikací k instanci flexibilního serveru Azure Database for PostgreSQL pomocí protokolu TLS (Transport Layer Security). TLS je standardní protokol, který zajišťuje šifrovaná síťová připojení mezi databázovým serverem a klientskými aplikacemi. TLS je aktualizovaný protokol SSL (Secure Sockets Layer). Termíny SSL a TLS se stále používají zaměnitelně.

Důležité

Od 11. listopadu 2025 se v oblastech Azure uvedených v následujícím seznamu plánuje obměna certifikátů TLS/SSL, při které budou použity nové zprostředkující CA certifikáty.

  • Středozápadní USA
  • Východní Asie
  • Velká Británie – jih

Od 19. ledna 2026 se plánuje tuto rotaci rozšířit do všech zbývajících regionů Azure, včetně Azure Government a všech ostatních regionů.

Informace o řešení potíží najdete v tématu Problémy s připnutím certifikátu.

Řetězy certifikátů

Řetěz certifikátů je seřazený seznam certifikátů, které obsahují certifikát TLS/SSL a certifikáty certifikační autority. Umožňuje příjemci ověřit, že odesílatel a všechny certifikační autority jsou důvěryhodné. Řetězec nebo cesta začíná certifikátem TLS/SSL. Každý certifikát v řetězu je podepsaný entitou identifikovanou dalším certifikátem v řetězu.

Řetězec se ukončí kořenovým certifikátem certifikační autority. Tento certifikát je vždy podepsaný samotnou certifikační autoritou. Podpisy všech certifikátů v řetězu musí být ověřeny až do kořenového certifikátu certifikační autority.

Jakýkoli certifikát, který se nachází mezi certifikátem TLS/SSL a kořenovým certifikátem certifikační autority v řetězu, se nazývá zprostředkující certifikát.

Verze protokolu TLS

Několik subjektů státní správy po celém světě udržuje pokyny pro protokol TLS týkající se zabezpečení sítě. Ve Spojených státech zahrnují tyto organizace oddělení zdravotnictví a lidských služeb a Národní institut standardů a technologií. Úroveň zabezpečení, kterou protokol TLS poskytuje, je nejvíce ovlivněna verzí protokolu TLS a podporovanými šifrovacími sadami.

Šifrovací sada je sada algoritmů, které zahrnují šifru, algoritmus výměny klíčů a algoritmus hash. Společně se používají k vytvoření zabezpečeného připojení TLS. Většina klientů a serverů TLS podporuje více alternativ. Musí vyjednat, když naváže zabezpečené připojení, aby vybrali společnou verzi protokolu TLS a šifrovací sadu.

Azure Database for PostgreSQL podporuje protokol TLS verze 1.2 a novější. V dokumentu RFC 8996 explicitně uvádí IETF (Internet Engineering Task Force), že protokol TLS 1.0 a TLS 1.1 se nesmí používat. Oba protokoly byly na konci roku 2019 zastaralé.

Všechna příchozí připojení, která používají starší verze protokolu TLS, například TLS 1.0 a TLS 1.1, jsou ve výchozím nastavení odepřena.

IETF vydal specifikaci TLS 1.3 v DOKUMENTU RFC 8446 v srpnu 2018 a protokol TLS 1.3 je nyní nejběžnější a doporučenou verzí protokolu TLS, která se používá. Protokol TLS 1.3 je rychlejší a bezpečnější než protokol TLS 1.2.

Poznámka:

Certifikáty SSL a TLS certifikuje, že vaše připojení je zabezpečené pomocí špičkových šifrovacích protokolů. Šifrováním připojení na drátu zabráníte neoprávněnému přístupu k datům během přenosu. Důrazně doporučujeme používat nejnovější verze protokolu TLS k šifrování připojení k instanci flexibilního serveru Azure Database for PostgreSQL.

I když to nedoporučujeme, v případě potřeby můžete zakázat TLS\SSL pro připojení k instanci flexibilního serveru Azure Database for PostgreSQL. Parametr serveru můžete aktualizovat require_secure_transport na OFF. Verzi protokolu TLS můžete nastavit také nastavením ssl_min_protocol_version a ssl_max_protocol_version parametry serveru.

Ověřování certifikátu se provádí pomocí klientských certifikátů SSL pro ověřování. V tomto scénáři server PostgreSQL porovnává atribut běžného názvu (CN) klientského certifikátu předaného požadovanému databázovému uživateli.

Azure Database for PostgreSQL v tuto chvíli nepodporuje:

Poznámka:

Microsoft provedl změny kořenové certifikační autority pro různé služby Azure, včetně Azure Database for PostgreSQL. Další informace najdete v tématu Změny certifikátu Protokolu TLS v Azure a v části Konfigurace PROTOKOLU SSL v klientovi.

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

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;

K testování můžete také použít openssl příkaz přímo:

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 SSL. Použití tohoto příkazu vyžaduje alespoň OpenSSL 1.1.1.

Pokud chcete vynutit nejnovější a nejbezpečnější verzi protokolu TLS pro ochranu připojení z klienta k instanci flexibilního serveru Azure Database pro PostgreSQL, nastavte ssl_min_protocol_version na hodnotu 1.3. Toto nastavení vyžaduje , aby klienti, kteří se připojují k instanci flexibilního serveru Azure Database for PostgreSQL, používali tuto verzi protokolu pouze k bezpečné komunikaci. Starší klienti nemusí být schopni komunikovat se serverem, protože tuto verzi nepodporují.

Konfigurace SSL na klientovi

Ve výchozím nastavení PostgreSQL neprovádí žádné ověření certifikátu serveru. Z tohoto důvodu je možné falšování identity serveru (například úpravou záznamu DNS nebo převzetím IP adresy serveru) bez znalosti klienta. Všechny možnosti PROTOKOLU SSL mají režii ve formě šifrování a výměny klíčů, takže kompromis se provádí mezi výkonem a zabezpečením.

Aby se zabránilo falšování identity, musí se použít ověření certifikátu SSL v klientovi.

Pro konfiguraci klienta pro SSL existuje mnoho parametrů připojení. Mezi důležité patří:

  • ssl: Připojení pomocí PROTOKOLU SSL. Tato vlastnost nepotřebuje přidruženou hodnotu. Pouhá přítomnost určuje připojení SSL. Pro zajištění kompatibility s budoucími verzemi je tato hodnota true upřednostňovaná. Když v tomto režimu vytváříte připojení SSL, klientský ovladač ověří identitu serveru, aby se zabránilo útokům typu man-in-the-middle. Zkontroluje, jestli je certifikát serveru podepsaný důvěryhodnou autoritou a že hostitel, ke kterému se připojujete, je stejný jako název hostitele v certifikátu.

  • sslmode: Pokud požadujete šifrování a chcete, aby připojení selhalo, pokud ho nejde zašifrovat, nastavte sslmode=require. Toto nastavení zajistí, že server bude nakonfigurovaný tak, aby přijímal připojení SSL pro tohoto hostitele nebo IP adresu a že server rozpozná klientský certifikát. Pokud server nepřijme připojení SSL nebo se klientský certifikát nerozpozná, připojení selže. Následující tabulka uvádí hodnoty pro toto nastavení:

    Režim SSL Explanation
    disable Šifrování se nepoužívá.
    allow Šifrování se používá, pokud ho nastavení serveru vyžadují nebo vynucuje.
    prefer Šifrování se používá, pokud to nastavení serveru umožňuje.
    require Používá se šifrování. Zajišťuje, že je server nakonfigurovaný tak, aby přijímal připojení SSL pro tuto IP adresu hostitele a aby server rozpoznal klientský certifikát.
    verify-ca Používá se šifrování. Ověřte podpis certifikátu serveru vůči certifikátu uloženému v klientovi.
    verify-full Používá se šifrování. Ověřte podpis certifikátu serveru a název hostitele vůči certifikátu uloženému v klientovi.

Použitý výchozí sslmode režim se liší mezi klienty založenými na knihovně libpq (například psql) a JDBC. Klienti založené na knihovně libpq mají výchozí hodnotu prefer. Klienti JDBC mají výchozí hodnotu verify-full.

  • sslcert, sslkeya sslrootcert: Tyto parametry mohou přepsat výchozí umístění klientského certifikátu, klíč klienta PKCS-8 a kořenový certifikát. Výchozí hodnota /defaultdir/postgresql.crtje , /defaultdir/postgresql.pk8a /defaultdir/root.crt, v uvedeném pořadí, kde defaultdir je ${user.home}/.postgresql/ v systémech Linux a %appdata%/postgresql/ ve Windows.

Certifikační autority jsou instituce zodpovědné za vydávání certifikátů. Důvěryhodná certifikační autorita je entita, která má právo ověřit, že někdo je tím, kdo říká, že je. Aby tento model fungoval, musí všichni účastníci souhlasit se sadou důvěryhodných certifikačních autorit. Všechny operační systémy a většina webových prohlížečů se dodávají se sadou důvěryhodných certifikačních autorit.

Použití verify-ca a verify-fullsslmode nastavení konfigurace se také označuje jako připnutí certifikátu. V takovém případě musí certifikáty kořenové certifikační autority na serveru PostgreSQL odpovídat podpisu certifikátu a dokonce i názvu hostitele s certifikátem v klientovi.

Pokud se certifikační autority změní nebo vyprší platnost certifikátů serveru PostgreSQL, může být potřeba pravidelně aktualizovat certifikáty uložené klientem. Pokud chcete zjistit, jestli připnete certifikační autority, přečtěte si téma Připnutí certifikátů a služby Azure.

Další informace o konfiguraci PROTOKOLU SSL\TLS na klientovi najdete v dokumentaci k PostgreSQL.

Pro klienty, kteří používají verify-ca a verify-fullsslmode konfigurační nastavení (to znamená připnutí certifikátu), musí do úložišť klientských certifikátů nasadit tři kořenové certifikáty certifikační autority:

Stažení certifikátů kořenové certifikační autority a aktualizace klientů aplikací ve scénářích připnutí certifikátu

Pokud chcete aktualizovat klientské aplikace ve scénářích připnutí certifikátů, můžete stáhnout certifikáty:

Pokud chcete importovat certifikáty do úložišť klientských certifikátů, možná budete muset po stažení souborů certifikátů z předchozích identifikátorů URI převést soubory .crt certifikátu do formátu .pem. Pomocí nástroje OpenSSL můžete provádět tyto převody souborů:

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

Informace o aktualizaci úložišť certifikátů klientských aplikací s novými kořenovými certifikáty certifikační autority jsou popsané v části Aktualizace klientských certifikátů TLS pro klienty aplikací.

Důležité

U některých klientských knihoven Postgres při sslmode=verify-full použití tohoto 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. V tomto případě doporučujeme explicitně zadat sslrootcert parametr. Nebo nastavte PGSSLROOTCERT proměnnou 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.

  1. Dojde ke ztrátě připojení z klientské aplikace k instanci flexibilního serveru Azure Database for PostgreSQL – byl otevřen tiket podpory.
  2. Pokud se váš přechodný certifikát vyměnil, možná budete muset aktualizovat úložiště klientských certifikátů novým přechodným certifikátem.
  3. jak zkontrolovat, jestli připnete zprostředkující certifikát – viz Připnutí certifikátu a služby Azure.

Scénáře připnutí certifikátů pro čtení replik

Při migraci kořenové certifikační autority do kořenové certifikační autority Microsoft RSA 2017 je možné, aby nově vytvořené repliky byly na novějším kořenovém certifikátu certifikační autority než primární server, který byl vytvořen dříve. Pro klienty, kteří používají verify-ca a verify-fullsslmode konfigurační nastavení (to znamená připnutí certifikátu), je nezbytné přerušit připojení, aby přijímali tři kořenové certifikáty certifikační autority:

V tuto chvíli Azure Database for PostgreSQL nepodporuje ověřování na základě certifikátů.

Testování klientských certifikátů připojením k psql ve scénářích připnutí certifikátů

Pomocí příkazového psql řádku z klienta můžete otestovat připojení k serveru ve scénářích připnutí certifikátu:

$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

Další informace o parametrech SSL a certifikátu najdete v dokumentaci k psql.

Testování připojení TLS/SSL

Než se pokusíte získat přístup k serveru s povoleným protokolem SSL z klientské aplikace, ujistěte se, že se k němu můžete dostat přes psql. Pokud jste vytvořili připojení SSL, měl by se zobrazit výstup podobný následujícímu příkladu:

psql (14.5)Připojení SSL (protokol: TLSv1.2, šifra: ECDHE-RSA-AES256-GCM-SHA384, bity: 256, komprese: vypnuto)Zadejte nápovědu "help".

Můžete také načíst rozšíření sslinfo a potom volat ssl_is_used() funkci, abyste zjistili, jestli se používá SSL. Funkce vrátí t , pokud připojení používá protokol SSL. V opačném případě se vrátí f.

Šifrovací sady

Šifrovací sada je sada kryptografických algoritmů. Protokoly TLS/SSL používají algoritmy ze šifrovací sady k vytváření klíčů a šifrování informací.

Šifrovací sada se zobrazuje jako dlouhý řetězec zdánlivě náhodných informací, ale každý segment tohoto řetězce obsahuje základní informace. Obecně platí, že tento datový řetězec obsahuje několik klíčových komponent:

  • Protokol (tj. TLS 1.2 nebo TLS 1.3)
  • Algoritmus výměny klíčů nebo smlouvy
  • Algoritmus digitálního podpisu (ověřování)
  • Algoritmus hromadného šifrování
  • Algoritmus kódu ověřování zpráv (MAC)

Různé verze protokolu TLS/SSL podporují různé šifrovací sady. Šifrovací sady PROTOKOLU TLS 1.2 nelze vyjednat s připojeními TLS 1.3 a naopak.

V tuto chvíli azure Database for PostgreSQL podporuje mnoho šifrovacích sad s verzí protokolu TLS 1.2, která spadají do kategorie HIGH:!aNULL .

Troubleshoot

Pokyny v této části Řešení potíží vám pomůžou rychle identifikovat a vyřešit běžné problémy s protokolem TLS/SSL. Začněte reprodukcí problému a shromažďováním diagnostických dat (chybové zprávy na straně klienta, výstup psql, výstup OpenSSL s_client výstupu a protokolů serveru), pak ověřte parametry serveru (require_secure_transport, ssl_min_protocol_version, ssl_max_protocol_version), řetěz certifikátů a nastavení sslmode/sslrootcert pro určení neshod ve verzích protokolu, šifrovacích sadách nebo chybějících nebo obměněných certifikátech.

Chyby připojení TLS/SSL

  1. Prvním krokem při řešení potíží s kompatibilitou verzí protokolu TLS/SSL je identifikace chybových zpráv, které se vám nebo vašim uživatelům zobrazují 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. Pokud chcete mít jistotu kompatibility s verzí protokolu TLS/SSL, zkontrolujte konfiguraci protokolu TLS/SSL 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/SSL 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 TLS/SSL na serveru nebo klientovi. Můžete například potřebovat 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ý u kořenové certifikační autority Microsoft RSA 2017 má v řetězu křížově podepsaný globální kořenovou certifikační autoritou Digicert G2. 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 vyřešit, přidejte všechny tři nezbytné 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 s připínáním certifikátu

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. Ověřte, zda ve své aplikaci používáte připnutí certifikátu.
  2. Vygenerujte seznam certifikátů, které jsou v důvěryhodném kořenovém úložišti.
    1. Seznam důvěryhodných certifikátů můžete například získat prostřednictvím kódu programu v úložišti klíčů Java.
    2. Můžete například zkontrolovat cacerts java keystore a zjistit, jestli už obsahuje požadované certifikáty.
  3. Používáte přikování certifikátu, pokud máte jednotlivé zprostředkující certifikáty nebo jednotlivé 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.
    1. Aktualizované certifikáty si můžete stáhnout z oficiálního úložiště Microsoftu: podrobnosti o certifikační autoritě Azure.
      1. Aktuální řetězec:
        1. DigiCert Global Root G2
        2. Microsoft Azure RSA TLS vydávající certifikační autorita 03 / 04 / 07 / 08
      2. Nový řetězec:
        1. DigiCert Global Root G2
        2. Microsoft TLS RSA Root G2
        3. Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16

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

Související obsah

  • Last updated on