Dela via

Transport Layer Security (TLS) i Azure Database for PostgreSQL

Azure Database for PostgreSQL kräver att alla klientanslutningar använder TLS (Transport Layer Security), ett branschstandardprotokoll som krypterar kommunikationen mellan databasservern och klientprogrammen. TLS ersätter det äldre SSL-protokollet, där endast TLS-versionerna 1.2 och 1.3 identifieras som säkra. TLS-säkerhetens integritet bygger på tre grundpelare:

  • Använd endast TLS-versionerna 1.2 eller 1.3.
  • Klienten validerar serverns TLS-certifikat som utfärdats av en certifikatutfärdare (CA) i en kedja av certifikatutfärdare som startats av en betrodd rotcertifikatutfärdare.
  • Förhandlar om en säker chiffersvit mellan server och klient.

Betrodda rotcertifikat och certifikatrotationer

Viktigt!

Microsoft startade en TLS-certifikatrotation för Azure Database for PostgreSQL för att uppdatera mellanliggande CA-certifikat och den resulterande certifikatkedjan. Rot-CA:erna förblir desamma.

Om klientkonfigurationen använder de rekommenderade konfigurationerna för TLS behöver du inte vidta några åtgärder.

Schema för certifikatrotation

  • Azure-regionerna West Central US, East Asia och UK South startade sin TLS-certifikatrotation den 11 november 2025.
  • Från och med den 19 januari 2026 planeras den här certifikatrotationen att utökas till de återstående regionerna (utom Kina), inklusive Azure Government.
  • Efter vårfestivalen (kinesiskt nyår) 2026 kommer regionerna i Kina också att genomgå en rotation av certifikat som inkluderar en ändring av en rotcertifikatutfärdare.

Rot-CAs som används av Azure Database for PostgreSQL

Root CAs är de översta auktoriteterna i certifikatkedjan. Azure Database for PostgreSQL använder för närvarande dubbelsignerade certifikat som utfärdats av en mellanliggande CA (ICA) som är förankrad i följande rotcertifikatutfärdare:

Kina-regioner använder för närvarande följande certifikatutfärdare:

Mellanliggande certifikatutfärdare

Azure Database for PostgreSQL använder mellanliggande certifikatutfärdare (ICA) för att utfärda servercertifikat. För att upprätthålla säkerheten roterar Microsoft regelbundet dessa ICA:er och de servercertifikat som de utfärdar. Dessa rotationer är rutinmässiga och meddelas inte i förväg.

Den aktuella rotationen av mellanliggande certifikatutfärdare för DigiCert Global Root CA (se Certifikatrotation) startade i november 2023 och är planerad att slutföras under första kvartalet 2024. Om du följde de rekommenderade metoderna kräver den här ändringen inga ändringar i din miljö.

Gammal CA-kedja

Använd inte mellanliggande CAs eller servercertifikat i ditt betrodda rotarkiv.

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

Ny CA-kedja

Använd inte mellanliggande CAs eller servercertifikat i ditt betrodda rotarkiv.

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

Läs repliker

Rotcertifikatutfärdarmigrering från DigiCert Global Root CA till DigiCert Global Root G2 slutförs inte i alla regioner. Därför är det möjligt för nyligen skapade läsrepliker att använda ett nyare rotcertifikat än den primära servern. Du bör lägga till DigiCert Global Root CA i läsreplikernas betrodda lager.

Certifikatkedjor

En certifikatkedja är en hierarkisk sekvens av certifikat som utfärdats av betrodda certifikatutfärdare (CA). Kedjan börjar vid rot-CA, som utfärdar mellanliggande CA-certifikat (ICA). ICA:er kan utfärda certifikat för underordnade ICA:er. Den lägsta ICA i kedjan utfärdar enskilda servercertifikat. För att upprätta en förtroendekedja verifierar du varje certifikat i kedjan upp till rot-CA-certifikatet.

Minska anslutningsfel

Genom att använda rekommenderade TLS-konfigurationer kan du minska risken för anslutningsfel på grund av certifikatrotationer eller ändringar i mellanliggande certifikatutfärdare. Mer specifikt bör du undvika att lita på mellanliggande certifikatutfärdare eller enskilda servercertifikat. Dessa metoder kan leda till oväntade anslutningsproblem när Microsoft uppdaterar certifikatkedjan.

Viktigt!

Microsoft meddelar ändringar i rotcertifikatutfärdare i förväg för att hjälpa dig att förbereda dina klientprogram. Roteringar och ändringar av mellanliggande certifikatutfärdare är dock rutinmässiga och meddelas inte.

Försiktighet

Om du använder konfigurationer som inte stöds (klient) orsakas oväntade anslutningsfel.

Bästa konfiguration

  • Framtvinga den senaste, säkraste TLS-versionen genom att ange ssl_min_protocol_version serverparametern till TLSv1.3.
  • Använd sslmode=verify-all för PostgreSQL-anslutningar för att säkerställa fullständig verifiering av certifikat och värdnamn. Beroende på din DNS-konfiguration med privata slutpunkter eller integrering av virtuella nätverk kanske verify-all det inte går. Därför kan du använda verify-ca i stället.
  • Underhåll alltid den fullständiga uppsättningen Azure-rotcertifikat i ditt betrodda rotarkiv.

