Förstå ändringarna i rotcertifikatutfärdarändringen för Azure Database for PostgreSQL – enskild server

  • Artikel

GÄLLER FÖR: Azure Database for PostgreSQL – enskild server

Viktigt!

Azure Database for PostgreSQL – enskild server är på väg att dras tillbaka. Vi rekommenderar starkt att du uppgraderar till Azure Database for PostgreSQL – flexibel server. Mer information om hur du migrerar till Azure Database for PostgreSQL – flexibel server finns i Vad händer med Azure Database for PostgreSQL – enskild server?.

Azure Database for PostgreSQL – enskild server som planerar rotcertifikatändringen från och med december 2022 (12/2022) som en del av bästa praxis för standardunderhåll och säkerhet. Den här artikeln innehåller mer information om ändringarna, vilka resurser som påverkas och de steg som krävs för att säkerställa att programmet upprätthåller anslutningen till databasservern.

Varför krävs en rotcertifikatuppdatering?

Tidigare kunde Azure Database for PostgreSQL-användare bara använda det fördefinierade certifikatet för att ansluta till sin PostgreSQL-server, som finns här. Certifikatutfärdare (CA) Webbläsarforum publicerade nyligen rapporter om flera certifikat som utfärdats av CA-leverantörer för att vara icke-kompatibla.

Enligt branschens efterlevnadskrav började CA-leverantörer återkalla CA-certifikat för icke-kompatibla certifikatutfärdare, kräva att servrar använder certifikat som utfärdats av kompatibla certifikatutfärdare och signerats av CA-certifikat från dessa kompatibla certifikatutfärdare. Eftersom Azure Database for PostgreSQL använde ett av dessa icke-kompatibla certifikat behövde vi rotera certifikatet till den kompatibla versionen för att minimera det potentiella hotet mot postgres-servrarna.

Det nya certifikatet distribueras och gäller från och med december 2022 (12/2022).

Vilken ändring skulle utföras från och med december 2022 (12/2022)?

Från och med december 2022 ersätts rotcertifikatet BaltimoreCyberTrustRoot med en kompatibel version som kallas DigiCertGlobalRootG2-rotcertifikat . Om dina program drar nytta av verify-ca eller verify-full som värdet för sslmode-parametern i databasklientanslutningen måste du följa anvisningarna för att lägga till nya certifikat i certifikatarkivet för att upprätthålla anslutningen.

Behöver jag göra några ändringar på min klient för att upprätthålla anslutningen?

Det krävs inga kod- eller programändringar på klientsidan. Om du följer vår rekommendation för certifikatuppdatering nedan kan du fortfarande fortsätta att ansluta så länge BaltimoreCyberTrustRoot-certifikatet inte tas bort från det kombinerade CA-certifikatet. Vi rekommenderar att du inte tar bort BaltimoreCyberTrustRoot från ditt kombinerade CA-certifikat tills vidare för att upprätthålla anslutningen.

Behöver jag göra ändringar i klientcertifikaten?

PostgreSQL utför som standard ingen verifiering av servercertifikatet. Det innebär att det fortfarande är teoretiskt möjligt att förfalska serveridentiteten (till exempel genom att ändra en DNS-post eller genom att ta över serverns IP-adress) utan att klienten vet om det. För att förhindra eventuell förfalskning måste SSL-certifikatverifiering på klienten användas. Sådan verifiering kan ställas in via programklienten anslutningssträng ssl-lägesvärde – verify-ca eller verify-full. Om dessa ssl-mode-värden väljs bör du följa anvisningarna i nästa avsnitt.

