Sdílet prostřednictvím

Připojení klientů pomocí zabezpečení TLS k databázi

Připojení mezi vašimi klientskými aplikacemi a databázovým serverem vždy používají šifrování s oborovým standardem TLS (Transport Layer Security), dříve označovaným jako SSL (Secure Sockets Layer).

Poznámka:

Open source PostgreSQL používá ve svých příkazech, proměnných a dokumentaci starší název SSL, aby nedocházelo k přerušení existujících implementací. Tento článek používá akronym TLS při použití SSL v názvech příkazů a proměnných.

Azure Database for PostgreSQL podporuje šifrovaná připojení pomocí protokolu TLS 1.2 a 1.3. Server odepře všechna příchozí připojení, která se pokusí šifrovat provoz pomocí protokolu TLS 1.0 a TLS 1.1.

Ve výchozím nastavení server vynucuje zabezpečené připojení mezi klientem a serverem. Chcete-li toto vynucení zakázat a povolit šifrovanou i nešifrovanou komunikaci klienta, změňte parametr require_secure_transport serveru na OFF. Verzi protokolu TLS můžete nastavit také nastavením parametru ssl_max_protocol_version serveru. Nezakažte 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.

Konfigurace protokolu TLS klienta

Ve výchozím nastavení PostgreSQL neověřuje certifikát serveru. Z důvodu tohoto výchozího chování nemůže klient zjistit, jestli je identita serveru falšovaná (například pokud někdo upraví záznam DNS nebo převezme IP adresu serveru). Pokud chcete zabránit tomuto typu falšování identity, povolte v klientovi ověření certifikátu TLS.

Pro nastavení protokolu TLS klienta můžete nakonfigurovat mnoho parametrů připojení. Mezi důležité patří:

  • ssl: Připojení pomocí protokolu TLS. Tato vlastnost nepotřebuje hodnotu. Jeho přítomnost určuje připojení TLS. Pro zajištění kompatibility s budoucími verzemi použijte hodnotu true. Když v tomto režimu vytvoříte připojení TLS, klientský ovladač ověří identitu serveru, aby se zabránilo útokům typu man-in-the-middle.

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

    sslmode Explanation
    disable Šifrování se nepoužívá. Azure Database for PostgreSQL vyžaduje připojení TLS, takže toto nastavení nepoužívejte.
    allow Šifrování se používá, pokud ho nastavení serveru vyžadují nebo vynucuje. Azure Database for PostgreSQL vyžaduje připojení TLS, takže toto nastavení je ekvivalentní prefer.
    prefer Šifrování se používá, pokud to nastavení serveru umožňuje. Azure Database for PostgreSQL vyžaduje připojení TLS.
    require Používá se šifrování. Zajišťuje, že je server nakonfigurovaný tak, aby přijímal připojení TLS.
    verify-ca Používá se šifrování. Ověřte certifikát serveru vůči důvěryhodným kořenovým certifikátům uloženým v klientovi.
    verify-full Používá se šifrování. Ověřte certifikát serveru vůči certifikátu uloženému v klientovi. Také ověří, že certifikáty serveru používají stejný název hostitele jako připojení. Toto nastavení použijte, pokud privátní překladače DNS nepoužívají jiný název pro odkaz na server Azure Database for PostgreSQL.

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

  • sslcert, sslkeya sslrootcert: Tyto parametry přepíší 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.

Důležité

Některé knihovny klienta Postgres se nemusí připojit při použití nastavení sslmode=verify-full s kořenovými certifikáty certifikační autority, které křížově signují zprostředkující certifikáty. Výsledkem této konfigurace jsou alternativní cesty důvěryhodnosti. V tomto případě explicitně zadejte 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.

Instalace důvěryhodných kořenových certifikačních autorit (CA)

Stažení a převod kořenových certifikátů certifikační autority

Pro klienty systému Windows, kteří používají systémové úložiště certifikátů pro důvěryhodné kořenové certifikáty, není nutná žádná akce, protože Systém Windows nasadí nové kořenové certifikáty certifikační autority prostřednictvím služby Windows Update.

