Digitale Zertifikate und Verschlüsselung in Exchange Server

Verschlüsselung und digitale Zertifikate sind wichtige Faktoren in jeder Organisation. Standardmäßig ist Exchange Server für die Verwendung von Tls (Transport Layer Security) 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 zur Verbesserung der Sicherheit von Client- und Serververbindungen. 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 TLS-Leitfaden 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.

Die 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 tragen zum Schutz der Daten bei, die vor Diebstahl oder Manipulation ausgetauscht werden.

  • Authentifizierung: Sie überprüfen, ob ihre Besitzer (Personen, Websites und sogar Netzwerkgeräte wie Router) tatsächlich die Person oder das sind, was sie sind. 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.

Das Herstellen einer Infrastruktur für die Lebenszyklusverwaltung von Zertifikaten ist schwierig. 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 im Voraus planen, 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 wurde, für die Website https://www.contoso.com verwendet 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 Zertifikat www.contoso.com nicht für ftp.contoso.com verwenden, selbst 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 bereitstellen, wenn Sie das Zertifikat anfordern, und Sie können das Zertifikat auf einer beliebigen Anzahl von Hosts verwenden, die Sie möglicherweise in der Zukunft 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. Ebenso können Sie das Zertifikat *.eu.contoso.com 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 zwei selbstsignierte Zertifikate von Exchange 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. Dazu gehören alle Edge-Transport-Server, 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 Exchange die Bereitstellung von opportunistischem TLS für alle eingehenden und ausgehenden SMTP-Verbindungen. 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 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 – IIS Web Management Service Authentication

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:

Zertifikatanforderungen für Exchange-Dienste

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

Dienst Beschreibung
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.

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.
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 zielserver verschlüsselt und authentifiziert sind, finden Sie unter "Domänensicherheit".

Unified Messaging (UM) Weitere Informationen finden Sie unter Deploying Certificates for UM.

Hinweis: UM ist in Exchange 2019 nicht verfügbar.

Hybridbereitstellung mit Microsoft 365 oder Office 365 Weitere Informationen finden Sie unter Certificate Requirements for Hybrid Deployments.
Secure/Multipurpose Internet Mail Extensions (S/MIME) Weitere Informationen finden Sie unter S/MIME für die Nachrichtensignierung und -verschlüsselung.

*Die Kerberos-Authentifizierung und die Kerberos-Verschlüsselung werden für den Remote-PowerShell-Zugriff sowohl vom Exchange Admin Center als auch von der Exchange-Verwaltungsshell verwendet. 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 eine Verbindung mit einem Exchange-Server von einem Computer herzustellen, der kein Mitglied der Domäne ist, 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 Platzhalterzertifikaten. 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.

    Befinden sich z. B. alle Ihre allgemeinen Namen auf derselben Ebene von contoso.com, 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 Sie Zertifikate 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 zu 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. 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. Nicht alle Zertifizierungsstellen unterstützen z B. SAN-Zertifikate, möglicherweise beschränkt die Zertifizierungsstelle die Anzahl von allgemeinen Namen in einem SAN-Zertifikat, oder sie berechnet zusätzliche Kosten 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 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 einzuschließen. Mit dem Assistenten können Sie die Dienste angeben, die das Zertifikat verwenden sollen, und enthält die allgemeinen Namen, 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 haben, und bestimmen Sie, welche Hostnamen für die verschiedenen Dienste für Ihre Bereitstellung verwendet werden sollen.

  • Verwenden Sie möglichst wenige Hostnamen: Durch die Minimierung der Anzahl von Hostnamen in SAN-Zertifikaten wird die Komplexität der Zertifikatverwaltung reduziert. 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 namens 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 spezifische 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.

Eigenschaft Microsoft Exchange Microsoft Exchange-Zertifikat für die Serverauthentifizierung WMSVC
Betreff CN=<ServerName> (z. B. CN=Mailbox01) CN=Microsoft Exchange Server Auth Certificate CN=WMSvc-<ServerName> (z. B. CN=WMSvc-Mailbox01)
Alternative Antragstellernamen (CertificateDomains) <ServerName> (z. B. Mailbox01)

<ServerFQDN> (z. B. Mailbox01.contoso.com)

keine WMSvc-<ServerName> (z. B. WMSvc-Mailbox01)
Besitzt privaten Schlüssel (HasPrivateKey) Ja (True) Ja (True) Ja (True)
PrivateKeyExportable* False True 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 (z. B. IIS://Mailbox01/W3SVC/1, IIS://Mailbox01/W3SVC/2) keine Keine
IsSelfSigned True True True
Aussteller CN=<ServerName> (z. B. CN=Mailbox01) CN=Microsoft Exchange Server Auth Certificate CN=WMSvc-<ServerName> (z. B. 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 in 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. 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

1 Gilt für Neuinstallationen des kumulativen Updates 22 oder höher Exchange 2016 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 mit sha-1-Hash erstellt wurden.

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.