Share via

Grundlegendes zu den Änderungen im Zusammenhang mit der Stammzertifizierungsstelle für Azure Database for PostgreSQL-Einzelserver

  • Artikel

GILT FÜR: Azure Database for PostgreSQL – Single Server

Wichtig

Azure Database for PostgreSQL – Single Server wird eingestellt. Es wird dringend empfohlen, ein Upgrade auf Azure Database for PostgreSQL – Flexible Server auszuführen. Weitere Informationen zum Migrieren zu Azure Database for PostgreSQL – Flexible Server finden Sie unter Was geschieht mit Azure Database for PostgreSQL – Single Server?

Die Änderung des Stammzertifikats wird ab Dezember 2022 (12/2022) für Azure Database for PostgreSQL Single Server im Rahmen der standardmäßigen Wartung und bewährten Sicherheitsmethoden geplant. In diesem Artikel erhalten Sie ausführlichere Informationen zu den Änderungen, den betroffenen Ressourcen sowie den Schritten, die erforderlich sind, um sicherzustellen, dass die Konnektivität Ihrer Anwendung mit dem Datenbankserver bestehen bleibt.

Warum muss das Stammzertifikat aktualisiert werden?

Bisher konnten Azure Database for PostgreSQL-Kunden nur dieses vordefinierte Zertifikat verwenden, um eine Verbindung mit ihrem PostgreSQL-Server herzustellen. Im Zertifizierungsstellen-Browserforum wurden jedoch kürzlich gemeldet, dass mehrere von Zertifizierungsstellenanbietern ausgestellte Zertifikate nicht konform sind.

Gemäß den Konformitätsanforderungen der Branche haben Zertifizierungsstellenanbieter damit begonnen, Zertifizierungsstellenzertifikate für nicht konforme Zertifizierungsstellen zu sperren. Daher müssen Server Zertifikate verwenden, die von konformen Zertifizierungsstellen ausgestellt und durch Zertifizierungsstellenzertifikate von diesen konformen Zertifizierungsstellen signiert wurden. Da von Azure Database for PostgreSQL eines dieser nicht konformen Zertifikate verwendet wurde, musste das Zertifikat zur konformen Version rotiert werden, um die potenzielle Bedrohung für Ihre Postgres-Server zu minimieren.

Der Rollout des neuen Zertifikats im Dezember 2022 (12/2022) begonnen, und es ist seitdem Datum gültig.

Welche Änderung sollte ab Dezember 2022 (12/2022) durchgeführt werden?

Ab Dezember 2022 wird das BaltimoreCyberTrustRoot-Stammzertifikat durch eine kompatible Version ersetzt, die als DigiCertGlobalRootG2-Stammzertifikat bekannt ist. Wenn Ihre Anwendungen verify-ca oder verify-full als Wert des sslmode-Parameters in der Konnektivität des Datenbankclients verwenden, müssen Sie die Anweisungen befolgen, um dem Zertifikatspeicher neue Zertifikate hinzuzufügen, um die Konnektivität zu erhalten.

Muss ich Änderungen an meinem Client vornehmen, um die Konnektivität aufrechtzuerhalten?

Clientseitige Code- oder Anwendungsänderungen sind nicht erforderlich. Wenn Sie unsere Empfehlung zur Zertifikatsaktualisierung befolgen, können Sie weiterhin eine Verbindung herstellen, solange das BaltimoreCyberTrustRoot-Zertifikat nicht aus dem kombinierten ZS-Zertifikat entfernt wird. Es wird empfohlen, das BaltimoreCyberTrustRoot-Zertifikat bis auf Weiteres nicht aus dem kombinierten Zertifizierungsstellenzertifikat zu entfernen, um die Konnektivität aufrechtzuerhalten.

Muss ich irgendwelche Änderungen an den Clientzertifikaten vornehmen?

