Freigeben über

Transport Layer Security und digitale Zertifikate

In diesem Artikel werden Details zu den Tls-Zertifikaten (Protocol Transport Layer Security) und digitalen Zertifikaten beschrieben.

Transport Layer Security (TLS) (Transportschichtsicherheit)

Die TLS- und SSL-Protokolle befinden sich zwischen der Anwendungsprotokollebene und der TCP/IP-Ebene, auf der sie Anwendungsdaten sichern und an die Transportschicht senden können. TLS/SSL-Protokolle verwenden Algorithmen aus einer Verschlüsselungssuite , um Schlüssel zu erstellen und Informationen zu verschlüsseln. Der Client und der Server verhandeln die Protokollversion und die Verschlüsselungssuite, die während der ersten Verbindungsphase (Pre-Login) der Verbindungseinrichtung verwendet werden soll. Im TLS-Handshake wird immer die höchste unterstützte TLS-Version bevorzugt. Informationen zum Überprüfen der von verschiedenen Versionen von Windows-Betriebssystemen unterstützten TLS-Protokolle finden Sie unter "Protokolle in TLS/SSL (Schannel SSP)". Mehrere bekannte Sicherheitsrisiken wurden mit SSL und früheren Versionen von TLS gemeldet. Es wird empfohlen, ein Upgrade auf TLS 1.2 für sichere Kommunikation durchzuführen.

SQL Server kann TLS zum Verschlüsseln der Daten verwenden, die über ein Netzwerk zwischen einer Clientanwendung und einer Instanz von SQL Server übertragen werden. TLS verwendet ein Zertifikat, um die Verschlüsselung zu implementieren.

Das Aktivieren der TLS-Verschlüsselung erhöht die Sicherheit von Daten, die netzwerkübergreifend zwischen Instanzen von SQL Server und Anwendungen übertragen werden. Wenn jedoch der gesamte Datenverkehr zwischen SQL Server und einer Clientanwendung mithilfe von TLS verschlüsselt wird, ist die folgende zusätzliche Verarbeitung erforderlich:

  • Ein zusätzlicher Netzwerkroundtrip ist zum Zeitpunkt des Verbindungsaufbaus erforderlich.
  • Pakete, die von der Anwendung an die Instanz von SQL Server gesendet werden, müssen vom TLS-Stapel des Clients verschlüsselt und vom Server-TLS-Stapel entschlüsselt werden.
  • Pakete, die von der Instanz von SQL Server an die Anwendung gesendet werden, müssen vom TLS-Stapel des Servers verschlüsselt und vom Client-TLS-Stapel entschlüsselt werden.

Wichtig

Ab SQL Server 2016 (13.x) wurde ssl (Secure Sockets Layer) nicht mehr unterstützt. Verwenden Sie stattdessen TLS (TLS 1.2 wird empfohlen). Weitere Informationen finden Sie unter TLS 1.2-Unterstützung für Microsoft SQL Server. SQL Server 2022 bietet Unterstützung für TLS 1.3. Weitere Informationen finden Sie unter TLS 1.3-Unterstützung. Wenn keine übereinstimmenden Protokolle zwischen dem Client und dem Servercomputer vorhanden sind, kann der Fehler auftreten, dass eine vorhandene Verbindung vom Remotehost zwangsweise geschlossen wurde.

Übersicht über digitale Zertifikate

Digitale Zertifikate sind elektronische Dateien, die wie ein Onlinekennwort funktionieren, um die Identität eines Benutzers oder eines Computers zu überprüfen. Sie werden verwendet, um den verschlüsselten Kanal zu erstellen, der für die Clientkommunikation verwendet wird. Ein Zertifikat ist eine digitale Erklärung, die von einer Zertifizierungsstelle (CA) ausgestellt wird, die für die Identität des Zertifikatinhabers sorgt und es den Parteien ermöglicht, mithilfe der Verschlüsselung sicher zu kommunizieren.

