Digitale Zertifikate und Verschlüsselung in Exchange Server

GILT FÜR:2016 2019 Subscription Edition

Verschlüsselung und digitale Zertifikate sind wichtige Faktoren in jeder Organisation. Standardmäßig ist Exchange Server für die Verwendung von Transport Layer Security (TLS) konfiguriert, um die Kommunikation zwischen internen Exchange-Servern und zwischen Exchange-Diensten auf dem lokalen Server zu verschlüsseln. Exchange-Administratoren müssen jedoch ihre Verschlüsselungsanforderungen für die Kommunikation mit internen und externen Clients (Computern und mobilen Geräten) sowie mit externen Messagingservern berücksichtigen.

In diesem Thema werden die verfügbaren Arten von Zertifikaten und die Standardkonfiguration für Zertifikate in Exchange beschrieben. Außerdem enthält es Vorschläge für zusätzliche Zertifikate, die Sie mit Exchange verwenden müssen.

Informationen zu den Verfahren, die für Zertifikate in Exchange Server erforderlich sind, finden Sie unter Zertifikatprozeduren in Exchange Server.

Übersicht über digitale Zertifikate

Digitale Zertifikate sind elektronische Dateien, die wie Onlinekennwörter 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 Bescheinigung von einer Zertifizierungsstelle (Certification Authority, CA), die die Identität des Zertifikatinhabers bestätigt und den Parteien eine sichere Kommunikation durch die Verschlüsselung von Daten ermöglicht.

Digitale Zertifikate bieten die folgenden Dienste:

• Verschlüsselung: Sie helfen, die ausgetauschten Daten vor Diebstahl oder Manipulation zu schützen.

• Authentifizierung: Sie überprüfen, ob ihre Inhaber (Personen, Websites und sogar Netzwerkgeräte wie Router) wirklich die sind, für die sie sich ausgeben. In der Regel ist die Authentifizierung unidirektional, wobei die Quelle die Identität des Ziels bestätigt, aber gegenseitige TLS-Authentifizierung ist ebenfalls möglich.

Zertifikate können für verschiedene Zwecke ausgestellt werden. Beispiel: zur Webbenutzerauthentifizierung, zur Webserverauthentifizierung, für S/MIME (Secure/Multipurpose Internet Mail Extensions), IPsec (Internet Protocol Security) und zur Codesignierung.

Ein Zertifikat enthält einen öffentlichen Schlüssel und bindet diesen an die Identität einer Person, eines Computers oder eines Diensts mit dem entsprechenden privaten Schlüssel. Öffentliche und private Schlüssel werden vom Client und vom Server zum Verschlüsseln von Daten vor deren Übertragung verwendet. Für Windows-Benutzer, -Computer und -Dienste wird eine Vertrauensstellung mit der Zertifizierungsstelle eingerichtet, wenn das Stammzertifikat im Speicher für vertrauenswürdige Stammzertifikate definiert ist und das Zertifikat einen gültigen Zertifizierungspfad enthält. Ein Zertifikat gilt als gültig, wenn es nicht gesperrt wurde (es ist nicht in der Zertifikatsperrliste (Certificate Revocation List, CRL) der Zertifizierungsstelle aufgeführt) und der Gültigkeitszeitraum nicht abgelaufen ist.

Die drei Haupttypen von digitalen Zertifikaten werden in der folgenden Tabelle beschrieben.

Um nachzuweisen, dass ein Zertifikatinhaber ist, wer er vorgibt zu sein, muss das Zertifikat den Zertifikatinhaber anderen Clients, Geräten oder Servern gegenüber genau identifizieren. Die drei grundlegenden Methoden dazu sind in der folgenden Tabelle beschrieben.

Zertifikate in Exchange

Wenn Sie Exchange 2016 oder Exchange 2019 auf einem Server installieren, werden zwei selbstsignierte Zertifikate erstellt und von Exchange installiert. Ein drittes selbstsigniertes Zertifikat wird vom Microsoft Windows für den Webverwaltungsdienst in Internetinformationsdienste (IIS) erstellt und installiert. Diese drei Zertifikate werden im Exchange-Verwaltungskonsole (EAC) und der Exchange-Verwaltungsshell angezeigt und werden in der folgenden Tabelle beschrieben:

Die Eigenschaften dieser selbstsignierten Zertifikate sind im Abschnitt Eigenschaften der standardmäßigen selbstsignierten Zertifikate beschrieben.