Rekommendation för uppdatering av klientcertifikat

  • Ladda ned BaltimoreCyberTrustRoot & DigiCertGlobalRootG2 Root CA från länkarna nedan:

  • Om du vill förhindra framtida störningar rekommenderar vi också att du lägger till följande rötter i det betrodda arkivet:

  • Generera ett kombinerat CA-certifikatarkiv med både BaltimoreCyberTrustRoot - och DigiCertGlobalRootG2-certifikat ingår.

    • För Java-användare (PostgreSQL JDBC) som använder DefaultJavaSSLFactory kör du:

      keytool -importcert -alias PostgreSQLServerCACert  -file D:\BaltimoreCyberTrustRoot.crt.pem  -keystore truststore -storepass password -noprompt

      keytool -importcert -alias PostgreSQLServerCACert2  -file D:\DigiCertGlobalRootG2.crt.pem -keystore truststore -storepass password  -noprompt

      Ersätt sedan den ursprungliga nyckellagringsfilen med den nya genererade:

      • System.setProperty("javax.net.ssl.trustStore","path_to_truststore_file");
      • System.setProperty("javax.net.ssl.trustStorePassword","password");

    • För .NET-användare (Npgsql) i Windows kontrollerar du att Baltimore CyberTrust Root och DigiCert Global Root G2 båda finns i Windows Certificate Store, betrodda rotcertifikatutfärdare. Om det inte finns några certifikat importerar du det saknade certifikatet.

      Azure Database for PostgreSQL .net cert

    • För .NET-användare (Npgsql) i Linux med SSL_CERT_DIR kontrollerar du att Både BaltimoreCyberTrustRoot och DigiCertGlobalRootG2 finns i katalogen som anges av SSL_CERT_DIR. Om det inte finns några certifikat skapar du den saknade certifikatfilen.

    • För andra PostgreSQL-klientanvändare kan du sammanfoga två CA-certifikatfiler som det här formatet nedan


      -----BEGIN CERTIFICATE-----
      (Root CA1: BaltimoreCyberTrustRoot.crt.pem)
      -----END CERTIFICATE-----
      -----BEGIN CERTIFICATE-----
      (Root CA2: DigiCertGlobalRootG2.crt.pem)
      -----END CERTIFICATE-----

  • Ersätt den ursprungliga rot-CA pem-filen med den kombinerade rot-CA-filen och starta om programmet/klienten.

  • När det nya certifikatet har distribuerats på serversidan kan du i framtiden ändra din CA pem-fil till DigiCertGlobalRootG2.crt.pem.

Kommentar

Ta inte bort eller ändra Baltimore-certifikatet förrän certifikatändringen har gjorts. Vi skickar en kommunikation när ändringen är klar, varefter det är säkert för dem att släppa Baltimore-certifikatet.

Tänk om vi tog bort BaltimoreCyberTrustRoot-certifikatet?

Du kan börja få anslutningsfel när du ansluter till din Azure Database for PostgreSQL-server. Du måste konfigurera SSL med BaltimoreCyberTrustRoot-certifikatet igen för att upprätthålla anslutningen.

Vanliga frågor och svar

1. Behöver jag fortfarande uppdatera rotcertifikatutfärdare om jag inte använder SSL/TLS?

Inga åtgärder krävs om du inte använder SSL/TLS.

2. Behöver jag starta om databasservern för att uppdatera rotcertifikatutfärdare om jag använder SSL/TLS?

Nej, du behöver inte starta om databasservern för att börja använda det nya certifikatet. Det här är en ändring på klientsidan och de inkommande klientanslutningarna måste använda det nya certifikatet för att säkerställa att de kan ansluta till databasservern.

3. Hur gör jag för att vet om jag använder SSL/TLS med rotcertifikatverifiering?

Du kan identifiera om dina anslutningar verifierar rotcertifikatet genom att granska din anslutningssträng.

  • Om din anslutningssträng innehåller sslmode=verify-ca eller sslmode=verify-fullmåste du uppdatera certifikatet.
  • Om din anslutningssträng innehåller sslmode=disable, sslmode=allow, sslmode=prefereller sslmode=require, behöver du inte uppdatera certifikat.
  • Om din anslutningssträng inte anger sslmode behöver du inte uppdatera certifikat.

Om du använder en klient som abstraherar bort anslutningssträng läser du klientens dokumentation för att förstå om den verifierar certifikat. Om du vill förstå PostgreSQL sslmode läser du beskrivningarna av SSL-läge i PostgreSQL-dokumentationen.

4. Vad är effekten om du använder App Service med Azure Database for PostgreSQL?

För Azure-apptjänster som ansluter till Azure Database for PostgreSQL kan vi ha två möjliga scenarier och det beror på hur du använder SSL med ditt program.

  • Det här nya certifikatet har lagts till i App Service på plattformsnivå. Om du använder de SSL-certifikat som ingår på App Service-plattformen i ditt program behövs ingen åtgärd.
  • Om du uttryckligen inkluderar sökvägen till SSL-certifikatfilen i koden måste du ladda ned det nya certifikatet och uppdatera koden för att använda det nya certifikatet. Ett bra exempel på det här scenariot är när du använder anpassade containrar i App Service som delas i App Service-dokumentationen

