Digitale Zertifikate und Verschlüsselung in Exchange Server

Verschlüsselung und digitale Zertifikate sind wichtige Faktoren in jeder Organisation. Exchange Server ist standardmäßig 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.

Hinweis

Exchange Server 2019 enthält wichtige Änderungen, um die Sicherheit von Client- und Serververbindungen zu verbessern. Die Standardkonfiguration für die Verschlüsselung aktiviert nur TLS 1.2 und deaktiviert die Unterstützung älterer Algorithmen (d. h. DES, 3DES, RC2, RC4 und MD5). Außerdem werden Schlüsselaustauschalgorithmen mit elliptischen Kurven Algorithmen ohne elliptische Kurven vorgezogen. In Exchange Server 2016 und höher werden alle Kryptografieeinstellungen von der im Betriebssystem angegebenen Konfiguration geerbt. Weitere Informationen finden Sie unter Bewährte Methoden für die TLS-Konfiguration für Exchange Server.

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 Prozeduren, 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 tragen dazu bei, die ausgetauschten Daten vor Diebstahl oder Manipulation zu schützen.

• Authentifizierung: Sie überprüfen, ob ihre Besitzer (Personen, Websites und sogar Netzwerkgeräte wie Router) wirklich wer oder was sie zu sein behaupten. 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.

Typ	Beschreibung	Vorteile	Nachteile
Selbstsigniertes Zertifikat	Das Zertifikat wird von der Anwendung signiert, die es erstellt hat.	Kosten (kostenlos).	Dem Zertifikat wird nicht automatisch von Clientcomputern und mobilen Geräten vertraut. Das Zertifikat muss dem Speicher für vertrauenswürdige Stammzertifikate auf allen Clientcomputern und Geräten manuell hinzugefügt werden, aber nicht alle mobilen Geräte lassen Änderungen am Speicher für vertrauenswürdige Stammzertifikate zu. Nicht alle Dienste funktionieren mit selbstsignierten Zertifikaten. Es ist schwierig, eine Infrastruktur für die Zertifikatlebenszyklusverwaltung einzurichten. Selbstsignierte Zertifikaten können z. B. nicht gesperrt werden.
Von einer internen Zertifizierungsstelle ausgestelltes Zertifikat	Das Zertifikat wird von einer Public Key-Infrastruktur (PKI) in Ihrer Organisation ausgestellt. Beispiel: Active Directory-Zertifikatdienste (AD CS). Weitere Informationen finden Sie unter Active Directory-Zertifikatdienste: Übersicht.	Ermöglicht Organisationen, eigene Zertifikate auszustellen. Preisgünstiger als Zertifikate von einer kommerziellen Zertifizierungsstelle.	Höhere Komplexität beim Bereitstellen und Verwalten der PKI. Dem Zertifikat wird nicht automatisch von Clientcomputern und mobilen Geräten vertraut. Das Zertifikat muss dem Speicher für vertrauenswürdige Stammzertifikate auf allen Clientcomputern und Geräten manuell hinzugefügt werden, aber nicht alle mobilen Geräte lassen Änderungen am Speicher für vertrauenswürdige Stammzertifikate zu.
Von einer kommerziellen Zertifizierungsstelle ausgestelltes Zertifikat	Das Zertifikat wird von einer vertrauenswürdigen gewerblichen Zertifizierungsstelle erworben.	Vereinfachte Zertifikatbereitstellung, da alle Clients, Geräte und Server automatisch den Zertifikaten vertrauen.	Kosten Sie müssen vorausplanen, um die Anzahl der erforderlichen Zertifikate zu minimieren.

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.

