SQL Server: TLS-Zertifikat austauschen

Die SQL-Server-Datenbank-Engine wählt pro Instanz ein TLS-Zertifikat. Es muss im Zertifikatspeicher des lokalen Computers liegen, für das Dienstkonto von SQL Server lesbar sein, für die Instanz ausgewählt und durch einen Neustart der Instanz aktiviert werden.

VoraussetzungenCopy Anchor Link

• Besorgen Sie ein Zertifikat, das Microsofts Anforderungen für SQL Server erfüllt: EKU Serverauthentifizierung, ein privater Schlüssel und die Namen, mit denen Clients sich verbinden (Server-FQDN, Listener der Verfügbarkeitsgruppe, virtueller Name der Clusterinstanz), im Antragsteller oder SAN.
• Notieren Sie Instanz, Dienstkonto, Fingerabdruck des aktuellen Zertifikats, die Einstellung Verschlüsselung erzwingen (Force Encryption), Listener von Verfügbarkeitsgruppen und Clusterknoten.
• Das Dienstkonto finden Sie im SQL Server-Konfigurations-Manager > SQL Server-Dienste (Spalte Anmelden als). Standard ist ein virtuelles Konto wie NT Service\MSSQLSERVER.
• Behalten Sie das alte Zertifikat im Speicher, bis das neue geprüft ist - es ist Ihr Rollback.
• Planen Sie einen Failover oder ein Wartungsfenster: Ein Neustart der Datenbank-Engine trennt die Clients.

Wie SQL Server ein Zertifikat auswähltCopy Anchor Link

SQL Server verwendet in dieser Reihenfolge:

1. das im SQL Server-Konfigurations-Manager ausgewählte Zertifikat (als Fingerabdruck im Registry-Wert SuperSocketNetLib\Certificate der Instanz gespeichert),
2. falls keines ausgewählt ist: ein Zertifikat aus dem Speicher des lokalen Computers, dessen Antragsteller den FQDN der Maschine enthält und dessen privaten Schlüssel das Dienstkonto lesen kann - auch wenn niemand es ausgewählt hat,
3. sonst ein selbst erzeugtes Zertifikat.

Wählen Sie das neue Zertifikat deshalb ausdrücklich aus. Bleibt die Auswahl leer und verlassen Sie sich auf Punkt 2, nimmt SQL Server womöglich ein Zertifikat, das Sie gar nicht meinten.

Zertifikat Schritt für Schritt austauschenCopy Anchor Link

Mit dem SQL Server-Konfigurations-Manager ab 2019Copy Anchor Link

Ab SQL Server 2019 hat der Konfigurations-Manager eine integrierte Zertifikatsverwaltung: Er importiert das Zertifikat, gibt dem Dienstkonto Zugriff auf den Schlüssel und wählt es für die Instanz aus - für eine Einzelinstanz, eine Failover-Clusterinstanz oder eine Verfügbarkeitsgruppe. Die Masken beschreibt Microsoft in Zertifikatverwaltung (SQL Server-Konfigurations-Manager) (unter Quellen verlinkt). Dieser Konfigurations-Manager funktioniert auch für ältere SQL-Server-Versionen; Microsoft empfiehlt, ihn bei Bedarf aus einem Setup von SQL Server 2019 Express oder neuer zu installieren. Starten Sie die Instanz danach neu (für eine Failover-Clusterinstanz siehe unten).

Manuell (jede Version)Copy Anchor Link

1. Importieren Sie die PFX-Datei unter Zertifikate (Lokaler Computer) > Eigene Zertifikate auf jedem Knoten, der die Instanz oder ein Replikat einer Verfügbarkeitsgruppe hosten kann.

2. Klicken Sie in certlm.msc (der Zertifikatskonsole des lokalen Computers) mit der rechten Maustaste auf das Zertifikat > Alle Aufgaben > Private Schlüssel verwalten und geben Sie dem Dienstkonto von SQL Server Lesen. Ohne diese Berechtigung startet der Dienst unter Umständen nicht.

3. Öffnen Sie im SQL Server-Konfigurations-Manager SQL Server-Netzwerkkonfiguration > Protokolle für <Instanz> > Eigenschaften > Zertifikat und wählen Sie das neue Zertifikat.

4. Starten Sie nur diesen SQL-Server-Dienst neu, im Wartungsfenster:

   Copy Text

   Restart-Service MSSQLSERVER        # Standardinstanz
   # Restart-Service 'MSSQL$INSTANCE' # benannte Instanz

5. Nur bei Verfügbarkeitsgruppen: auf jedem Replikat wiederholen. Microsofts Ablauf beginnt mit dem primären Replikat; führen Sie einen Failover der Verfügbarkeitsgruppe durch, bevor Sie ein Replikat neu starten, das gerade primär ist.

Verschlüsselung erzwingen (Reiter Flags) ist eine eigene Entscheidung: Der Server verlangt dann Verschlüsselung von jedem Client. Ab SQL Server 2022 gibt es zusätzlich Strikte Verschlüsselung erzwingen (TDS 8.0). Beides gehört nicht in eine Routine-Erneuerung, solange Sie die Auswirkungen auf die Clients nicht geplant haben.

Failover-Clusterinstanzen und WildcardsCopy Anchor Link

In zwei Fällen setzen Sie den Registry-Wert HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\<Instanz>\MSSQLServer\SuperSocketNetLib\Certificate von Hand - den Fingerabdruck des Zertifikats ohne Leerzeichen:

• Failover-Clusterinstanz (manueller Weg): Laut Microsoft ist dieser Wert auf Clusterknoten leer, obwohl das Zertifikat im Speicher liegt. Installieren Sie das Zertifikat (mit Schlüsselberechtigung) auf jedem Knoten, dann auf jedem Knoten nacheinander: Wert setzen, die SQL-Server-Rolle auf einen anderen Knoten verschieben und den Knoten neu starten, auf dem Sie die Registry geändert haben. Das Zertifikat muss den virtuellen Servernamen des Clusters enthalten. Starten und stoppen Sie eine Clusterinstanz über den Failovercluster-Manager, nicht mit Restart-Service.
• Wildcard-Zertifikat: Der Konfigurations-Manager kann kein Wildcard-Zertifikat auswählen. Importieren Sie es und vergeben Sie die Schlüsselberechtigung wie in Schritt 1-2, und setzen Sie dann statt Schritt 3 seinen Fingerabdruck im Registry-Wert.

Fingerabdruck ohne Leerzeichen auslesen:

Get-ChildItem Cert:\LocalMachine\My | Format-Table Thumbprint,Subject,NotAfter

<Instanz> im Pfad ist die Instanz-ID, etwa MSSQL16.MSSQLSERVER. Vor SQL Server 2022 CU22 und SQL Server 2025 zeigt der Konfigurations-Manager ein über die Registry gesetztes Zertifikat nur an, wenn Groß- und Kleinschreibung des Fingerabdrucks genau dem Speicher entsprechen; SQL Server verwendet es trotzdem.

Neues Zertifikat prüfenCopy Anchor Link

1. Prüfen Sie, ob die Auswahl (Konfigurations-Manager oder Registry-Wert) den neuen Fingerabdruck zeigt.
2. Prüfen Sie nach dem Neustart das SQL-Server-Fehlerprotokoll (in SSMS unter Verwaltung > SQL Server-Protokolle). Die Meldung "A self-generated certificate was successfully loaded for encryption" bedeutet, dass Ihr Zertifikat nicht verwendet wird.
3. Verbinden Sie sich von einem Client mit Verschlüsselung und Zertifikatsprüfung - etwa SSMS mit Encrypt auf Mandatory und deaktiviertem Trust server certificate, über den exakten Server- oder Listener-Namen. Das gelingt nur, wenn der Server ein gültiges Zertifikat für diesen Namen vorlegt, und beweist damit, dass Ihr Zertifikat verwendet wird.
4. Prüfen Sie, ob die Verbindungen verschlüsselt sind:

SELECT DISTINCT encrypt_option
FROM sys.dm_exec_connections
WHERE net_transport <> 'Shared memory';

TRUE heißt verschlüsselt. Allein beweist das nicht, welches Zertifikat verwendet wird - auch ein selbst erzeugtes verschlüsselt -, deshalb ist Schritt 3 der eigentliche Test. Testen Sie nie mit TrustServerCertificate=True; das verdeckt Namens- und Vertrauensprobleme.

Wenn der Dienst nicht startetCopy Anchor Link

Suchen Sie den Grund im Fehlerprotokoll von SQL Server und im Windows-Ereignisprotokoll Anwendung. Häufigste Ursache ist eine fehlende Schlüsselberechtigung: vergeben (Schritt 2) und den Dienst erneut starten. Um die Instanz sofort wieder in Betrieb zu nehmen, leeren Sie die Zertifikatsauswahl (Konfigurations-Manager oder Registry-Wert) - sie startet dann mit einem selbst erzeugten Zertifikat - und korrigieren das Zertifikat danach.

RollbackCopy Anchor Link

Wählen Sie im Konfigurations-Manager wieder das alte Zertifikat (oder stellen Sie den alten Fingerabdruck im Registry-Wert wieder her), prüfen Sie seine Schlüsselberechtigung und starten Sie die Instanz neu. Das geht nur, solange das alte Zertifikat noch im Speicher liegt und gültig ist. In einer Hochverfügbarkeitsumgebung schwenken Sie erst zurück, wenn der wiederhergestellte Knoten einen Clienttest besteht.

Häufige ProblemeCopy Anchor Link

• Das Dienstkonto kann den privaten Schlüssel nicht lesen, die Instanz startet nicht.
• Im SAN fehlen Listener der Verfügbarkeitsgruppe, Clustername oder Client-Alias.
• Das Zertifikat liegt im Speicher des aktuellen Benutzers statt des lokalen Computers.
• Nur das aktuelle primäre Replikat oder ein Clusterknoten wurde aktualisiert.
• Es wurde kein Zertifikat ausgewählt, und SQL Server hat ein anderes aus dem Speicher genommen.
• Clients verdecken Vertrauens- oder Namensfehler mit TrustServerCertificate=True.

Zertifikatstausch mit aethercert automatisierenCopy Anchor Link

Das aethercert-Deployment-Ziel für SQL Server importiert das Zertifikat, kann dem konfigurierten Dienstkonto Lesezugriff auf den privaten Schlüssel geben, schreibt die Zertifikatsauswahl der Instanz und kann den Dienst neu starten, wenn das ausdrücklich aktiviert ist.

Unter Deployment-Ziele finden Sie die Felder dieser Vorlage, die Voraussetzungen auf dem Host und den Stand der Verifizierung.

QuellenCopy Anchor Link

• Microsoft Learn: Verbindungen durch Importieren eines Zertifikats verschlüsseln
• Microsoft Learn: Zertifikatanforderungen für SQL Server
• Microsoft Learn: Zertifikatverwaltung im SQL Server-Konfigurations-Manager