Dies sind die wichtigsten Probleme, die Sie bei Zertifikaten in Exchange berücksichtigen müssen:

• Sie müssen das selbstsignierte Microsoft Exchange-Zertifikat nicht ersetzen, um den Netzwerkdatenverkehr zwischen Exchange-Servern und -Diensten in Ihrer Organisation zu verschlüsseln.

• Sie benötigen zusätzliche Zertifikate zum Verschlüsseln von Verbindungen mit Exchange-Servern von internen und externen Clients.

• Sie benötigen zusätzliche Zertifikate, um die Verschlüsselung von SMTP-Verbindungen zwischen Exchange-Servern und externen Messagingservern zu erzwingen.

Die folgenden Elemente der Planung und Bereitstellung für Exchange Server sind wichtige Treiber für Ihre Zertifikatanforderungen:

• Lastenausgleich: Planen Sie, den verschlüsselten Kanal am Load Balancer oder Reverseproxyserver zu beenden, Layer 4- oder Layer 7-Load Balancer zu verwenden und Sitzungsaffinität oder keine Sitzungsaffinität zu verwenden? Weitere Informationen finden Sie unter Lastenausgleich in Exchange 2016.

• Namespaceplanung: Welche Versionen von Exchange sind vorhanden, verwenden Sie das gebundene oder ungebundene Namespacemodell und verwenden Sie Split-Brain-DNS (Konfigurieren unterschiedlicher IP-Adressen für denselben Host basierend auf internem und externem Zugriff)? Weitere Informationen finden Sie unter Namespaceplanung in Exchange 2016.

• Clientkonnektivität: Welche Dienste werden Ihre Clients verwenden (webbasierte Dienste, POP, IMAP usw.) und welche Versionen von Exchange sind beteiligt? Weitere Informationen finden Sie in den folgenden Themen:

  • Clientkonnektivität in einer Exchange 2016-Koexistenzumgebung mit Exchange 2013

  • Clientkonnektivität in einer Exchange 2016-Koexistenzumgebung mit Exchange 2010

  • Clientkonnektivität in einer Exchange 2016-Koexistenzumgebung mit verschiedenen Exchange-Versionen

Unterstützung von Kryptografiezertifikaten mit elliptischen Kurven in Exchange Server

ECC-Zertifikate oder Elliptic Curve Cryptography-Zertifikate sind eine Art digitaler Zertifikate, die einen Ellipsenkurvenalgorithmus für die Verschlüsselung verwenden, der im Vergleich zu herkömmlichen RSA-Zertifikaten eine höhere Sicherheit mit kürzeren Schlüssellängen bietet.

Beginnend mit dem Exchange Server April 2024 Hotfix Update (HU) unterstützen Exchange Server 2016 und Exchange Server 2019 die Verwendung von ECC-Zertifikaten (Elliptic Curve Cryptography) für einige Dienste. Wir haben einige wichtige Anpassungen mit dem Exchange Server Sicherheitsupdate (SU) vom November 2024 vorgenommen, um bekannte Probleme zu beheben und die ECC-Zertifikatunterstützung für zusätzliche Szenarien (z. B. POP3 und IMAP) zu aktivieren. Stellen Sie sicher, dass Sie das neueste Exchange Server Update installieren, bevor Sie die ECC-Zertifikatunterstützung aktivieren.

Sehen Sie in der Tabelle im nächsten Abschnitt nach, welche Dienste mit einem ECC-Zertifikat verwendet werden können.

Die Unterstützung von ECC-Zertifikaten ist standardmäßig deaktiviert und kann durch Erstellen eines Registrierungswerts aktiviert werden. Der Befehl muss auf jedem Exchange Server in Ihrer organization ausgeführt werden. Es kann bis zu 15 Minuten dauern, bis die Änderung aktiv wird.

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics" -Name "EnableEccCertificateSupport" -Value 1 -Type String

Die Außerkraftsetzung, die mit dem Exchange Server April 2024 Hotfix Update (HU) eingeführt wurde, sollte nicht mehr verwendet werden, da sie die Unterstützung von ECC-Zertifikaten nicht vollständig aktiviert. Es wird empfohlen, die Außerkraftsetzung zu entfernen. Öffnen Sie nach Ausführung des New-SettingOverride Befehls eine neue Exchange-Verwaltungsshell (EMS):

Get-SettingOverride | Where-Object {($_.SectionName -eq "ECCCertificateSupport") -and ($_.Parameters -eq "Enabled=true")} | Remove-SettingOverride
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force