Digitale Zertifikate stellen die folgenden Dienste bereit:

  • Verschlüsselung: Sie schützen die Daten, die vor Diebstahl oder Manipulation ausgetauscht werden.
  • Authentifizierung: Sie überprüfen, ob ihre Inhaber (Personen, Websites und sogar Netzwerkgeräte wie Router) wirklich wer oder was sie sein wollen. Typischerweise ist die Authentifizierung einseitig, bei der die Quelle die Identität des Ziels verifiziert, jedoch ist auch eine gegenseitige TLS-Authentifizierung möglich.

Ein Zertifikat enthält einen öffentlichen Schlüssel und fügt diesen öffentlichen Schlüssel an die Identität einer Person, eines Computers oder diensts an, der den entsprechenden privaten Schlüssel enthält. Die öffentlichen und privaten Schlüssel werden vom Client und vom Server verwendet, um Daten zu verschlüsseln, bevor sie übertragen werden. Bei Windows-Benutzern, Computern und Diensten wird die Vertrauensstellung in der Zertifizierungsstelle festgelegt, wenn das Stammzertifikat im vertrauenswürdigen Stammzertifikatspeicher definiert ist und das Zertifikat einen gültigen Zertifizierungspfad enthält. Ein Zertifikat gilt als gültig, wenn es nicht widerrufen wurde (es befindet sich nicht in der Zertifikatsperrliste oder CRL der Zertifizierungsstelle) oder abgelaufen.

Die drei primären Typen digitaler Zertifikate werden in der folgenden Tabelle beschrieben:

Typ BESCHREIBUNG Vorteile Benachteiligungen
Selbstsigniertes Zertifikat Das Zertifikat wird von der Anwendung signiert, die es erstellt hat oder mithilfe von New-SelfSignedCertificate erstellt wird. Kosten (kostenlos) – Das Zertifikat wird nicht automatisch von Clientcomputern und mobilen Geräten als vertrauenswürdig eingestuft. Das Zertifikat muss dem vertrauenswürdigen Stammzertifikatspeicher auf allen Clientcomputern und Geräten manuell hinzugefügt werden, aber nicht alle mobilen Geräte ermöglichen Änderungen am vertrauenswürdigen Stammzertifikatspeicher.

- Nicht alle Dienste funktionieren mit selbstsignierten Zertifikaten.

– Schwierig, eine Infrastruktur für die Zertifikatlebenszyklusverwaltung einzurichten. Selbstsignierte Zertifikate können z. B. nicht widerrufen werden.
Von einer internen Zertifizierungsstelle ausgestelltes Zertifikat Das Zertifikat wird von einer Public Key-Infrastruktur (PKI) in Ihrer Organisation ausgestellt. Ein Beispiel ist Active Directory-Zertifikatdienste (AD CS). Weitere Informationen finden Sie unter Active Directory-Zertifikatdienste (Übersicht). – Ermöglicht Organisationen, eigene Zertifikate auszustellen.

- Weniger teuer als Zertifikate von einer kommerziellen Zertifizierungsstelle.		 - Erhöhte Komplexität für die Bereitstellung und Wartung der PKI.

– Das Zertifikat wird nicht automatisch von Clientcomputern und mobilen Geräten als vertrauenswürdig eingestuft. Das Zertifikat muss dem vertrauenswürdigen Stammzertifikatspeicher auf allen Clientcomputern und Geräten manuell hinzugefügt werden, aber nicht alle mobilen Geräte ermöglichen Änderungen am vertrauenswürdigen Stammzertifikatspeicher.
Von einer kommerziellen Zertifizierungsstelle ausgestelltes Zertifikat Das Zertifikat wird von einer vertrauenswürdigen kommerziellen Zertifizierungsstelle erworben. Die Zertifikatbereitstellung ist vereinfacht, da alle Clients, Geräte und Server den Zertifikaten automatisch vertrauen. Kosten. Sie müssen vorausplanen, um die Anzahl der erforderlichen Zertifikate zu minimieren.