5. Vad är effekten om du använder Azure Kubernetes Services (AKS) med Azure Database for PostgreSQL?

Om du försöker ansluta till Azure Database for PostgreSQL med hjälp av Azure Kubernetes Services (AKS) liknar det åtkomst från en värdmiljö för dedikerade kunder. Se stegen här.

6. Vad är effekten om du använder Azure Data Factory för att ansluta till Azure Database for PostgreSQL?

För anslutningsprogram som använder Azure Integration Runtime använder anslutningsappen certifikat i Windows Certificate Store i den Azure-värdbaserade miljön. Dessa certifikat är redan kompatibla med de nyligen tillämpade certifikaten och därför behövs ingen åtgärd.

För anslutningsprogram med lokalt installerad integrationskörning där du uttryckligen inkluderar sökvägen till SSL-certifikatfilen i din anslutningssträng måste du ladda ned det nya certifikatet och uppdatera anslutningssträng för att använda det.

7. Behöver jag planera en stilleståndstid för databasserverunderhåll för den här ändringen?

Nej. Eftersom ändringen här endast finns på klientsidan för att ansluta till databasservern behövs ingen underhållsavbrottstid för databasservern för den här ändringen.

8. Kommer jag att påverkas om jag skapar en ny server efter den 30 november 2022?

För servrar som skapats efter den 30 november 2022 fortsätter du att använda BaltimoreCyberTrustRoot tillsammans med nya DigiCertGlobalRootG2-rotcertifikat i databasklientens SSL-certifikatarkiv för dina program för att ansluta med SSL.

9. Hur ofta uppdaterar Microsoft sina certifikat eller vad är förfalloprincipen?

Dessa certifikat som används av Azure Database for PostgreSQL tillhandahålls av betrodda certifikatutfärdare (CA). Så stödet för dessa certifikat är kopplat till stöd för dessa certifikat av CA. BaltimoreCyberTrustRoot-certifikatet är schemalagt att upphöra att gälla 2025, så Microsoft måste utföra en certifikatändring innan det upphör att gälla. Även om det finns oförutsedda buggar i dessa fördefinierade certifikat måste Microsoft göra certifikatrotationen tidigast som den ändring som utfördes den 15 februari 2021 för att säkerställa att tjänsten alltid är säker och kompatibel.

10. Om jag använder skrivskyddade repliker behöver jag bara utföra den här uppdateringen på den primära servern eller skrivskyddade repliker?

Eftersom den här uppdateringen är en ändring på klientsidan måste du även tillämpa ändringarna för dessa klienter om klienten använde för att läsa data från replikservern.

11. Har vi frågor på serversidan för att kontrollera om SSL används?

För att kontrollera om du använder SSL-anslutning för att ansluta till servern, se SSL-verifiering.

12. Krävs det en åtgärd om jag redan har DigiCertGlobalRootG2 i min certifikatfil?

Nej. Det krävs ingen åtgärd om certifikatfilen redan har DigiCertGlobalRootG2.

13. Hur kan jag kontrollera certifikatet som skickas av servern?

Det finns många verktyg som du kan använda. DigiCert har till exempel ett praktiskt verktyg som visar certifikatkedjan för valfritt servernamn. (Det här verktyget fungerar med offentligt tillgänglig server. Det går inte att ansluta till servern som finns i ett virtuellt nätverk (VNET).) Ett annat verktyg som du kan använda är OpenSSL på kommandoraden. Du kan använda den här syntaxen för att kontrollera certifikat:

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

14. Vad händer om jag har ytterligare frågor?

Om du har frågor kan du få svar från communityexperter i Vanliga frågor och svar om Microsoft. Om du har en supportplan och behöver teknisk hjälp skapar du en supportbegäran:

  • Som Typ av problem väljer du Teknisk.
  • För Prenumeration väljer du din prenumeration.
  • För Tjänst väljer du Mina tjänster och sedan Azure Database for PostgreSQL – enskild server.
  • För Problemtyp väljer du Säkerhet.
  • För Problemundertyp väljer du Dubbel kryptering för Azure-kryptering och infrastruktur