Standardmäßig führt PostgreSQL keine Überprüfung des Serverzertifikats durch. Das bedeutet, dass es theoretisch immer noch möglich ist, die Identität des Servers zu spoofen (z. B. durch Änderung eines DNS-Eintrags oder durch Übernahme der IP-Adresse des Servers), ohne dass der Client davon weiß. Um die Möglichkeit des Spoofings zu verhindern, muss die SSL-Zertifikatüberprüfung auf dem Client verwendet werden. Eine solche Überprüfung kann über den ssl mode-Wert der Verbindungszeichenfolge des Anwendungsclients konfiguriert werden – verify-ca oder verify-full. Wenn diese SSL-Modus-Werte ausgewählt werden, sollten Sie die Anweisungen im nächsten Abschnitt befolgen.

Empfehlung zur Clientzertifikataktualisierung

  • Laden Sie die Stammzertifizierungsstellen BaltimoreCyberTrustRoot und DigiCertGlobalRootG2 über die folgenden Links herunter:

  • Optional, um zukünftige Unterbrechungen zu vermeiden, wird auch empfohlen, dem Vertrauensspeicher die folgenden Stämme hinzuzufügen:

  • Generieren Sie einen kombinierten Zertifizierungsstellen-Zertifikatspeicher, in dem sowohl BaltimoreCyberTrustRoot als auch DigiCertGlobalRootG2 enthalten sind.

    • Führen Sie für Java-Benutzer (PostgreSQL-JDBC) mit DefaultJavaSSLFactory Folgendes aus:

      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

      Ersetzen Sie dann die ursprüngliche Keystore-Datei durch die neu generierte Datei:

      • System.setProperty("javax.net.ssl.trustStore","Pfad_zur_Truststore-Datei");
      • System.setProperty("javax.net.ssl.trustStorePassword","Kennwort");

    • Stellen Sie für .NET-Benutzer (Npgsql) unter Windows sicher, dass Baltimore CyberTrust Root und DigiCert Global Root G2 als vertrauenswürdige Stammzertifizierungsstellen im Windows-Zertifikatspeicher vorhanden sind. Ist eines der Zertifikate nicht vorhanden, importieren Sie das fehlende Zertifikat.

      Azure Database for PostgreSQL-.NET-Zertifikat

    • Stellen Sie bei .NET-Benutzern (Npgsql) unter Linux, die SSL_CERT_DIR verwenden, sicher, dass BaltimoreCyberTrustRoot und DigiCertGlobalRootG2 in dem durch SSL_CERT_DIR angegebenen Verzeichnis enthalten sind. Ist eines der Zertifikate nicht vorhanden, erstellen Sie die fehlende Zertifikatsdatei.

    • Für andere PostgreSQL-Client Benutzer können Sie zwei ZS-Zertifikats Dateien wie in diesem Format weiter unten zusammenführen.


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

  • Ersetzen Sie die ursprüngliche PEM-Datei der Stammzertifizierungsstelle durch die kombinierte Datei der Stammzertifizierungsstelle, und starten Sie die Anwendung bzw. den Client neu.

  • Nachdem das neue Zertifikat auf der Serverseite bereitgestellt wurde, können Sie die PEM-Datei der Zertifizierungsstelle in Zukunft in „DigiCertGlobalRootG2.crt.pem“ ändern.

Hinweis

Bitte löschen oder ändern Sie das Baltimore-Zertifikat erst, nachdem die Zertifikatänderung vorgenommen wurde. Sobald dies abgeschlossen ist, senden wir Ihnen eine Mitteilung,und danach kann das Baltimore-Zertifikat sicher gelöscht werden.

Was geschieht, wenn das BaltimoreCyberTrustRoot-Zertifikat entfernt wurde?

Beim Herstellen einer Verbindung mit dem Azure Database for PostgreSQL-Server erhalten Sie möglicherweise Konnektivitätsfehler. Sie müssen SSL erneut mit dem BaltimoreCyberTrustRoot-Zertifikat konfigurieren, um die Konnektivität zu gewährleisten.

Häufig gestellte Fragen

1. Muss ich die Stammzertifizierungsstelle auch aktualisieren, wenn ich SSL/TLS nicht verwende?