Zertifikatanforderungen für Exchange-Dienste

Die Exchange-Dienste, denen Zertifikate zugewiesen werden können, werden in der folgenden Tabelle beschrieben.

^* Kerberos-Authentifizierung und Kerberos-Verschlüsselung werden für den Zugriff auf Remote-PowerShell verwendet, sowohl von der Exchange-Verwaltungskonsole als auch von der Exchange-Verwaltungsshell. Daher müssen Sie die Zertifikate nicht für die Verwendung mit der Remote-PowerShell konfigurieren, solange Sie direkt eine Verbindung mit einem Exchange-Server herstellen (und nicht mit einem Lastenausgleich-Namespace). Um Remote-PowerShell zum Herstellen einer Verbindung mit einem Exchange-Server von einem Computer, der kein Mitglied der Domäne ist, oder zum Herstellen einer Verbindung über das Internet zu verwenden, müssen Sie Ihre Zertifikate für die Verwendung mit Remote-PowerShell konfigurieren.

Bewährte Methoden für Exchange-Zertifikate

Wenngleich die Konfiguration der digitalen Zertifikate Ihrer Organisation basierend auf Ihren spezifischen Anforderungen variiert, sollen die nachfolgend aufgeführten bewährten Methoden Sie bei der Auswahl der richtigen Konfiguration für Ihre digitalen Zertifikate unterstützen.

• So wenige Zertifikate wie möglich verwenden: Sehr wahrscheinlich bedeutet dies, dass SAN-Zertifikate oder Wildcard-Zertifikate verwendet werden. Im Hinblick auf Interoperabilität mit Exchange sind beide von der Funktion her gleichwertig. Die Entscheidung zwischen einem SAN-Zertifikat und einem Platzhalterzertifikat wird mehr durch die wichtigsten (realen oder wahrgenommenen) Funktionen und Einschränkungen der einzelnen Zertifikattypen bestimmt, die unter Übersicht über digitale Zertifikate beschrieben sind.

  Wenn sich beispielsweise alle Ihre allgemeinen Namen in derselben Ebene von contoso.com befinden, spielt es keine Rolle, ob Sie ein SAN-Zertifikat oder ein Platzhalterzertifikat verwenden. Muss das Zertifikat jedoch für autodiscover.contoso.com, autodiscover.fabrikam.com und autodiscover.northamerica.contoso.com verwendet werden, müssen Sie ein SAN-Zertifikat verwenden.

• Verwenden von Zertifikaten einer kommerziellen Zertifizierungsstelle für Client- und externe Serververbindungen: Obwohl Sie die meisten Clients so konfigurieren können, dass sie jedem Zertifikat oder Zertifikataussteller vertrauen, ist es viel einfacher, ein Zertifikat einer kommerziellen Zertifizierungsstelle für Clientverbindungen mit Ihren Exchange-Servern zu verwenden. Auf dem Client ist keine Konfiguration erforderlich, um einem Zertifikat zu vertrauen, das von einer kommerziellen Zertifizierungsstelle ausgestellt ist. Viele kommerzielle Zertifizierungsstellen bieten Zertifikate, die speziell für Exchange konfiguriert sind. Sie können das EAC oder die Exchange-Verwaltungsshell zum Generieren von Zertifikatanforderungen verwenden, die bei den meisten kommerziellen Zertifizierungsstellen funktionieren.

• Wählen Sie die richtige kommerzielle Zertifizierungsstelle aus: Vergleichen Sie Zertifikatpreise und Funktionen zwischen Zertifizierungsstellen. Zum Beispiel:

  • Überprüfen Sie, ob die Clients (Betriebssysteme, Browser und mobile Geräte), die eine Verbindung mit Ihren Exchange-Servern herstellen, die Zertifizierungsstelle als vertrauenswürdig einstufen.

  • Überprüfen Sie, ob die Zertifizierungsstelle die Art von Zertifikat unterstützt, die Sie benötigen. Beispielsweise unterstützen nicht alle Zertifizierungsstellen SAN-Zertifikate, die Zertifizierungsstelle begrenzt möglicherweise die Anzahl der gebräuchlichen Namen, die Sie in einem SAN-Zertifikat verwenden können, oder die Zertifizierungsstelle berechnet möglicherweise zusätzliche Gebühren basierend auf der Anzahl der allgemeinen Namen in einem SAN-Zertifikat.

  • Erkundigen Sie sich, ob die Zertifizierungsstelle eine Karenzzeit bietet, in der Sie zusätzliche allgemeine Namen zu SAN-Zertifikaten hinzufügen können, nachdem sie kostenlos ausgestellt wurden.

  • Überprüfen Sie, ob die Lizenz des Zertifikats die Verwendung des Zertifikats auf der erforderlichen Anzahl von Servern zulässt. Bei einigen Zertifizierungsstellen darf ein Zertifikat nur auf einem Server verwendet werden.