Methode	Beschreibung	Vorteile	Nachteile
Abgleich mit dem Zertifikatantragsteller	Das Subject -Feld des Zertifikats enthält den allgemeinen Namen (Common Name, CN) des Hosts. Beispielsweise kann das Zertifikat, das für www.contoso.com ausgestellt wird, für die Website https://www.contoso.comverwendet werden.	Kompatibel mit allen Clients, Geräten und Diensten. Abschottung. Sperren des Zertifikats für einen Host wirkt sich nicht auf andere Hosts aus.	Anzahl erforderlicher Zertifikate. Sie können das Zertifikat nur für den angegebenen Host verwenden. Beispielsweise können Sie das www.contoso.com-Zertifikat nicht für ftp.contoso.com verwenden, auch wenn die Dienste auf demselben Server installiert sind. Komplexität. Auf einem Webserver ist für jedes Zertifikat eine eigene IP-Adressbindung erforderlich.
Abgleich mit dem alternativen Zertifikatantragstellernamen (Subject Alternative Name, SAN)	Zusätzlich zum Subject -Feld enthält das Subject Alternative Name -Feld des Zertifikats eine Liste mit mehreren Hostnamen. Beispiel: www.contoso.com ftp.contoso.com ftp.eu.fabirkam.net	Bequemlichkeit. Sie können das gleiche 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. Mangelnde Abschottung. Sie können Zertifikate nicht selektiv für einige der angegebenen Hosts widerrufen, ohne alle Hosts im Zertifikat zu beeinflussen.
Abgleich mit Platzhalterzertifikat	Das Subject-Feld des Zertifikats enthält den allgemeinen Namen als Platzhalterzeichen (*) plus eine einzelne Domäne oder Unterdomäne. Beispiel: *.contoso.com oder *.eu.contoso.com. Das Platzhalterzertifikat *.contoso.com kann verwendet werden für: www.contoso.com ftp.contoso.com mail.contoso.com	Flexibilität. Sie müssen keine Liste der Hosts angeben, wenn Sie das Zertifikat anfordern, und Sie können das Zertifikat auf einer beliebigen Anzahl von Hosts verwenden, die Sie in Zukunft möglicherweise benötigen.	Sie können Platzhalterzertifikate nicht mit anderen Domänen der obersten Ebene (Top-Level-Domains, TLDs) verwenden. Beispielsweise können Sie das Platzhalterzertifikat *.contoso.com nicht für Hosts auf *.contoso.net verwenden. Sie können Platzhalterzertifikate nur für Hostnamen auf der Ebene des Platzhalters verwenden. Beispielsweise können Sie das Zertifikat *.contoso.com nicht für www.eu.contoso.com verwenden. Oder Sie können 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 Platzhalterzertifikate. Bei Zertifikaten für die erweiterte Überprüfung (Extended Validation, EV) können Platzhalter nicht verwendet werden. Sorgfältige Überwachung und Kontrolle erforderlich. Wenn das Platzhalterzertifikat beschädigt wird, wirkt sich dies auf jeden Host in der angegebenen Domäne aus.

Zertifikate in Exchange

Wenn Sie Exchange 2016 oder Exchange 2019 auf einem Server installieren, werden von Exchange zwei selbstsignierte Zertifikate erstellt und installiert. Ein drittes selbstsigniertes Zertifikat wird von 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:

Name	Kommentare
Microsoft Exchange	Dieses selbstsignierte Zertifikat von Exchange weist die folgenden Merkmale auf: Dem Zertifikat wird automatisch von allen anderen Exchange-Servern in der Organisation vertraut. Dies schließt alle Edge-Transport-Server ein, die die Exchange-Organisation abonniert haben. Das Zertifikat wird automatisch für alle Exchange-Dienste mit Ausnahme von Unified Messaging aktiviert und wird verwendet zur Verschlüsselung der internen Kommunikation zwischen Exchange-Servern, Exchange-Diensten auf demselben Computer und Clientverbindungen, die von den Clientzugriffsdiensten auf die Back-End-Dienste auf Postfachservern weitergeleitet werden. (Hinweis: UM ist in Exchange 2019 nicht verfügbar.) Das Zertifikat wird automatisch für eingehende Verbindungen von externen SMTP-Messagingservern und für ausgehende Verbindungen zu externen SMTP-Messagingservern aktiviert. Diese Standardkonfiguration ermöglicht Es Exchange, opportunistische TLS für alle ein- und ausgehenden SMTP-Verbindungen bereitzustellen. Exchange versucht, die SMTP-Sitzung mit einem externen Messagingserver zu verschlüsseln, aber wenn der externe Server die TLS-Verschlüsselung nicht unterstützt, bleibt die Sitzung unverschlüsselt. Das Zertifikat ermöglicht keine verschlüsselte Kommunikation mit internen oder externen Clients. Clients und Server vertrauen dem selbstsignierten Zertifikat von Exchange nicht, da es nicht in ihrem Zertifikatspeicher für vertrauenswürdige Stammzertifikate definiert ist.
Microsoft Exchange-Zertifikat für die Serverauthentifizierung	Dieses selbstsignierte Zertifikat von Exchange wird für die Server-zu-Server-Authentifizierung und Integration mithilfe von OAuth verwendet. Weitere Informationen finden Sie unter Planen der Exchange Server-Integration in SharePoint und Skype for Business.
WMSVC	Dieses selbstsignierte Windows-Zertifikat wird vom Webverwaltungsdienst in IIS zum Aktivieren der Remoteverwaltung des Webservers und der ihm zugeordneten Websites und Anwendungen verwendet. Wenn Sie dieses Zertifikat entfernen, kann der Webverwaltungsdienst nicht gestartet werden, falls kein gültiges Zertifikat ausgewählt ist. Wenn sich der Dienst in diesem Zustand befindet, können Sie möglicherweise keine Updates für Exchange installieren oder Exchange nicht vom Server deinstallieren. Anweisungen zum Beheben dieses Problems finden Sie unter Ereignis-ID 1007 – Authentifizierung des IIS-Webverwaltungsdiensts.

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 auf dem Lastenausgleichs- oder Reverseproxyserver zu beenden, Lastenausgleichsmodule der Schicht 4 oder Schicht 7 zu verwenden und Sitzungsaffinität oder keine Sitzungsaffinität zu verwenden? Weitere Informationen finden Sie unter Lastenausgleich in Exchange 2016.