Wenn Sie SSL/TLS nicht verwenden, sind keine Schritte erforderlich.

2. Muss ich bei Verwendung von SSL/TLS meinen Datenbankserver neu starten, um die Stammzertifizierungsstelle zu aktualisieren?

Nein, der Datenbankserver muss nicht neu gestartet werden, damit das neue Zertifikat verwendet werden kann. Es handelt sich um eine clientseitige Änderung, und die eingehenden Clientverbindungen müssen das neue Zertifikat verwenden, um sicherzustellen, dass sie eine Verbindung mit dem Datenbankserver herstellen können.

3. Wie kann ich feststellen, ob ich SSL/TLS mit Stammzertifikatüberprüfung verwende?

Durch Überprüfen der Verbindungszeichenfolge können Sie ermitteln, ob Ihre Verbindungen das Stammzertifikat überprüfen.

  • Wenn Ihre Verbindungszeichenfolge sslmode=verify-ca oder sslmode=verify-full enthält, müssen Sie das Zertifikat aktualisieren.
  • Wenn Ihre Verbindungszeichenfolge sslmode=disable, sslmode=allow, sslmode=prefer oder sslmode=require enthält, müssen Sie keine Zertifikate aktualisieren.
  • Wenn in Ihrer Verbindungszeichenfolge „sslmode“ nicht angegeben ist, müssen Sie keine Zertifikat aktualisieren.

Wenn Sie einen Client verwenden, der die Verbindungszeichenfolge abstrahiert, lesen Sie die Dokumentation des Clients, um zu ermitteln, ob Zertifikate überprüft werden. Um den PostgreSQL-SSL-Modus zu verstehen, lesen Sie die Beschreibungen des SSL-Modus in der PostgreSQL-Dokumentation.

4. Welche Auswirkungen hat es, wenn App Service mit Azure Database for PostgreSQL verwendet wird?

Für Azure App Service-Instanzen, die eine Verbindung mit Azure Database for PostgreSQL herstellen, gibt es zwei mögliche Szenarien, je nachdem, wie Sie SSL mit Ihrer Anwendung verwenden.

  • Das neue Zertifikat wurde App Service auf Plattformebene hinzugefügt. Wenn Sie die SSL-Zertifikate verwenden, die in der App Service-Plattform in Ihrer Anwendung enthalten sind, ist keine Aktion erforderlich.
  • Wenn Sie den Pfad zur SSL-Zertifikatsdatei explizit in Ihren Code einschließen, müssen Sie das neue Zertifikat herunterladen und den Code so aktualisieren, dass das neue Zertifikat verwendet wird. Ein gutes Beispiel für dieses Szenario: Wenn Sie benutzerdefinierte Container in App Service so verwenden, wie in der App Service-Dokumentation zu lesen ist.

5. Welche Auswirkungen hat es, wenn Azure Kubernetes Service (AKS) mit Azure Database for PostgreSQL verwendet wird?

Wenn Sie versuchen, mithilfe von Azure Kubernetes Service (AKS) eine Verbindung mit Azure Database for PostgreSQL herzustellen, ähnelt dies dem Zugriff über eine dedizierte Kundenhostumgebung. Die entsprechenden Schritte finden Sie hier.

6. Welche Auswirkungen hat es, wenn Azure Data Factory zum Herstellen einer Verbindung mit Azure Database for PostgreSQL verwendet wird?

Ein Connector, der Azure Integration Runtime verwendet, nutzt Zertifikate im Windows-Zertifikatspeicher in der von Azure gehosteten Umgebung. Diese Zertifikate sind bereits mit den neu angewendeten Zertifikaten kompatibel, daher ist keine Aktion erforderlich.

Bei einem Connector, der die selbstgehostete Integration Runtime verwendet, für die Sie den Pfad zur SSL-Zertifikatsdatei explizit in die Verbindungszeichenfolge einschließen, müssen Sie das neue Zertifikat herunterladen und die Verbindungszeichenfolge aktualisieren, um ihn zu verwenden.

7. Muss ich für diese Änderung eine Wartungsdowntime für den Datenbankserver planen?