• Verwenden Sie den Exchange-Zertifikat-Assistenten: Ein häufiger Fehler beim Erstellen von Zertifikaten besteht darin, einen oder mehrere gängige Namen zu vergessen, die für die Dienste erforderlich sind, die Sie verwenden möchten. Der Zertifikat-Assistent im Exchange Admin Center hilft Ihnen, die richtige Liste gebräuchlicher Namen in die Zertifikatanforderung einzuschließen. Der Assistent ermöglicht es Ihnen, die Dienste anzugeben, die das Zertifikat verwenden. Er schließt die allgemeinen Namen ein, die Sie im Zertifikat für diese Dienste haben müssen. Führen Sie den Zertifikat-Assistenten aus, wenn Sie Ihren ersten Satz von Exchange 2016- oder Exchange 2019-Servern bereitgestellt und bestimmt haben, welche Hostnamen für die verschiedenen Dienste für Ihre Bereitstellung verwendet werden sollen.

• Verwenden Sie so wenige Hostnamen wie möglich: Die Minimierung der Anzahl von Hostnamen in SAN-Zertifikaten reduziert die Komplexität der Zertifikatverwaltung. Fühlen Sie sich nicht verpflichtet, die Hostnamen einzelner Exchange-Server in SAN-Zertifikaten aufzunehmen, wenn die beabsichtigte Verwendung des Zertifikats dies nicht erfordert. In der Regel müssen Sie nur die DNS-Namen aufnehmen, die internen Clients, externen Clients oder externen Servern angezeigt werden, die das Zertifikat zum Herstellen einer Verbindung mit Exchange verwenden.

  Für einen einfachen Exchange Server organization mit dem Namen Contoso ist dies ein hypothetisches Beispiel für die mindestens erforderlichen Hostnamen:

  • mail.contoso.com: Dieser Hostname deckt die meisten Verbindungen mit Exchange ab, einschließlich Outlook, Outlook im Web, OAB-Verteilung, Exchange-Webdienste, Exchange Admin Center und Exchange ActiveSync.

  • autodiscover.contoso.com: Dieser spezielle Hostname wird von Clients benötigt, die die AutoErmittlung unterstützen, einschließlich Outlook-, Exchange ActiveSync- und Exchange-Webdienstclients. Weitere Informationen finden Sie unter AutoErmittlungsdienst.

Eigenschaften der standardmäßigen selbstsignierten Zertifikate

Einige interessante Eigenschaften der standardmäßigen selbstsignierten Zertifikate, die in der Exchange-Verwaltungskonsole und/oder der Exchange-Verwaltungsshell auf einem Exchange-Server angezeigt werden, werden in der folgenden Tabelle beschrieben.

^* Diese Eigenschaften sind in der Standardansicht der Exchange-Verwaltungsshell nicht sichtbar. Um sie anzuzeigen, müssen Sie mit den Cmdlets Format-Table oder Format-List den Eigenschaftennamen (genauen Namen oder Platzhalterübereinstimmung) angeben. Zum Beispiel:

• Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-List *

• Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-Table -Auto FriendlyName,*PrivateKey*

Weitere Informationen finden Sie unter Get-ExchangeCertificate.

Weitere Informationen zu den standardmäßigen selbstsignierten Zertifikaten, die im Windows Zertifikat-Manager sichtbar sind, werden in der folgenden Tabelle beschrieben.

¹ Gilt für Neuinstallationen von Exchange 2016, kumulatives Update 22 oder höher, und Exchange 2019, kumulatives Update 11 oder höher. Weitere Informationen finden Sie unter Exchange Server 2019- und 2016-Zertifikate, die während des Setups erstellt wurden, verwenden SHA-1-Hash.

Normalerweise verwenden Sie nicht den Windows Zertifikat-Manager zum Verwalten von Exchange-Zertifikaten (verwenden Sie die Exchange-Verwaltungskonsole oder die Exchange-Verwaltungsshell). Beachten Sie, dass das WMSVC-Zertifikat kein Exchange-Zertifikat ist.