Um zu beweisen, dass ein Zertifikatinhaber die Person ist, die sie vorgeben zu sein, muss das Zertifikat den Zertifikatinhaber für andere Clients, Geräte oder Server genau identifizieren. Die drei grundlegenden Methoden hierfür werden in der folgenden Tabelle beschrieben:

Methode BESCHREIBUNG Vorteile Benachteiligungen
Zertifikatsantragstellerabgleich Das Feld " Betreff " des Zertifikats enthält den gemeinsamen Namen (CN) des Hosts. Beispielsweise kann das zertifikat, das ausgestellt www.contoso.com wird, für die Website https://www.contoso.comverwendet werden. - Kompatibel mit allen Clients, Geräten und Diensten.

- Aufteilung. Das Widerrufen des Zertifikats für einen Host wirkt sich nicht auf andere Hosts aus.		 - Anzahl der erforderlichen Zertifikate. Sie können das Zertifikat nur für den angegebenen Host verwenden. Beispielsweise können Sie das www.contoso.com Zertifikat ftp.contoso.comnicht verwenden, auch wenn die Dienste auf demselben Server installiert sind.

-Kompliziertheit. Auf einem Webserver erfordert jedes Zertifikat eine eigene IP-Adressbindung.
Abgleich mit alternativem Antragstellernamen (Subject Alternative Name, SAN) Zusätzlich zum Feld " Betreff " enthält das Feld " Alternativer Antragstellername " des Zertifikats eine Liste mit mehreren Hostnamen. Beispiel:
www.contoso.com
ftp.contoso.com
ftp.eu.fabrikam.net		 -Annehmlichkeit. Sie können dasselbe Zertifikat für mehrere Hosts in mehreren separaten Domänen verwenden.

– Die meisten Clients, Geräte und Dienste unterstützen SAN-Zertifikate.

- Überwachung und Sicherheit. Sie wissen genau, welche Hosts das SAN-Zertifikat verwenden können.		 - Mehr Planung erforderlich. Sie müssen die Liste der Hosts angeben, wenn Sie das Zertifikat erstellen.

- Mangel an Untergliederung. Sie können Zertifikate für einige der angegebenen Hosts nicht selektiv widerrufen, ohne dass sich dies auf alle Hosts im Zertifikat auswirkt.
Platzhalterzertifikatabgleich Das Feld " Betreff " des Zertifikats enthält den gemeinsamen Namen als Platzhalterzeichen (*) sowie eine einzelne Domäne oder Unterdomäne. Beispiel: *.contoso.com oder *.eu.contoso.com. Das *.contoso.com Wildcardzertifikat kann für Folgendes verwendet werden:
www.contoso.com
ftp.contoso.com
mail.contoso.com		 Flexibilität. Sie müssen keine Liste von Hosts angeben, wenn Sie das Zertifikat anfordern, und Sie können das Zertifikat für eine beliebige Anzahl von Hosts verwenden, die Sie in Zukunft benötigen. - Sie können keine Wildcardzertifikate mit anderen Domänen der obersten Ebene (TLDs) verwenden. Beispielsweise können Sie das *.contoso.com Wildcardzertifikat nicht für *.contoso.net Hosts verwenden.

- Sie können Platzhalterzertifikate nur für Hostnamen auf der Ebene des Platzhalters verwenden. Beispielsweise können Sie das *.contoso.com-Zertifikat nicht für www.eu.contoso.com verwenden. Entweder können Sie das *.eu.contoso.com Zertifikat nicht für www.uk.eu.contoso.com verwenden.

– Ältere Clients, Geräte, Anwendungen oder Dienste unterstützen möglicherweise keine Wildcardzertifikate.

– Wildcards sind nicht mit Zertifikaten für die erweiterte Gültigkeitsprüfung (Extended Validation, EV) verfügbar.

- Sorgfältige Überwachung und Kontrolle sind erforderlich. Wenn das Wildcardzertifikat kompromittiert ist, wirkt es sich auf jeden Host in der angegebenen Domäne aus.

Verwandte Inhalte