• Namespace Planung: Welche Versionen von Exchange sind vorhanden, verwenden Sie das gebundene oder ungebundene Namespacemodell und verwenden Split-Brain-DNS (Konfigurieren verschiedener 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 verwenden Ihre Clients (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 für elliptische Kurve in Exchange Server

Ab dem Exchange Server-Hotfixupdate vom April 2024 (HU) unterstützen Exchange Server 2016 und Exchange Server 2019 die Verwendung von ECC-Zertifikaten (Elliptic Curve Cryptography) für einige Dienste.

ECC-Zertifikate oder Kryptografiezertifikate für elliptische Kurve sind eine Art von digitalem Zertifikat, das den Algorithmus für elliptische Kurven für die Verschlüsselung verwendet und im Vergleich zu herkömmlichen RSA-Zertifikaten eine höhere Sicherheit mit kürzeren Schlüssellängen bietet.

Warnung

In den folgenden Szenarien wird die Verwendung von ECC-Zertifikaten derzeit nicht unterstützt. Wir arbeiten an einem Update, um diese Szenarien in Zukunft zu unterstützen:

• Sie können keine ECC-Zertifikate auf der Edge-Transport-Serverrolle zuweisen.
• Sie können ECC-Zertifikate dem POP- und IMAP-Dienst zuweisen, aber sie werden nicht verwendet.
• Das Verbundvertrauenszertifikat muss ein RSA-Zertifikat sein.
• Das Exchange Server OAuth-Zertifikat muss ein RSA-Zertifikat sein.
• ECC-Zertifikate können nicht verwendet werden, wenn die anspruchsbasierte AD FS-Authentifizierung verwenden konfiguriert ist.

Überprüfen Sie die Tabelle im nächsten Abschnitt, um zu verstehen, welche Dienste mit einem ECC-Zertifikat verwendet werden können.

Die Unterstützung von ECC-Zertifikaten ist standardmäßig deaktiviert und kann durch Erstellen einer Außerkraftsetzung aktiviert werden. Öffnen Sie eine neue Exchange-Verwaltungsshell (EMS), nachdem der New-SettingOverride Befehl ausgeführt wurde:

New-SettingOverride -Name "ECC Support" -Parameters @("Enabled=true") -Component "Global" -Reason "Support ECC" -Section "ECCCertificateSupport"
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.

Dienst	Beschreibung	ECC-Zertifikat unterstützt
IIS (HTTP)	Standardmäßig werden die folgenden Dienste unter der Standardwebsite in den Clientzugriffs- (Front-End-)Diensten auf einem Postfachserver angeboten und von Clients zum Herstellen einer Verbindung mit Exchange verwendet: AutoErmittlung Exchange ActiveSync Exchange-Verwaltungskonsole Exchange-Webdienste Offlineadressbuch-Verteilung Outlook Anywhere (RPC über HTTP) Outlook MAPI über HTTP Outlook im Web Remote-PowerShell* Da Sie einer Website nur ein einzelnes Zertifikat zuordnen können, müssen alle DNS-Namen, mit denen Clients eine Verbindung zu diesen Diensten herstellen, in das Zertifikat aufgenommen werden. Sie erreichen dies mit einem SAN-Zertifikat oder einem Platzhalterzertifikat.	Ja
POP oder IMAP	Die für POP oder IMAP verwendeten Zertifikate können sich von dem Zertifikat unterscheiden, das für IIS verwendet wird. Um jedoch die Verwaltung zu vereinfachen, wird empfohlen, auch die für POP oder IMAP verwendeten Hostnamen in Ihr IIS-Zertifikat aufzunehmen und dasselbe Zertifikat für alle diese Dienste zu verwenden.	Nein
SMTP	SMTP-Verbindungen von Clients oder Messagingservern werden von einem oder mehreren Empfangsconnectors akzeptiert, die im Front-End-Transportdienst auf dem Exchange-Server konfiguriert sind. Weitere Informationen finden Sie unter Empfangsconnectors. Um TLS-Verschlüsselung für SMTP-Verbindungen festzulegen, können Sie ein separates Zertifikat für jeden Empfangsconnector verwenden. Das Zertifikat muss den DNS-Namen enthalten, der von den SMTP-Clients oder -Servern zum Herstellen der Verbindung mit dem Empfangsconnector verwendet wird. Zur einfacheren Zertifikatverwaltung können Sie alle DNS-Namen, für die TLS-Datenverkehr unterstützt werden muss, in einem einzelnen Zertifikat zusammenfassen. Informationen zur gegenseitigen TLS-Authentifizierung, bei der die SMTP-Verbindungen zwischen dem Quell- und dem Zielserver verschlüsselt und authentifiziert sind, finden Sie unter Domänensicherheit.	Ja
Unified Messaging (UM)	Weitere Informationen finden Sie unter Deploying Certificates for UM. Hinweis: UM ist in Exchange 2019 nicht verfügbar.	Ja
Hybridbereitstellung mit Microsoft 365 oder Office 365	Weitere Informationen finden Sie unter Certificate Requirements for Hybrid Deployments.	Ja
Secure/Multipurpose Internet Mail Extensions (S/MIME)	Weitere Informationen finden Sie unter S/MIME für die Nachrichtensignierung und -verschlüsselung.	Nein

^* 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). Wenn Sie remote PowerShell verwenden möchten, um von einem Computer, der kein Mitglied der Domäne ist, eine Verbindung mit einem Exchange-Server herzustellen, oder um eine Verbindung über das Internet herzustellen, 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.

• Verwenden Sie so wenige Zertifikate wie möglich: Sehr wahrscheinlich bedeutet dies die Verwendung von SAN-Zertifikaten oder Wildcard-Zertifikaten. 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 Gängigen Namen auf derselben Ebene contoso.com befinden, spielt es keine Rolle, ob Sie ein SAN-Zertifikat oder ein Wildcardzertifikat 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 von 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 von 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 -features 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 kann die Anzahl der allgemeinen Namen begrenzen, die Sie in einem SAN-Zertifikat verwenden können, oder die Zertifizierungsstelle kann zusätzliche Gebühren basierend auf der Anzahl gängiger Namen in einem SAN-Zertifikat berechnen.

  • 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 des Exchange-Zertifikat-Assistenten: Ein häufiger Fehler beim Erstellen von Zertifikaten besteht darin, einen oder mehrere allgemeine 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 allgemeiner Namen in die Zertifikatanforderung aufzunehmen. Mit dem Assistenten können Sie die Dienste angeben, die das Zertifikat verwenden, und die allgemeinen Namen enthalten, die Sie im Zertifikat für diese Dienste benötigen. Führen Sie den Zertifikat-Assistenten aus, wenn Sie Ihre anfängliche Gruppe von Exchange 2016- oder Exchange 2019-Servern bereitgestellt und ermittelt 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, die mit der Zertifikatverwaltung verbunden ist. 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 eine einfache Exchange Server-Organisation mit dem Namen Contoso ist dies ein hypothetisches Beispiel für die mindest 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 spezifische Hostname ist für Clients erforderlich, die die AutoErmittlung unterstützen, einschließlich Outlook-, Exchange ActiveSync- und Exchange-Webdienst-Clients. 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.

Eigenschaft	Microsoft Exchange	Microsoft Exchange-Zertifikat für die Serverauthentifizierung	WMSVC
Subject	CN=<ServerName> (Beispiel: CN=Mailbox01)	CN=Microsoft Exchange Server Auth Certificate	CN=WMSvc-<ServerName> (Beispiel: CN=WMSvc-Mailbox01)
Alternative Antragstellernamen (CertificateDomains)	<ServerName> (z. B. Mailbox01) <ServerFQDN> (z. B. Mailbox01.contoso.com)	keine	WMSvc-<ServerName> (Beispiel: WMSvc-Mailbox01)
Verfügt über einen privaten Schlüssel (HasPrivateKey)	Ja (True)	Ja (True)	Ja (True)
PrivateKeyExportable*	Falsch	Wahr	True
EnhancedKeyUsageList*	Serverauthentifizierung (1.3.6.1.5.5.7.3.1)	Serverauthentifizierung (1.3.6.1.5.5.7.3.1)	Serverauthentifizierung (1.3.6.1.5.5.7.3.1)
IISServices*	IIS://<ServerName>/W3SVC/1, IIS://<ServerName>/W3SVC/2 (Beispiel: IIS://Mailbox01/W3SVC/1, IIS://Mailbox01/W3SVC/2)	keine	Keine
IsSelfSigned	True	True	Wahr
Aussteller	CN=<ServerName> (Beispiel: CN=Mailbox01)	CN=Microsoft Exchange Server Auth Certificate	CN=WMSvc-<ServerName> (Beispiel: CN=WMSvc-Mailbox01)
NotBefore	Datum/Uhrzeit der Installation von Exchange.	Datum/Uhrzeit der Installation von Exchange.	Datum/Uhrzeit der Installation des IIS-Webverwaltungsdiensts.
Läuft ab (NotAfter)	5 Jahre nach NotBefore.	5 Jahre nach NotBefore.	10 Jahre nach NotBefore.
Größe des öffentlichen Schlüssels (PublicKeySize)	2048	2048	2048
RootCAType	Registrierung	Keine	Registrierung
Dienste	IMAP, POP, IIS, SMTP	SMTP	Keine

^* 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.

Eigenschaft	Microsoft Exchange	Microsoft Exchange-Zertifikat für die Serverauthentifizierung	WMSVC
Signaturalgorithmus	sha256RSA1	sha256RSA1	sha256RSA1
Signaturhashalgorithmus	sha2561	sha2561	sha2561
Schlüsselverwendung	Digitale Signatur, Schlüsselverschlüsselung (a0)	Digitale Signatur, Schlüsselverschlüsselung (a0)	Digitale Signatur, Schlüsselverschlüsselung (a0), Datenverschlüsselung (b0 00 00 00)
Basiseinschränkungen	Subject Type=End Entity Path Length Constraint=None	Subject Type=End Entity Path Length Constraint=None	n/v
Fingerabdruckalgorithmus	sha2561	sha2561	sha2561

¹ Gilt für Neuinstallationen von Exchange 2016 Cumulative Update 22 oder höher und Exchange 2019 Cumulative 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.