Pro klienty v Javě, rozšíření VS Code a další klienty (například PSQLPerl), které nepoužívají systémové úložiště, a pro klienty v Linuxu: potřebujete stáhnout a zkombinovat certifikáty kořenové certifikační autority do souboru PEM. Je nezbytné minimálně zahrnout následující certifikáty kořenové certifikační autority:

Poznámka:

Pro čínské regiony a pro zákazníky s rozšířeními pro rotaci: Digicert Global Root CA (soubor pem) je stále platný, proto ho zahrněte do kombinovaného souboru PEM.

Pokud dojde ke změnám kořenových certifikačních autorit používaných službou Azure Database for PostgreSQL, zahrňte všechny certifikáty kořenové certifikační autority Azure, abyste snížili potřebu budoucích aktualizací kombinovaného souboru. Seznam certifikátů kořenové certifikační autority Azure najdete v podrobnostech certifikační autority Azure.

Pokud chcete importovat certifikáty do úložišť klientských certifikátů, možná budete muset převést všechny certifikáty ve formátu CRT na formát PEM a zřetězení souborů PEM do jednoho souboru. Pomocí nástroje OpenSSL X509 můžete převést soubory CRT na PEM.

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

Kombinování certifikátů kořenové certifikační autority do jednoho souboru PEM

Pro některé klienty můžete zřetězit všechny soubory PEM do jednoho souboru pomocí libovolného textového editoru nebo nástroje příkazového řádku.

-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

Pro regiony v Číně a pro zákazníky s rozšířeními rotace:

-----BEGIN CERTIFICATE-----
(Root CA0 content: DigiCertGlobalRootCA.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

Kombinování a aktualizace kořenových certifikátů certifikační autority pro aplikace v Javě

Vlastní aplikace v Javě používají výchozí úložiště klíčů s názvem cacerts, které obsahuje certifikáty důvěryhodné certifikační autority (CA). Soubor cacerts certifikátů se nachází v adresáři vlastností zabezpečení na místě java.home\lib\security, kde java.home představuje adresář runtime prostředí (adresář jre v sadě SDK nebo adresář nejvyšší úrovně prostředí Java™ 2 Runtime Environment). Pokud chcete aktualizovat certifikáty kořenové certifikační autority klienta pro scénáře připnutí klientských certifikátů pomocí PostgreSQL, použijte následující pokyny:

  1. cacerts Zkontrolujte úložiště klíčů Java a zjistěte, jestli už obsahuje požadované certifikáty. Certifikáty v úložišti klíčů Java můžete vypsat pomocí následujícího příkazu:

    keytool -list -v -keystore ..\lib\security\cacerts > outputfile.txt

    Pokud v úložišti klíčů Java na klientovi nejsou k dispozici potřebné certifikáty, jak můžete zkontrolovat ve výstupu, pokračujte následujícími pokyny:

  2. Vytvořte záložní kopii vlastního úložiště klíčů.

  3. Stáhněte si soubory certifikátu a uložte je místně, kde na ně můžete odkazovat.

  4. Vygenerujte kombinované úložiště certifikátů certifikační autority, které obsahuje všechny potřebné kořenové certifikáty certifikační autority. Následující příklad ukazuje použití defaultJavaSSLFactory pro uživatele Javy PostgreSQL.

    keytool -importcert -alias PostgreSQLServerCACert  -file "DigiCertGlobalRootG2.crt.pem" -keystore truststore -storepass password -noprompt

keytool -importcert -alias PostgreSQLServerCACert2  -file "Microsoft ECC Root Certificate Authority 2017.crt.pem" -keystore truststore -storepass password  -noprompt

...

Aktualizace kořenových certifikátů certifikační autority ve službě Azure App Services

Pro Službu Azure App Services, která se připojuje k instanci flexibilního serveru Azure Database for PostgreSQL, existují dva možné scénáře pro aktualizaci klientských certifikátů. Scénáře závisí na tom, jak používáte SSL s vaší aplikací nasazenou do Azure App Services.

  • Před provedením změn v instanci flexibilního serveru Azure Database for PostgreSQL přidejte nové certifikáty do služby App Service na úrovni platformy. Pokud ve vaší aplikaci používáte certifikáty SSL zahrnuté na platformě služby App Service, není potřeba žádná akce. Další informace najdete v tématu Přidání a správa certifikátů TLS/SSL ve službě Azure App Service v dokumentaci ke službě Azure App Service.
  • Pokud do kódu explicitně zahrnete cestu k souboru certifikátu SSL, musíte stáhnout nový certifikát a aktualizovat kód tak, aby ho používal.

Aktualizace certifikátů kořenové certifikační autority při používání klientů ve službě Azure Kubernetes Service (AKS)

Pokud se pokoušíte připojit ke službě Azure Database for PostgreSQL pomocí aplikací hostovaných ve službě Azure Kubernetes Services (AKS), je to podobné přístupu z hostitelského prostředí vyhrazeného zákazníka. Podrobné pokyny najdete v dokumentaci k AKS.

Aktualizace certifikátů kořenové certifikační autority pro uživatele .NET (Npgsql) ve Windows

Pro uživatele .NET (Npgsql) na Windows, kteří se připojují k instancím flexibilního serveru Azure Database for PostgreSQL, se ujistěte, že všechny kořenové certifikáty certifikační autority jsou součástí úložiště certifikátů Windows v rámci důvěryhodných kořenových certifikačních autorit. Služba Windows Update udržuje standardní seznam kořenových certifikačních autorit Azure. Pokud nejsou zahrnuté nějaké certifikáty uvedené v doporučené konfiguraci , naimportujte chybějící certifikáty.

Jak používat protokol TLS s ověřováním certifikátů

Některé aplikační architektury, které používají PostgreSQL pro své databázové služby, ve výchozím nastavení nepovolují protokol TLS během instalace. Vaše instance Azure Database for PostgreSQL vynucuje připojení TLS, ale pokud aplikace není nakonfigurovaná pro protokol TLS, může selhat. V dokumentaci vaší aplikace se dozvíte, jak povolit připojení TLS.

Připojení pomocí PSQL

Následující příklad ukazuje, jak se připojit k serveru pomocí rozhraní příkazového PSQL řádku. K vynucení ověření certifikátu TLS použijte nastavení připojovacího sslmode=verify-fullsslmode=verify-ca řetězce. Předejte do parametru sslrootcert cestu k souboru místního certifikátu.

 psql "sslmode=verify-full sslrootcert=<path-of-pem-file> host=mydemoserver.postgres.database.azure.com dbname=postgres user=myadmin"

Testování připojení TLS

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

psql (14.5)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

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

Získání seznamu důvěryhodných certifikátů v úložišti klíčů Java prostřednictvím kódu programu

Ve výchozím nastavení ukládá Java důvěryhodné certifikáty do speciálního souboru s názvem cacerts , který se nachází v instalační složce Javy v klientovi. Následující příklad načte cacerts a načte ho do objektu KeyStore :

private KeyStore loadKeyStore() {
    String relativeCacertsPath = "/lib/security/cacerts".replace("/", File.separator);
    String filename = System.getProperty("java.home") + relativeCacertsPath;
    FileInputStream is = new FileInputStream(filename);
    KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
    String password = "changeit";
    keystore.load(is, password.toCharArray());

    return keystore;
}

Výchozí heslo je cacertschangeit, ale mělo by se lišit u skutečného klienta. Správci doporučují změnit heslo ihned po instalaci Javy. Jakmile načtete objekt KeyStore, můžete použít třídu PKIXParameters ke čtení certifikátů, které jsou přítomny.

public void whenLoadingCacertsKeyStore_thenCertificatesArePresent() {
    KeyStore keyStore = loadKeyStore();
    PKIXParameters params = new PKIXParameters(keyStore);
    Set<TrustAnchor> trustAnchors = params.getTrustAnchors();
    List<Certificate> certificates = trustAnchors.stream()
      .map(TrustAnchor::getTrustedCert)
      .collect(Collectors.toList());

    assertFalse(certificates.isEmpty());
}

Související obsah

  • Last updated on