Bra konfiguration

  • Ange serverparametern ssl_min_protocol_version till TLSv1.3. Om du måste ha stöd för TLS 1.2 ska du inte ange den lägsta versionen.
  • Använd sslmode=verify-all eller sslmode=verify-ca för PostgreSQL-anslutningar för att säkerställa fullständig eller partiell certifikatverifiering.
  • Kontrollera att det betrodda rotarkivet innehåller det rotutfärdarens certifikat som för närvarande används av Azure Database for PostgreSQL.

Använd inte följande konfigurationer:

  • Inaktivera TLS genom att ange require_secure_transport till OFF och ställa in klientsidan på sslmode=disable.
  • Använd inställningar sslmodepå klientsidan disable , allow, prefereller require som kan göra din app sårbar för man-in-the-middle-attacker.

Konfigurationer som inte stöds. använd inte

Azure PostgreSQL meddelar inte ändringar om mellanliggande CA-ändringar eller enskilda roteringar av servercertifikat. Därför stöds inte följande konfigurationer när du använder sslmode inställningar verify-ca eller verify-all:

  • Använda mellanliggande CA-certifikat i betrodda lagret.
  • Använda certifikatanslutning, till exempel genom att använda enskilda servercertifikat i ditt betrodda arkiv.

Försiktighet

Dina program kan inte ansluta till databasservrarna utan varning när Microsoft ändrar certifikatkedjans mellanliggande certifikatutfärdare eller roterar servercertifikatet.

Problem med att fästa certifikat

Anmärkning

Certifikatrotationer påverkar dig inte om du inte använder sslmode=verify-full inställningarna eller sslmode=verify-ca i klientprogrammets anslutningssträng. Därför behöver du inte följa stegen i det här avsnittet.

Använd aldrig certifikatpinning i dina program eftersom det bryter mot certifikatrotationen, till exempel det nuvarande certifikatbytet av mellanliggande CA:s. Om du inte vet vad certifikatspinning är, är det osannolikt att du använder det. Så här kontrollerar du om certifikatet fästs:

  • Skapa din lista över certifikat som finns i ditt betrodda rotarkiv.
  • Du använder certifikatpinnning om du har mellanliggande CA-certifikat eller enskilda PostgreSQL-servercertifikat i ditt betrodda rotcertifikatsarkiv.
  • Ta bort certifikatslåsningskontrollen genom att ta bort alla certifikat från din betrodda rotlagringsplats och lägga till de rekommenderade rot-CA-certifikaten.

Om du får problem på grund av det mellanliggande certifikatet även efter att du har följt de här stegen kontaktar du Microsofts support. Ta med ICA Rotation 2026 i rubriken.

Andra överväganden för TLS

Utöver den grundläggande TLS-konfigurationen och certifikathanteringen påverkar flera andra faktorer säkerheten och beteendet för krypterade anslutningar till Azure Database for PostgreSQL. Genom att förstå dessa överväganden kan du fatta välgrundade beslut om TLS-implementering i din miljö.

Osäkra och säkra TLS-versioner

Flera statliga entiteter över hela världen upprätthåller riktlinjer för TLS när det gäller nätverkssäkerhet. I USA inkluderar dessa organisationer Department of Health and Human Services och National Institute of Standards and Technology. Den säkerhetsnivå som TLS tillhandahåller påverkas mest av TLS-protokollversionen och de chiffersviter som stöds.

Azure Database for PostgreSQL stöder TLS-versionerna 1.2 och 1.3. I RFC 8996 anger IETF (Internet Engineering Task Force) uttryckligen att TLS 1.0 och TLS 1.1 inte får användas. Båda protokollen var inaktuella i slutet av 2019. Alla inkommande anslutningar som använder tidigare osäkra versioner av TLS-protokollet, till exempel TLS 1.0 och TLS 1.1, nekas som standard.

IETF släppte TLS 1.3-specifikationen i RFC 8446 i augusti 2018 och TLS 1.3 är den rekommenderade versionen eftersom den är snabbare och säkrare än TLS 1.2.

Vi rekommenderar det inte, men om det behövs kan du inaktivera TLS för anslutningar till din Azure Database for PostgreSQL. Du kan uppdatera serverparametern require_secure_transport till OFF.

Viktigt!

Använd den senaste versionen av TLS 1.3 för att kryptera dina databasanslutningar. Du kan ange den lägsta TLS-versionen genom att ange ssl_min_protocol_version serverparametern till TLSv1.3. Ange inte serverparametern ssl_max_protocol_version .

Chiffer-sviter

En chiffersvit är en uppsättning algoritmer som innehåller ett chiffer, en nyckelutbytesalgoritm och en hashalgoritm. Använd dem tillsammans med TLS-certifikatet och TLS-versionen för att upprätta en säker TLS-anslutning. De flesta TLS-klienter och -servrar stöder flera chiffersviter och ibland flera TLS-versioner. När anslutningen upprättas förhandlar klienten och servern om TLS-versionen och chiffersviten som ska användas via ett handskakning. Under den här handskakningen utförs följande steg:

  • Klienten skickar en lista över acceptabla chiffersviter.
  • Servern väljer den bästa chiffersviten i listan och informerar klienten om valet.

TLS-funktioner är inte tillgängliga i Azure Database for PostgreSQL

För närvarande implementerar Inte Azure Database for PostgreSQL följande TLS-funktioner:

  • TLS-certifikatbaserad klientautentisering via TLS med ömsesidig autentisering (mTLS).
  • Anpassade servercertifikat (ta med egna TLS-certifikat).

Relaterat innehåll

  • Last updated on