Nein. Da die Änderung hier nur auf der Clientseite erfolgt, um eine Verbindung mit dem Datenbankserver herzustellen, ist für diese Änderung keine Wartungsdowntime beim Datenbankserver erforderlich.

8. Bin ich betroffen, wenn ich nach dem 30. November 2022 einen neuen Server erstelle?

Für Server, die nach dem 30. November 2022 erstellt werden, werden Sie weiterhin BaltimoreCyberTrustRoot zusammen mit neuen DigiCertGlobalRootG2-Stammzertifikaten im SSL-Zertifikatspeicher Ihres Datenbankclients für Ihre Anwendungen verwenden, um eine Verbindung mit SSL herzustellen.

9. Wie oft aktualisiert Microsoft seine Zertifikate, bzw. welche Ablaufrichtlinie gilt?

Diese von Azure Database for PostgreSQL verwendeten Zertifikate werden von vertrauenswürdigen Zertifizierungsstellen (ZS) bereitgestellt. Die Unterstützung dieser Zertifikate ist also an die Unterstützung dieser Zertifikate durch die ZS gebunden. Der Ab lauf des BaltimoreCyberTrustRoot-Zertifikats ist auf 2025 geplant, sodass Microsoft vor dem Ablauf eine Zertifikatsänderung durchführen muss. Sollten in diesen vordefinierten Zertifikaten unvorhergesehene Fehler auftreten, muss Microsoft die Zertifikatsrotation schnellstmöglich durchführen, ähnlich wie bei der Änderung am 15. Februar 2021, um zu gewährleisten, dass der Dienst jederzeit sicher und konform ist.

10, Muss ich bei Verwendung von Lesereplikaten dieses Update nur für den primären Server oder auch für die Lesereplikate ausführen?

Da dieses Update eine clientseitige Änderung ist, müssen Sie die Änderungen auch für die Clients anwenden, die Daten vom Replikatserver gelesen haben.

11. Gibt es eine serverseitige Abfrage, um zu überprüfen, ob SSL verwendet wird?

Um zu überprüfen, ob Sie eine SSL-Verbindung zum Herstellen einer Verbindung mit dem Server verwenden, lesen Sie die Informationen unter Überprüfen der SSL-Verbindung.

12. Ist eine Aktion erforderlich, wenn sich DigiCertGlobalRootG2 bereits in meiner Zertifikatsdatei befindet?

Nein Wenn in Ihrer Zertifikatsdatei DigiCertGlobalRootG2 bereits enthalten ist, ist keine Aktion erforderlich.

13. Wie kann ich das vom Server gesendete Zertifikat überprüfen?

Dafür bieten sich zahlreiche Tools an. DigiCert bietet beispielsweise ein praktisches Tool, das Ihnen die Zertifikatkette für einen beliebigen Servernamen zeigt. (Dieses Tool funktioniert nur mit einem öffentlich zugänglichen Server. Es kann keine Verbindung mit einem Server in einem virtuellen Netzwerk (VNet) herstellen). Ein weiteres Tool, das Sie verwenden können, ist OpenSSL in der Befehlszeile, und Sie können diese Syntax zur Prüfung der Zertifikate verwenden:

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

14. Wie gehe ich vor, wenn ich weitere Fragen habe?

Bei Fragen können Sie Antworten von Communityexperten auf Microsoft Q&A erhalten. Wenn Sie über einen Supportplan verfügen und technische Hilfe benötigen, erstellen Sie eine Supportanfrage:

  • Wählen Sie als Problemtyp die Option Technisch aus.
  • Wählen Sie unter Abonnement Ihr Abonnement aus.
  • Wählen Sie unter Dienst die Option Meine Dienste und dann Azure Database for PostgreSQL – Einzelserver aus.
  • Wählen Sie unter Problemtyp die Option Sicherheit aus.
  • Wählen Sie unter Problemuntertyp die Optionen „Azure-Verschlüsselung“ und „Infrastruktur-Mehrfachverschlüsselung“ aus.