Freigeben über

Verwendung von Zertifikaten in Exchange 2007 Server

  • Artikel

 

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Letztes Änderungsdatum des Themas: 2008-05-19

Microsoft Exchange Server 2007 setzt zum Sichern vieler Pfade der E-Mail-Kommunikation Zertifikate ein. Dieses Thema ist als End-to-End-Einführung in die Verwendung von Zertifikaten in Exchange 2007 vorgesehen. In diesem Thema werden die folgenden Punkte erläutert:

  • Verwendung von Zertifikaten in Exchange 2007.

  • Grundlagen zur Entscheidung, ob ein Zertifikat von einer öffentlichen Zertifizierungsstelle (Certification Authority, CA) als einem Drittanbieter erworben werden soll, oder ob das standardmäßige, selbstsignierte Zertifikat ausreichend ist.

  • Verwendung von Zertifikatattributen durch die Komponenten von Exchange 2007 und Beziehung der Zertifikateigenschaften zu den Erweiterungsfeldern des X.509-Zertifikats.

  • Vertrauensstellung und Gültigkeit von Zertifikaten.

  • Erstellen, Importieren und Aktivieren von Exchange 2007-Zertifikaten.

  • Auswahl von Zertifikaten aus dem persönlichen Informationsspeicher des Computers durch Exchange-Komponenten.

Jeder Abschnitt in diesem Thema enthält Verweise und Links zur Dokumentation zu Zertifikaten für Exchange 2007.

Bestätigung   Die meisten dieser Inhalte wurden aus Microsoft-internen Notizen und Dokumenten adaptiert, die von Support Engineer Stuart Presley zusammengestellt und bereitgestellt wurden.

Inhalt

  • Exchange 2007 Components That Use Certificates to Encrypt or Authenticate Sessions

  • How to Determine When to Use Certificates Issued by Public CAs and When to Use Self-Signed Certificates

  • Understanding Certificate Attributes and How Exchange 2007 Uses Them

  • Certificate Trust and Validation

  • Creating, Importing, and Enabling Certificates

  • Certificate Selection

  • For More Information

Exchange 2007-Komponenten, die Zertifikate zum Verschlüsseln oder Authentifizieren von Sitzungen verwenden

Exchange 2007 verwendet X.509-Zertifikate für die Aushandlung von TLS- (Transport Layer Security) und SSL-Kommunikationstransportkanälen (Secure Sockets Layer) für Protokolle, wie etwa HTTPS, SMTP und POP und IMAP.

TLS ist das IETF-Standardprotokoll (Internet Engineering Task Force) zur Unterstützung von Vertraulichkeit und Sicherheit in der Kommunikation zwischen zwei Anwendungen, die Daten in einem Netzwerk austauschen. Mit TLS wird die Kommunikation verschlüsselt. Darüber hinaus versetzt das Protokoll Clients in die Lage, Server zu authentifizieren und ermöglicht optional auch die Authentifizierung von Clients durch den Server. TLS ist eine sicherere Version des SSL-Protokolls, auf dem TLS aufbaut. SSL wurde zuvor von Netscape entwickelt. Beide Protokolle sind in der Funktion gleichwertig. Und die meisten Implementierungen unterstützen beide Protokolle, um Abwärtskompatibilität mit älteren, nur SSL-fähigen, Clients zu ermöglichen.

Mit TLS-gesicherte Kommunikation kann für Vertraulichkeit (Verschlüsselung) allein oder für Vertraulichkeit und Authentifizierung zugleich verwendet werden. X.509-Zertifikate können selbstsigniert – dies wird auch als selbst ausgestellt bezeichnet – oder von einer X.509-Zertifizierungsstelle ausgestellt sein. Eine X.509-Zertifizierungsstelle ist eine von einem Drittanbieter betriebene öffentliche Zertifizierungsstelle, die Zertifikate oder eine Public-Key-Infrastruktur (PKI) ausstellt, die innerhalb Ihrer Organisation bereitgestellt wird. Sofern nicht ausdrücklich anders angemerkt, bezieht sich dieses Thema auf beide Lösungen als Zertifizierungsstellen (CAs). Öffentliche Zertifizierungsstellen von Drittanbietern werden als öffentliche Zertifizierungsstellen bezeichnet.

Die folgenden Exchange 2007-Komponenten verwenden Zertifikate zum Verschlüsseln oder Authentifizieren von Sitzungen:

  • SMTP   Zertifikate werden für die Verschlüsselung und Authentifizierung zum Zweck der Domänensicherheit zwischen Partnerorganisationen verwendet. Zertifikate werden für Verbindungen mit direkten Vertrauensstellungen zwischen Hub-Transport-Servern und Edge-Transport-Servern verwendet. Zertifikate werden zwischen Hub-Transport-Servern für das Verschlüsseln der SMTP-Sitzung verwendet. In Exchange 2007 bezeichnet direkte Vertrauensstellung die Authentifizierungsfunktion, bei der das Vorhandensein des Zertifikats im Active Directory-Verzeichnisdienst oder im ADAM-Verzeichnisdienst (Active Directory Application Mode) als Gültigkeit des Zertifikats gewertet wird. Active Directory wird als ein vertrauenswürdiger Speichermechanismus betrachtet. Zertifikate werden außerdem für opportunistische TLS-Sitzungen zwischen Organisationen verwendet. Weitere Informationen finden Sie unter TLS-Funktionen und die zugehörige Terminologie in Exchange 2007.

  • EdgeSync-Synchronisation   Ein von Exchange 2007 erstelltes selbstsigniertes Zertifikat wird für das Verschlüsseln der LDAP-Kommunikationssitzung zwischen der ADAM-Instanz auf den Edge-Transport-Servern und den internen Active Directory-Servern verwendet, nachdem der Microsoft Exchange EdgeSync-Dienst Daten von Active Directory auf die ADAM-Instanz auf dem Edge-Transport-Server repliziert hat. Bei einem selbstsignierten Zertifikat handelt es sich um ein Zertifikat, das von seinem Ersteller signiert wurde. Der Microsoft Exchange EdgeSync-Dienst ist der Dienst zur Datensynchronisation, der in regelmäßigen Abständen Konfigurationsdaten von Active Directory auf einen abonnierten Edge-Transport-Server repliziert. Weitere Informationen finden Sie unter Grundlegendes zum EdgeSync-Synchronisationsprozess.

  • POP3 und IMAP4   Zertifikate werden verwendet, um die Sitzung zwischen POP3- (Post Office Protocol, Version 3) und IMAP4-Clients (Internet Message Access Protocol, Version 4, Rev. 1) und Exchange-Servern zu authentifizieren und verschlüsseln. Weitere Informationen finden Sie unter Verwalten von POP3- und IMAP4-Sicherheit.

  • Unified Messaging   Zertifikate werden verwendet, um die SMTP-Sitzung zu Hub-Transport-Servern und zum UM-IP-Gateway (Unified Messaging) sowie zu Microsoft Office Communications Server 2007 zu verschlüsseln. Weitere Informationen finden Sie unter Grundlegendes zu Unified Messaging VoIP-Sicherheit.

  • AutoErmittlung   Zertifikate werden verwendet, um den HTTP-Pfad zwischen dem Client und dem Clientzugriffsserver zu verschlüsseln. Weitere Informationen finden Sie im Whitepaper: Exchange 2007-AutoErmittlungsdienst (englischsprachig).

  • ClientAccess-Anwendungen   Zertifikate werden verwendet, um den Pfad zwischen dem ClientAccess-Server und verschiedenen HTTP-Clients, wie etwa Outlook Anywhere, Microsoft Outlook Web Access und Geräten, die Microsoft Exchange ActiveSync unterstützen, zu verschlüsseln. Weitere Informationen finden Sie unter Verwalten der Clientzugriffssicherheit.

Spezifischere Informationen über die Art und Weise, in der die einzelnen Datenpfade in Exchange 2007 verschlüsselt und authentifiziert werden, finden Sie in Datenpfad-Sicherheitsreferenz.

Return to top

Bestimmen des Einsatzes von durch öffentliche Zertifizierungsstellen ausgestellten Zertifikaten im Vergleich zu selbstsignierten Zertifikaten

Der Zweck dieses Abschnitts liegt in einer kurzen Erläuterung, wie Exchange 2007 Zertifikate verwendet. Nachdem Sie diesen Abschnitt gelesen haben, sollte Ihnen, basierend auf den aktivierten Exchange-Komponenten und den zu unterstützenden Clients, die Entscheidung möglich sein, welche Zertifikate von einer öffentlichen Zertifizierungsstelle erworben werden müssen. In diesem Abschnitt wird darüber hinaus der allgemeine Kontext für die folgenden eher technischen Inhalte dargelegt.

Sie sollten unbedingt verstehen, dass dieser Abschnitt notwendigerweise kurz ist, da er das Ziel verfolgt, Ihnen eine schnelle Bestimmung ihrer allgemeinen Zertifikatanforderungen zu ermöglichen. Zugunsten einer kurzen Darstellung werden viele Verallgemeinerungen über Zertifikate und verwandte Technologien angewendet, um die Verwendung von Zertifikaten in Exchange 2007 zu veranschaulichen. Wenn Ihnen in diesem Abschnitt Konzepte begegnen, die Sie nicht verstehen, lesen Sie unbedingt den Rest dieses Themas und die verweisende Dokumentation.

Im Allgemeinen können alle Exchange 2007-Komponenten, die Kerberos, direkte Vertrauensstellung oder NTLM-Authentifizierung verwenden, für die Verschlüsselung ein selbstsigniertes Zertifikat einsetzen. In diesem Thema werden derartige Komponenten als interne Exchange 2007-Komponenten bezeichnet. Intern bezieht sich auf die Tatsache, dass die Datenpfade zwischen Exchange 2007-Servern und innerhalb des Unternehmensnetzwerks verlaufen, das durch Active Directory definiert ist.

Es wird empfohlen, ein von einer öffentlichen Zertifizierungsstelle ausgestelltes Zertifikat immer dann bereitzustellen, wenn Benutzer von außerhalb der Firewall Ihres Unternehmens auf Exchange-Komponenten zugreifen, die Authentifizierung und Verschlüsselung erfordern. Zum Beispiel sollten alle verschiedenen Clients, die von der Serverfunktion ClientAccess unterstützt werden, wie etwa Exchange ActiveSync, POP3, IMAP4 und Outlook Anywhere, mithilfe eines Zertifikats gesichert werden, das von einer öffentlichen Zertifizierungsstelle ausgestellt wurde. In diesem Thema werden derartige Komponenten als externe Exchange 2007-Komponenten bezeichnet. Extern bezieht sich auf die Tatsache, dass die Datenpfade zwischen den Clients und den Exchange 2007-Servern die Unternehmensfirewall durchqueren und sich ins Internet erstrecken.

Interne Komponenten verwenden selbstsignierte Zertifikate

Wie bereits zuvor erwähnt, verwenden viele Komponenten in Exchange 2007 Zertifikate. Im Allgemeinen ist für alle internen Exchange-Datenpfade, die durch Zertifikate gesichert sind, kein von einer öffentlichen Zertifizierungsstelle ausgestelltes Zertifikat erforderlich.

Der gesamte interne SMTP- und UM-Datenverkehr ist durch selbstsignierte Zertifikate gesichert, die beim Ausführen des Exchange 2007-Server-Installationsprogramms installiert werden. Zwar sollten diese Zertifikate in jährlichem Abstand durch Ausführen des Cmdlets New-ExchangeCertificate erneuert werden, jedoch benötigen Sie für die Ausführung der standardmäßigen internen Messagingkomponenten von Exchange kein von einer öffentlichen Zertifizierungsstelle ausgestelltes Zertifikat.

Hinweis

Von Exchange erstellte selbstsignierte Zertifikate laufen innerhalb eines Jahres ab. Die internen Komponenten, die sich auf die standardmäßigen selbstsignierten Zertifikate stützen, funktionieren auch nach dem Ablauf des selbstsignierten Zertifikats. Wenn das selbstsignierte Zertifikat abgelaufen ist, werden jedoch Ereignisse in der Ereignisanzeige protokolliert. Als optimale Methode wird das Erneuern der selbstsignierten Zertifikate vor ihrem Ablauf empfohlen.

Exchange 2007 beinhaltet eine Gruppe von Cmdlets zum Erstellen, Anfordern und Verwalten von TLS-Zertifikaten. Weitere Informationen über diese Cmdlets finden Sie unter Certificate Cmdlets weiter unten in diesem Thema. Standardmäßig sind diese Zertifikate selbstsigniert. Wie bereits zuvor in diesem Thema erläutert, handelt es sich bei einem selbstsignierten Zertifikat um ein Zertifikat, das von seinem Ersteller signiert wurde. In Exchange 2007 werden die selbstsignierten Zertifikate von dem Computer mit Microsoft Exchange unter Verwendung der Windows Certificate API (CAPI) erstellt. Da die Zertifikate selbstsigniert sind, sind die resultierenden Zertifikate im Allgemeinen weniger vertrauenswürdig als Zertifikate, die von einer Zertifizierungsstelle ausgestellt wurden. Selbstsignierte Zertifikate sollten daher nur für die folgenden internen Szenarien verwendet werden:

  • SMTP-Sitzungen zwischen Hub-Transport-Servern: Ein Zertifikat wird nur für die Verschlüsselung der SMTP-Sitzung verwendet. Authentifizierung wird durch das Kerberos-Protokoll bereitgestellt.

  • SMTP-Sitzungen zwischen Hub-Transport-Servern und einem Edge-Transport-Server: Ein Zertifikat wird für die Verschlüsselung der SMTP-Sitzung und für die Authentifizierung der direkten Vertrauensstellung verwendet.

  • EdgeSync-Synchronisation zwischen Edge-Transport-Servern und Active Directory: Ein Zertifikat wird für das Verschlüsseln der LDAP-Kommunikationssitzung zwischen der ADAM-Instanz auf den Edge-Transport-Servern und den internen Active Directory-Servern verwendet, nachdem der Microsoft Exchange EdgeSync-Dienst Daten von Active Directory auf die ADAM-Instanz auf dem Edge-Transport-Server repliziert hat.

  • Unified Messaging-Kommunikation: Ein Zertifikat wird für das Verschlüsseln von SIP- (Session Initiation Protocol) und RTP-Verkehr (Realtime Transport Protocol) zwischen UM-Servern und UM-IP-Gateways, IP-Nebenstellenanlagen (PBXs) und Computern, die Office Communications Server 2007 ausführen, verwendet. Das Zertifikat wird außerdem für das Verschlüsseln von SMTP-Verkehr verwendet, wenn Voicemail- oder Faxnachrichten von UM-Servern an Hub-Transport-Server übermittelt werden.

  • Ein ClientAccess-Server, auf den ausschließlich interne Clients zugreifen.

Für den externen Clientzugriff auf Exchange sind von einer öffentlichen Zertifizierungsstelle ausgestellte Zertifikate erforderlich

Interne Exchange-Komponente können sich auf selbstsignierte Zertifikate verlassen, da die Zertifikate nicht zur Authentifizierung verwendet werden. Die Authentifizierung für die meisten Exchange-Komponenten wird durch Kerberos oder NTLM bereitgestellt. Für die Kommunikation zwischen einem Edge-Transport-Server und einem Hub-Transport-Server wird Authentifizierung mithilfe von direkter Vertrauensstellung verwendet. Diese wird durch ein Zertifikat und die Tatsache bereitgestellt, dass der öffentliche Schlüssel des Edge-Transport-Servers in Active Directory gespeichert ist, das als vertrauenswürdiger Informationsspeicher angesehen wird. Andernfalls werden selbsignierte Zertifikate verwendet, um einen kurzlebigen Schlüssel zum Verschlüsseln von Datenpfaden zwischen Exchange-Komponenten bereitzustellen.

Für den externen Clientzugriff aus dem Internet in das Netzwerk, in dem Exchange ausgeführt wird, ist jedoch die traditionelle Gültigkeitsprüfung mit auf Zertifikaten beruhender Vertrauensstellung erforderlich. Für die Überprüfung von Vertrauensstellungen besteht die optimale Methode in der Verwendung eines von einer öffentlichen Zertifizierungsstelle ausgestellten Zertifikats. Wenn die Zertifikatauthentifizierung erforderlich ist, stellt die Verwendung eines selbstsignierten Zertifikats kein empfohlenes Verfahren dar, von dem daher dringend abgeraten wird. Es wird empfohlen, ein Zertifikat von einer öffentlichen Zertifizierungsstelle für folgende Szenarien zu verwenden:

  • POP3- und IMAP4-Clientzugriff auf Exchange

  • Outlook Web Access

  • Outlook Anywhere

  • Exchange ActiveSync

  • AutoErmittlung

  • Domänensicherheit

Die optimale Methode für alle diese Szenarien besteht in der Verwendung einer öffentlichen Zertifizierungsstelle, der standardmäßig alle Clients vertrauen.

Verwenden Sie das Cmdlet New-ExchangeCertificate, um eine neue Zertifikatanforderung entsprechend den Angaben der öffentlichen Drittanbieter-Zertifizierungsstelle, die das Zertifikat ausstellen soll, zu erstellen.

Weitere Informationen hierzu finden Sie unter den folgenden Themen:

Der Rest dieses Abschnitts enthält Informationen über das Bestimmen des Typs von öffentlichem Zertifikat, das Sie erwerben müssen, und ob Sie mehrere Zertifikate erwerben müssen, um das Sichern der von Ihrer Organisation für den Zugriff auf Exchange 2007 verwendeten Clients zu unterstützen.

Bestimmen von Typ und Anzahl der von einer öffentlichen Zertifizierungsstelle ausgestellten Zertifikate für Ihre Implementierung

Die Auswahl des geeigneten von einer öffentlichen Zertifizierungsstelle ausgestellten Zertifikats für Ihre Organisation hängt von den folgenden Faktoren ab:

  • Clientunterstützung für Platzhalternamen in Zertifikaten   Stellen Sie sich diese Fragen: Welche Clients sollen unterstützt werden? Wie bereits zuvor erwähnt, bezeichnet "Clients" in diesem Zusammenhang Clients, die aus dem Internet auf Exchange zugreifen.

  • Der Namespace Ihrer Organisation   Wie ist der dem Internet zugewandte IIS-Namespace (Internet Information Services, Internetinformationsdienste) konfiguriert?

  • Quelle des Zertifikats   Wo soll das Zertifikat erworben werden? Unterstützt die gewählte öffentliche Zertifizierungsstelle die Verwendung von Platzhalterzeichen in den Feldern für den Antragstellernamen oder den alternativen Antragstellernamen (Subject Alternative Name, SAN)? Falls nicht, wird die Verwendung von SANs unterstützt?

In den folgenden Abschnitten werden diese Faktoren genauer untersucht.

Clientunterstützung von Platzhalternamen in Zertifikaten

Platzhalternamen können in den Antragsteller- oder SAN-Erweiterungen von X.509-Zertifikaten verwendet werden. Weitere Informationen zu Platzhalternamen finden Sie in "CertificateDomains" in Understanding Certificate Attributes and How Exchange 2007 Uses Them weiter unten in diesem Thema.

Nachdem Sie bestimmt haben, welche Clients von Ihrer Organisation unterstützt werden sollen, sollten Sie feststellen, ob die Clients Zertifikate mit Platzhalternamen im Serverzertifikat unterstützen, mit dem der Client eine Verbindung herstellt.

Wenn der Client die Verwendung von Platzhalternamen im Zertifikat unterstützt, wird die gesamte Zertifikatplanung für Ihre Organisation stark vereinfacht. Wenn alle verwendeten Clients Platzhalternamen in Zertifikaten unterstützen und Ihre Organisation einen einzelnen Domänennamen verwendet, brauchen Sie sich keine Gedanken über die Namespaceplanung für Ihre Strategie zur Zertifikatbereitstellung zu machen. Stattdessen können Sie ein einzelnes Zertifikat erstellen, das Ihren Namespace mit einem Platzhalterzeichen unterstützt. Wenn beispielsweise Clients mit Outlook Web Access mail.contoso.com/owa für den Zugriff auf ihre E-Mail und POP3-Clients pop.contoso.com für den E-Mail-Zugriff verwenden, werden beide Clients von einem einzelnen Zertifikat mit einem Platzhalter-Antragstellernamen von *.contoso.com unterstützt.

Die folgenden Microsoft-Clients unterstützen Platzhalternamen in Zertifikaten:

  • Outlook

    Hinweis

    Wenn Platzhalterzertifikate auf Servercomputern mit Exchange bereitgestellt werden, auf denen die Serverfunktion ClientAccess ausgeführt wird, müssen die AutoErmittlungseinstellungen konfiguriert werden, damit Outlook 2007-Clients erfolgreich eine Verbindung herstellen können. Weitere Informationen zu diesem Problem und seiner Lösung finden Sie unter Platzhalterzertifikat verursacht Clientverbindungsprobleme bei Outlook Anywhere.

  • Internet Explorer (Outlook Web Access)

  • Exchange Edge-Transport-Server (Domänensicherheit)

Wichtig

Clients, die Windows Mobile 5.0 ausführen, unterstützen keinen verschlüsselten Kanal zu Servern, die Platzhalternamen im Zertifikat verwenden.

Wenn ein von Ihrer Organisation unterstützter Client keine Platzhalternamen im Serverzertifikat unterstützt und Sie mehrere Clientnamespaces unterstützen müssen, müssen Sie eine dieser Optionen wählen:

  1. Erwerb eines Zertifikats, das mehrere Namen, wie etwa mail.contoso.com, pop.contoso.com und mobile.contoso.com in der SAN-Erweiterung enthält.

  2. Erwerb eines Zertifikats für jede Entität im Namespace, zu der Clients Verbindungen herstellen sollen.

Planen des Namespaces der Organisation

Alle Clients benötigen für die Verbindung einen URL oder einen FQDN (Fully Qualified Domain Name). Jedem Pfad, mit dem Clients Verbindungen herstellen, muss ein gültiges Zertifikat zugeordnet sein, das den Hostnamen, den NetBIOS-Namen, den FQDN oder den allgemeinen Namen des Hosts enthält, zu dem der Client eine Verbindung herstellt. Das Bestimmen der Liste der Namen, die in das Zertifikat aufgenommen werden sollen, ist der Vorgang der Namespaceplanung.

Im Allgemeinen ist die Namespaceplanung für große Organisationen, die viele verschiedene Clients unterstützen und mehrere Regionen mit mehreren Servern überspannen, komplexer als in kleineren Organisationen.

Sie müssen die Planung von Zertifikatnamespaces verstehen, damit Sie wissen, welche Hostnamen in die SAN-Erweiterung des Zertifikats aufgenommen werden müssen, das Sie zum Sichern der bei Exchange 2007 eingehenden Verbindungen verwenden.

Weitere Informationen finden Sie unter Informationen zur Namespaceplanung für Exchange Server 2007.

Wo Sie Ihr Zertifikat erwerben können

Wie bereits zuvor erwähnt, empfehlen wir für den externen Cleintzugriff den Erwerb eines Zertifikats von einer öffentlichen Drittanbieter-Zertifizierungsstelle.

Berücksichtigen Sie beim Bewerten von Zertifizierungsstellen die folgenden Kriterien:

  • Lässt die Zertifizierungsstelle Platzhalternamen im Zertifikat zu? Wenn Ihre Clients Platzhalternamen im Zertifikat unterstützen, stellt der Erwerb eines Zertifikats von einer Zertifizierungsstelle, die Platzhalternamen unterstützt, die einfachste Methode zum Bereitstellen gesicherter Clients dar.

  • Unterstützt die Zertifizierungsstelle die SAN-Erweiterung? Wenn die folgenden Bedingungen erfüllt sind, kann die Verwendung eines Zertifikats, das mehrere Namen im SAN-Feld unterstützt, sinnvoll sein:

    • Sie müssen Clients unterstützen, die keine Platzhalternamen im Zertifikat unterstützen.

    • Clients müssen Verbindungen zu mehr als einem einzelnen Hostpfad herstellen.

    Microsoft ist Partner öffentlicher Zertifizierungsstellen, um Unified Communications-Zertifikate bereitzustellen. Eine aktuelle Liste von Zertifizierungsstellen, die Unified Communications-Zertifikate unterstützen, finden Sie im Microsoft Knowledge Base-Artikel 929395, Partner für Unified Communications-Zertifikate für Exchange 2007 und für Communications Server 2007.

  • Stellt die Zertifizierungsstelle ein hohes Maß an Authentizitätsprüfung bereit? Einige Zertifizierungsstellen sind sehr preisgünstig. Andere Zertifizierungsstellen berechnen mehrere Hundert Euro pro Jahr für ein Zertifikat. Da Sie sich auf die Integrität dieses Zertifikats verlassen, um den bei Ihrer Organisation eingehenden Datenverkehr zu authentifizieren, empfehlen wir, die Wahl einer öffentlichen Zertifizierungsstelle nicht nur anhand des Preises zu treffen. Bewerten und vergleichen Sie für Ihre Entscheidung sorgfältig die von jeder Zertifizierungsstelle angebotenen Dienste und die Reputation der einzelnen Zertifizierungsstellen.

Return to top

Grundlagen von Zertifikatattributen und ihrer Verwendung in Exchange 2007

Ein Verständnis der verschiedenen Attribute von Zertifikaten hilft Ihnen beim Verstehen der Verwendung von Zertifikaten in Exchange. Dieses Verständnis hilft Ihnen wiederum, die Zertifikatanforderungen in Ihrer Exchange-Organisation zu planen. Und dieses Verständnis unterstützt Sie bei der Behebung von Problemen.

X.509-Zertifikate weisen zwei Typen von Attributen auf.

  • Zertifikatfelder sind Attribute innerhalb der signierten Daten des eigentlichen X.509-Zertifikats. Die Integrität dieser Felder ist durch die Signatur geschützt, und ihr Wert kann nicht geändert werden, ohne das Zertifikat neu zu signieren oder neu auszustellen.

  • Zertifikateigenschaften sind Attribute, die Metadaten des Zertifikats oder des privaten Schlüssels darstellen. Einige Eigenschaften sind dem Zertifikat oder dem privaten Schlüssel immanent, wie etwa der Fingerabdruck von Zertifikaten. Viele Eigenschaften können jedoch ohne erneute Signierung des Zertifikats geändert werden.

    Beispielsweise können Sie mithilfe des Cmdlets Enable-ExchangeCertificate den Eigenschaften von Zertifikaten nach ihrer Erstellung Dienste hinzufügen. Sie können Zertifikate für die Verwendung durch IIS aktivieren, wie im Fall von Outlook Web Access oder Exchange ActiveSync, für SMTP, wie bei direkten Vertrauensstellungen oder Domänensicherheit, IMAP, POP und Unified Messaging. Beim Aktivieren eines Zertifikats für einen bestimmten Dienst werden die Zertifikateigenschaften aktualisiert. Weitere Informationen finden Sie unter Enable-ExchangeCertificate.

Sie können diese Attribute anzeigen, indem Sie das Cmdlet Get-ExchangeCertificate mit dem Argument |FL für ein bestimmtes Zertifikat ausführen. Wenn Sie Exchange 2007 RTM ausführen, müssen Sie das Cmdlet mit dem Argument |FL* ausführen, um alle Attributdaten anzuzeigen.

Einige der in der Ausgabe des Cmdlets Get-ExchangeCertificate angegebenen Felder und Eigenschaften sind X.509-Erweiterungsfeldern zugeordnet, die mithilfe von Zertifikat-Manager in der MMC (Microsoft Management Console) angezeigt werden können. Weitere Informationen zum Zertifikat-Manager finden Sie in Hinzufügen der Zertifikatverwaltung zur MMC (Microsoft Management Console). Weitere Informationen über das Cmdlet Get-ExchangeCertificate finden Sie unter Get-ExchangeCertificate.

Zertifikatfelder

Wie bereits weiter oben erläutert, sind Zertifikatfelder Attribute innerhalb der signierten Daten des eigentlichen X.509-Zertifikats. In diesem Abschnitt werden die von den Microsoft Exchange-Diensten verwendeten und in der Ausgabe des Cmdlets Get-ExchangeCertificate angezeigten Zertifikatfelder erläutert.

Einige dieser Felder stellen zugleich Parameter dar, die Sie beim Erstellen eines neuen Zertifikats oder einer neuen Zertifikatanforderung mit dem Cmdlet New-ExchangeCertificate festlegen können. Weitere Informationen über das Cmdlet New-ExchangeCertificate finden Sie unter New-ExchangeCertificate.

Jedes Zertifikatfeld in diesem Abschnitt ist entsprechend der Ausgabe des Cmdlets Get-ExchangeCertificate aufgelistet. Der Name jedes Exchange-Zertifikatfelds in diesem Abschnitt ist dem Namen einer X.509-Zertifikaterweiterung zugeordnet.

Issuer

Dieses Feld enthält den allgemeinen Namen, der den Aussteller des Zertifikats identifiziert. Von Exchange während der Installation oder vom Cmdlet New-ExchangeCertificate erstellte selbstsignierte Zertifikate zeigen cn=hostname an, wobei hostname der Name des lokalen Servers ist.

Zertifikate, die von Zertifizierungsstellen ausgestellt wurden, zeigen normalerweise im Feld Issuer den vollständigen allgemeinen Namen der Zertifizierungsstelle an.

Der Name der X.509-Zertifikaterweiterung ist ebenfalls Issuer.

Das Feld Issuer weist keinen entsprechenden Parameter auf, der im Cmdlet New-ExchangeCertificate festgelegt werden könnte. Das Feld Issuer wird durch die Entität festgelegt, die das Zertifikat ausstellt.

Subject

Dieses Feld identifiziert den Antragsteller des Zertifikats. Subject ist eine X.500-Zeichenfolge, die normalerweise einen einzelnen Namen darstellt, der für den Zugriff auf den Dienst verwendet wird, der das Zertifikat verwendet. Wenn ein Zertifikat vom Cmdlet New-ExchangeCertificate erstellt und der Antragsteller nicht explizit angegeben wird, ist Subject der erste Wert, der im Parameter DomainName beim Ausführen des Cmdlets New-ExchangeCertificate aufgelistet wird. Die folgenden X.500-Felder können vorkommen:

  • C = Country (Land)

  • ST = State (Staat)

  • L = Location (Standort)

  • O = Organization (Organisation)

  • OU = Organizational Unit (Organisationseinheit)

  • CN = Common Name (Allgemeiner Name)

Einige dieser Felder sind beim Erstellen von Zertifikatanforderungen für Drittanbieter-Zertifizierungsstellen erforderlich. Eine tiefgreifende Erläuterung des Felds Subject finden Sie unter Erstellen eines Zertifikats oder einer Zertifikatsanforderung für TLS.

Wenn Sie Microsoft ISA Server 2006 (Internet Security and Acceleration) zum Zweck der Überbrückung vor Exchange vorgeschaltet verwenden, achten Sie darauf, den Blogartikel Zertifikate mit mehreren SAN-Einträgen können die Webveröffentlichung in ISA Server verhindern (englischsprachig) zu lesen, um weitere Informationen zu Antragstellernamen und dem Verhalten von ISA Server zu erhalten.

Hinweis

Die Inhalte von Wiki-Einträgen und Blogs und ihre zugehörigen URLs können ohne vorherige Ankündigung geändert werden.

Wenn Exchange ein selbstsigniertes Zertifikat ohne Benutzerargumente erstellt, enthält dieses Zertifikat einen Antragstellernamen mit dem Wert CN=hostname.

Der Name der X.509-Zertifikaterweiterung ist ebenfalls Subject.

Sie können das Feld Subject festlegen, indem Sie den Parameter SubjectName im Cmdlet New-ExchangeCertificate angeben.

CertificateDomains

Das Feld CertificateDomains identifiziert alle DNS-Domänennamen, die einem Zertifikat zugeordnet sind. DNS-Domänennamen können entweder im allgemeinen Namensattribut (cn=) des Antragstellers oder in der SAN-Erweiterung eines Zertifikats vorkommen. Die Ausgabe des Cmdlets Get-ExchangeCertificate zeigt die Vereinigungsmenge der Domäne im Feld Subject mit allen im SAN gefundenen Domänen an.

Die im Feld CertificateDomains vorkommenden Werte können den Hostnamen oder FQDN umfassen, der zum Zugriff auf den Server verwendet wird. Zur Verwendung eines Zertifikats muss der FQDN, den ein Client zum Herstellen einer Verbindung mit den Server verwendet, im Feld CertificateDomains des Zertifikats vorkommen.

Wenn ein Client beispielsweise eine Verbindung mit einem Server herstellt und dazu POP3 und mail.fourthcofee.com als Servernamen verwendet, kann das den POP3-Einstellungen zugeordnete Zertifikat mail.fourthcofee.com in seinem Feld CertificateDomains enthalten.

Es können jedoch auch Zertifikate mit Platzhalternamen verwendet werden, wie etwa *.fourthcofee.com. Dies ist eine akzeptable Domäne. Jedoch sollten Sie sich bewusst sein, dass einige Legacyclients und mobile Geräte Platzhalternamen in Zertifikaten nicht unterstützen und daher die Verwendung von Platzhalterdomänen möglicherweise nicht unterstützen.

Hinweis

Das SAN-Feld wird durch Exchange nicht direkt für den Zugriff offengelegt. Sie können es nur im Zertifikat-Manager in MMC oder mithilfe des IIS-Managers (Internetinformationsdienste) anzeigen. An eine Website gebundene Zertifikate, wie etwa die von IIS für Outlook Web Access, Exchange ActiveSync oder AutoErmittlung verwendeten, können ebenfalls im IIS-Manager angezeigt werden.

Eine tiefgreifende Erläuterung der Verwendung von SANs und Platzhalternamen in Zertifikaten finden Sie in Erstellen eines Zertifikats oder einer Zertifikatsanforderung für TLS. Darüber hinaus enthält das Exchange-Teamblog, Gelernte Lektionen in Exchange 2007 – Erstellen eines Zertifikats bei einer Drittanbieter-Zertifizierungsstelle (englischsprachig), praktischen Rat zum Erstellen einer Zertifikatanforderung mit mehreren SANs.

Hinweis

Die Inhalte von Wiki-Einträgen und Blogs und ihre zugehörigen URLs können ohne vorherige Ankündigung geändert werden.

Der Name der X.509-Zertifikaterweiterung ist Subject Alternative Name (alternativer Antragstellername), wie jedoch bereits zuvor angemerkt, fügt die Ausgabe des Cmdlets Get-ExchangeCertificate den in der Zertifikaterweiterung Subject enthaltenen Wert der Liste der Namen im Feld CertificateDomains hinzu.

Sie können das Feld CertificateDomains festlegen, indem Sie die Parameter DomainName und Subject des Cmdlets New-ExchangeCertificate angeben.

"NotBefore" und "NotAfter"

Die Werte in den Feldern NotBefore und NotAfter stellen einen Datenbereich dar, innerhalb dessen die Verwendung des Zertifikats gültig ist. Wenn das aktuelle Datum später als das Datum NotAfter liegt, wird das Zertifikat als abgelaufen angesehen. Microsoft Exchange kann abgelaufene Zertifikate weiterhin verwenden, die Clients erstellen jedoch Warnungen, und der Server protokolliert entsprechende Ereignisse im Ereignisprotokoll.

Der Name der X.509-Zertifikaterweiterung, der dem Wert NotBefore zugeordnet ist, ist Valid from (Gültig ab). Der Name der X.509-Zertifikaterweiterung, der dem Wert NotAfter zugeordnet ist, ist Valid to (Gültig bis).

Den Feldern NotBefore und NotAfter entsprechen keine Parameter, die im Cmdlet New-ExchangeCertificate festgelegt werden könnten. Diese Felder werden durch die Entität definiert, die das Zertifikat ausstellt. Selbstsignierte Zertifikate, die vom Exchange-Installationsprogramm oder vom Cmdlet New-ExchangeCertificate erstellt werden, sind ein Jahr gültig.

CertificateRequest

Dieser Wert ist nur bei Zertifikaten vorhanden, die sich noch im Anforderungsstatus befinden. Zertifikatanforderungen sind keine gültigen X.509-Zertifikate und werden daher von Exchange nicht verwendet.

Das Feld CertificateRequest wird durch Angeben des Parameterschalters GenerateRequest des Cmdlets New-ExchangeCertificate aktiviert.

Zertifikateigenschaften

Wie bereits zuvor erläutert, sind Zertifikateigenschaften Attribute, die Metadaten eines Zertifikats oder privaten Schlüssels darstellen. Einige dieser Eigenschaften sind dem Zertifikat oder privaten Schlüssel immanent, wie etwa der Fingerabdruck eines Zertifikats, doch können viele Eigenschaften ohne erneutes Signieren des Zertifikats geändert werden.

Mit Ausnahme der Eigenschaft Thumbprint entspricht keine der Exchange-Zertifikateigenschaften einer X.509-Zertifikaterweiterung.

In diesem Abschnitt werden die Zertifikateigenschaften erläutert.

IsSelfSigned

Die Eigenschaft IsSelfSigned zeigt an, ob ein Zertifikat selbstsigniert ist. Ein selbstsigniertes Zertifikat stellt normalerweise ein Stammzertifikat dar. Dies ist ein Zertifikat, das keine weiteren Zertifikate in der Zertifikatkette aufweist. Das selbstsignierte Zertifikat in Exchange bezieht sich normalerweise auf die folgenden Arten von Zertifikaten:

  • Ein Zertifikat, das beim Installieren von Exchange auf einem Server generiert wird, auf dem kein qualifizierendes Zertifikat vorhanden ist;

  • Ein Zertifikat, das durch die Ausführung des Cmdlets New-ExchangeCertificate generiert wurde.

Wenn die Serverfunktionen Hub-Transport, Edge-Transport, Unified Messaging oder ClientAccess installiert werden, wird vom Exchange-Installationsprogramm ein selbstsigniertes Zertifikat generiert. Wenn im Zertifikatspeicher Persönlich auf dem Hostcomputer ein gültiges Zertifikat vorhanden ist, wird das vorhandene Zertifikat verwendet, und das vom Exchange-Installationsprogramm erstellte selbstsignierte Zertifikat wird nicht verwendet. Die gültigen Werte sind True oder False.

RootCAType

Die Eigenschaft RootCAType identifiziert den Typ der Zertifizierungsstelle, von der das Zertifikat ausgestellt wurde. Wenn der Parameter IsSelfSigned auf True festgelegt ist, sollte der Wert der Eigenschaft RootCAType None sein. Andernfalls kann das Zertifikat zu unerwarteten Ergebnissen im Zertifikatauswahlprozess führen. Dies sind die anderen möglichen Werte:

  • Registry   Eine interne, private PKI-Stammzertifizierungsstelle wurde manuell im Zertifikatspeicher eingerichtet.

  • ThirdParty   Eine öffentliche Drittanbieter-Zertifizierungsstelle.

  • GroupPolicy   Eine interne, private PKI-Stammzertifizierungsstelle, die mithilfe von Gruppenrichtlinien bereitgestellt wurde.

  • Enterprise   Eine interne, private PKI-Stammzertifizierungsstelle, die mithilfe von Active Directory bereitgestellt wurde.

  • Unknown   Exchange kann den Typ des installierten Zertifikats nicht ermitteln.

Das Verständnis der Weise, in der das Stammzertifikat der Zertifizierungsstelle auf einem Computer installiert wurde, kann Ihnen bei der Diagnose inkonsistenter Richtlinien für Vertrauensstellungen helfen. Derartige Inkonsistenzen können dazu führen, dass Zertifikate auf einigen Servern als gültig erkannt werden, nicht jedoch auf anderen Servern.

Beispielsweise zeigt der Wert Registry an, dass jemand das Zertifikat manuell auf einem Server installiert hat. Dies kann zu Inkonsistenzen führen, wenn das Zertifikat auf anderen Servern in der Organisation nicht installiert wurde. Es wird empfohlen, Zertifikate mithilfe von Gruppenrichtlinien oder Active Directory auf allen Computern zu verteilen.

Services

Die Eigenschaft Services identifiziert die Dienste, mit denen das betreffende Zertifikat verwendet werden kann. Die gültigen Werte sind SMTP, POP, IMAP, UM und IIS.

Dieser Wert wird im Feld Services durch Angeben des Parameters Services im Cmdlet Enable-ExchangeCertificate festgelegt. Weitere Informationen finden Sie unter Enable-ExchangeCertificate.

Status

Die Eigenschaft Status identifiziert, ob das Zertifikat gültig ist. Das Feld Status ist für die Problembehebung von Zertifikatproblemen sehr nützlich. Wenn der Status-Wert für ein bestimmtes Zertifikat nicht Valid ist, wird das betreffende Zertifikat nicht vom Exchange-Server für Dienste verwendet. Die Werte für die Status-Eigenschaft umfassen die folgenden:

  • Unknown   Dieser Status zeigt im Allgemeinen an, dass der Status des Zertifikats nicht überprüft werden kann, weil die Zertifikatsperrliste (Certificate Revocation List, CRL) nicht verfügbar ist oder der Server keine Verbindung mit ihr herstellen kann. Stellen Sie sicher, dass der Computer Verbindungen zur Zertifikatsperrstelle herstellen kann. Weitere Informationen finden Sie unter Konfigurieren der Proxyeinstellungen für WinHTTP.

  • Valid   Das Zertifikat funktioniert ordnungsgemäß.

  • Revoked   Die CRL hat angezeigt, dass dieses Zertifikat gesperrt wurde. Sie müssen ein neues Zertifikat erstellen.

  • DateInvalid   Dieser Status zeigt an, dass die Systemzeit nicht richtig, das Zertifikat abgelaufen oder die Zeit auf dem System, das die Datei signiert hat, unrichtig ist. Vergewissern Sie sich, dass die folgenden Bedingungen vorliegen:

    • Die Uhrzeit des lokalen Computers ist richtig.

    • Das Zertifikat ist nicht abgelaufen.

    • Die Uhrzeit des sendenden Systems ist richtig.

    Wenn das Zertifikat angelaufen ist, müssen Sie ein neues Zertifikat generieren.

  • Untrusted   Dieser Status zeigt an, dass das Zertifikat nicht selbstsigniert ist. Es wurde jedoch von einer Zertifizierungsstelle signiert, die keine Vertrauensstellung auf dem lokalen Computer genießt. Sie müssen das Zertifikat der Zertifizierungsstelle dem Speicher Vertrauenswürdige Stammzertifizierungsstellen auf dem Computer hinzufügen. Weitere Informationen zum manuellen Hinzufügen von Zertifikaten zum lokalen Zertifikatspeicher finden Sie in der Hilfedatei zum Zertifikat-Manager in MMC.

  • Invalid   Das Zertifikat wurde durch ein anderes Problem ungültig, etwa durch ein nicht vertrauenswürdiges, ungültiges oder gesperrtes Zertifikat an einer Stelle im Zertifikatpfad.

Weitere Informationen zur Problembehebung finden Sie unter den folgenden Themen:

HasPrivateKey

Die Eigenschaft HasPrivateKey zeigt an, ob das installierte Zertifikat über einen privaten Schlüssel verfügt. Dies ist sehr wichtig, da der Microsoft Exchange-Transportdienst, der Microsoft Exchange-POP3-Dienst und der Microsoft Exchange-IMAP4-Dienst kein Zertifikat verwendet, das keinen privaten Schlüssel aufweist.

Thumbprint

Die Eigenschaft Thumbprint ist eine eindeutige Zeichenfolge, die das Zertifikat identifiziert. Wenn das gleiche Zertifikat auf mehreren Exchange-Servern installiert ist, können Sie diese anhand ihrer Fingerabdrücke identifizieren. Wenn das gleiche Zertifikat normalerweise auf mehreren Exchange-Servern installiert ist, wenn mehrere Edge-Transport-Server E-Mail mit dem gleichen FQDN akzeptieren, wie etwa im Fall von mail.fourthcoffee.com. Es ist wesentlich kostengünstiger, das gleiche Zertifikat auf mehreren Servern zu installieren, als für jeden Server neue Zertifikate anzufordern. Das Zertifikat muss jedoch über einen exportierbaren privaten Schlüssel verfügen.

Die Eigenschaft Thumbprint wird verwendet, um ein Zertifikat für die folgenden Cmdlets anzugeben:

Der Name der X.509-Zertifikaterweiterung, der der Eigenschaft Thumbprint zugeordnet ist, ist ebenfalls Thumbprint.

Return to top

Vertrauensstellung und Gültigkeit von Zertifikaten

Damit ein Zertifikat für die Authentifizierung verwendet werden kann, muss das Zertifikat validiert und vertrauenswürdig sein.

Damit ein bestimmtes X.509-Zertifikat überprüft werden kann, muss die Stammzertifizierungsstelle als vertrauenswürdig eingestuft werden, die das Zertifikat ausgestellt hat. Eine Stammzertifizierungsstelle ist die Zertifizierungsstelle mit der höchsten Vertrauensstellung. Diese befindet sich auf oberster Ebene einer Zertifizierungsstelle. Die Stammzertifizierungsstelle verfügt über ein selbstsigniertes Zertifikat. Wenn Sie eine Anwendung ausführen, die Zertifikatauthentifizierung verlangt, muss jedes Zertifikat über eine Zertifikatkette verfügen, die in einem Zertifikat im vertrauenswürdigen Stammcontainer des lokalen Computers endet. Der vertrauenswürdige Stammcontainer enthält Zertifikate von Stammzertifizierungsstellen.

Ein Zertifikat ist mithilfe eines anderen Zertifikats mit einer Zertifizierungsstelle verkettet. Das Zertifikat sollte ebenfalls von einer Zertifizierungsstelle ausgestellt worden sein und wäre daher mit dieser verkettet. Diese Verkettung von Zertifikaten wird auch als Zertifizierungspfad bezeichnet. Jedes Zertifikat im Zertifizierungspfad muss gültig sein, damit das Zertifikat gültig ist. Außerdem muss es sich beim Zertifikat an oberster Stelle der Kette um eine vertrauenswürdige Stammzertifizierungsstelle handeln.

Es sind zwei Arten von vertrauenswürdigen Stammzertifizierungsstellen verfügbar, die Sie zum Implementieren von Anwendungen verwenden können, die auf Zertifikatauthentifizierung basieren: öffentliche Drittanbieter-Stammzertifizierungsstellen und private Stammzertifizierungsstellen.

Öffentliche Drittanbieter-Stammzertifizierungsstellen

Windows, Windows Mobile und verschiedene Betriebssysteme von Drittanbietern enthalten eine Reihe von eingebauten öffentlichen Drittanbieter-Stammzertifizierungsstellen. Wenn Sie die von diesen Drittanbieter-Stammzertifizierungsstellen ausgestellten Zertifikate als vertrauenswürdig einstufen, können Sie die von diesen Zertifizierungsstellen ausgestellten Zertifikate überprüfen.

Die Vertrauensstellung wird automatisch eingeräumt, sofern die folgenden Bedingungen erfüllt sind:

  • Ihre Organisation verwendet die standardmäßige Windows-Installation;

  • Die in Ihrer Organisation verwendete Clientsoftware und die verwendeten mobilen Geräte vertrauen ebenfalls den eingebauten öffentlichen Drittanbieter-Stammzertifizierungsstellen;

In diesem Fall ist keine weitere Konfiguration der Vertrauensstellung erforderlich.

Private vertrauenswürdige Stammzertifizierungsstellen

Eine private vertrauenswürdige Stammzertifizierungsstelle ist eine Stammzertifizierungsstelle, die von einer privaten oder internen PKI bereitgestellt wurde. Wenn Ihre Organisation beispielsweise eine interne PKI mit ihrem eigenem Stammzertifikat bereitgestellt hat, müssen Sie weitere Konfigurationen der Vertrauensstellung vornehmen.

Im Allgemeinen ist die Verwendung der von einer privaten PKI ausgestellten Zertifikate für Clientanwendungen, die externe Verbindungen in Ihre Organisation ermöglichen, keine empfohlene Methode.

Wenn private Stammzertifizierungsstellen verwendet werden, müssen Sie den vertrauenswürdigen Windows Stammzertifikatspeicher auf allen Geräten, Clients und Windows-Betriebssystemen aktualisieren, auf denen Zertifikatauthentifizierung erforderlich ist.

Sie können Vertrauensstellungen auf zwei Arten konfigurieren: direkte Stammvertrauensstellung und übergreifende Zertifizierung.

Direkte Stammvertrauensstellung

Wenn Sie ein Zertifikat als vertrauenswürdig einstufen möchten, das von einer privaten Stammzertifizierungsstelle ausgestellt wurde, können Sie dieses Stammzertifikat manuell dem Informationsspeicher für vertrauenswürdige Stammzertifikate auf einem Computer mit Windows hinzufügen. In einigen Fällen können Sie auch dem vertrauenswürdigen Stammspeicher von mobilen Clients ein Stammzertifikat hinzufügen. Weitere Informationen zum manuellen Hinzufügen von Zertifikaten zum lokalen Zertifikatspeicher auf einem Computer mit Windows finden Sie in der Hilfedatei zum Zertifikat-Manager in MMC. Weitere Informationen über das Installieren von Zertifikaten auf Windows Mobile-Geräten finden Sie in Installieren von Stammzertifikaten auf einem Windows Mobile-Gerät.

Wichtig

Wahrscheinlich können Sie nicht auf allen Computern und Geräten, die von Benutzern für den Zugriff auf Exchange verwendet werden, Zertifikate installieren. Beispielsweise können einige Benutzer versuchen, auf Outlook Web Access im Kioskmodus oder vom Computer eines Freundes zuzugreifen. In diesem Szenario wird den Benutzern eine Warnung angezeigt, sie werden jedoch nicht am Zugriff auf ihre E-Mail gehindert. Da dieses Verhalten bei den Benutzern die Gewohnheit fördert, Zertifikatwarnungen zu ignorieren, ist es keine empfehlenswerte Methode. Daher ist die Verwendung von vertrauenswürdigen Drittanbieter-Zertifizierungsstellen eine optimale Methode.

Übergreifende Zertifizierung

Übergreifende Zertifizierung findet statt, wenn eine Zertifizierungsstelle ein Zertifikat signiert, das von einer anderen Zertifizierungsstelle generiert wird. Übergreifende Zertifizierung wird verwendet, um Vertrauensstellungen zwischen PKIs herzustellen. Wenn Sie eine eigene PKI einsetzen, statt direkte manuelle Vertrauensstellung für eine Stammzertifizierungsstelle einer anderen privaten PKI zu verwenden, können Sie ein übergreifendes Zertifikat für die andere Zertifizierungsstelle unter Ihrer Stammzertifizierungsstelle erstellen. In diesem Fall wird die Vertrauensstellung eingerichtet, weil das übergreifende Zertifikat letztlich über die Zertifikatkette auf Ihre vertrauenswürdige Stammzertifizierungsstelle verweist.

Konfigurieren des Zugriffs auf die Zertifikatsperrliste

Wenn ein bestimmter Dienst, wie etwa der Microsoft Exchange-Transportdienst im SMTP/TLS-Szenario oder IIS im HTTPS-Szenario, ein Zertifikat abruft, überprüft der Dienst die Zertifikatkette und überprüft das Zertifikat. Die Überprüfung des Zertifikats ist ein Vorgang, bei dem viele Attribute des Zertifikats bestätigt werden. Die meisten dieser Attribute können auf dem lokalen Computer durch die Anwendung bestätigt werden, die das Zertifikat anfordert. Die beabsichtigte Verwendung des Zertifikats, die Ablaufdatumsangaben auf dem Zertifikat und ähnliche Attribute können z. B. außerhalb des Kontexts einer PKI überprüft werden. Die Überprüfung, ob das Zertifikat gesperrt wurde, muss jedoch mit der Zertifizierungsstelle überprüft werden, die das Zertifikat ausgestellt hat. Aus diesem Grund stellen die meisten Zertifizierungsstellen der Öffentlichkeit eine Zertifikatsperrliste zur Verfügung, um den Sperrstatus zu überprüfen.

Für die erfolgreiche Zertifizierung mit Zertifikaten müssen den Diensten, die den Client authentifizieren sollen, Zertifikatsperrlisten für die von Ihnen verwendeten Zertifizierungsstellen zur Verfügung stehen. Bei einem Fehler in der Sperrüberprüfung schlägt der Authentifizierungsdienst fehl.

Ihre authentifizierenden Server müssen in der Lage sein, auf Zertifikatsperrlisten für externe Zertifizierungsstellen zuzugreifen.

Alle öffentlichen Zertifizierungsstellen verfügen über öffentlich zugängliche Zertifikatsperrlisten, mit denen die Server Ihrer Organisation Kontakt aufnehmen können. In einigen Fällen sind Zertifikatsperrlisten für private, interne PKIs nur mit LDAP (Lightweight Directory Access Protocol) verfügbar. In den meisten Fällen werden bei öffentlichen Zertifizierungsstellen CRLs über HTTP veröffentlicht. Stellen Sie sicher, dass die entsprechenden ausgehenden Ports und Proxys so konfiguriert sind, dass Ihre Server und Clients die Zertifikatsperrliste abrufen können. Sie können überprüfen, welche Protokolle ein bestimmter CRL-Verteilungspunkt akzeptiert, indem Sie ein Zertifikat in MMC öffnen und das Feld CRL-Verteilungspunkte anzeigen.

In einigen Fällen kann es erforderlich sein, die Zertifikatsperrliste für die Zertifizierungsstelle, die Ihre Zertifikate ausstellt, öffentlich zugänglich zu machen. Wenn Sie beispielsweise Domänensicherheit bereitstellen, müssen Sie verstehen, dass selbst in dem Fall, dass ein Edge-Transport-Server ein Zertifikat von Ihrer eigenen Organisation abruft, er die Zertifikatkette überprüft, um das Zertifikat zu überprüfen. Aus diesem Grund muss die Zertifikatsperrliste für Ihre Zertifizierungsstelle Ihren eigenen Edge-Transport-Servern zur Verfügung stehen. Außerdem müssen alle Partner, mit denen Sie domänengesicherte E-Mail-Nachrichten austauschen, in der Lage sein, auf die Zertifikatsperrliste für die Zertifikatstelle zuzugreifen, die Ihre Zertifikate ausstellt.

Konfigurieren der Proxyeinstellungen für WinHTTP

Exchange 2007-Server basieren auf den zugrunde liegenden Windows-HTTP-Diensten (WinHTTP) zur Verwaltung des gesamten HTTP- und HTTPS-Datenverkehrs. Beispielsweise können sowohl Hub-Transport-Server als auch Edge-Transport-Server HTTP verwenden, um auf Aktualisierungen für die Updates des standardmäßigen Exchange 2007-Antispam-Filters und den Antispam-Updatedienst von Microsoft Forefront Security für Exchange Server zuzugreifen. Alle Exchange-Serverfunktionen verwenden WinHTTP, um die Überprüfung von Zertifikatsperrlisten zu aktivieren.

Weitere Informationen finden Sie unter Konfigurieren der Proxyeinstellungen für WinHTTP.

Testen der PKI- und Proxykonfiguration

Wenn Sie Ihre PKI- und Proxykonfiguration für einen bestimmten Exchange-Server überprüfen möchten, verwenden Sie Certutil.exe, um die Zertifikatkette für Serverzertifikat zu überprüfen. Certutil.exe ist ein Befehlszeilentool, das als Teil der Zertifikatdienste in Windows-Server-Betriebssystemen installiert wird. Weitere Informationen finden Sie unter Testen der PKI- und Proxykonfiguration.

Return to top

Erstellen, Importieren und Aktivieren von Zertifikaten

Es bestehen verschiedene Möglichkeiten, ein Zertifikat zu erwerben, das in Exchange 2007 installiert und verwendet werden kann. Die Wahl der Methode hängt von Ihren Bedürfnissen ab. Exchange 2007 generiert einen Satz selbstsignierter Zertifikate, um das Sichern der Standardkonfiguration zu ermöglichen. Diese sollte im Lauf der Zeit erneuert werden, um die Sicherheit des Systems zu unterstützen. Exchange generiert nicht automatisch Anforderungen für das Signieren durch Zertifizierungsstellen. Gleich ob Sie ein neues selbstsigniertes Zertifikat oder eine Zertifikatanforderung für eine Zertifizierungsstelle erstellen möchten, Sie verwenden für beide Methoden das gleiche Cmdlet.

Dieser Abschnitt enthält eine Übersicht der Vorgänge, die mit den von Exchange 2007 verwendeten Zertifikaten ausgeführt werden können. Lesen Sie diesen Abschnitt, wenn Sie mit den ExchangeCertificate-Cmdlets nicht vertraut sind. Die anwendungsspezifischen Beispiele und Verfahrensweisen werden weiter unten in diesem Dokument am Beispiel von POP3 vorgestellt. Dieser Abschnitt enthält außerdem Links zu anwendungsspezifischer Dokumentation.

Zertifikat-Cmdlets

In früheren Versionen von Exchange Server erfolgte die gesamte Zertifikatverwaltung mithilfe von IIS und des Zertifikat-Managers in MMC. In Exchange 2007 werden die meisten Aufgaben der Zertifikatverwaltung im Zusammenhang mit Exchange mithilfe der folgenden ExchangeCertificate-Cmdlets in der Exchange-Verwaltungsshell ausgeführt:

  • New-ExchangeCertificate   Dieses Cmdlet generiert selbstsignierte Zertifikate und Zertifikatanforderungen für Zertifizierungsstellen.

  • Import-ExchangeCertificate   Dieses Cmdlet importiert Zertifikate, die zuvor exportiert wurden, und importiert Zertifikatdateien, die von Zertifizierungsstellen generiert wurden.

  • Export-ExchangeCertificate   Dieses Cmdlet exportiert Zertifikate als Sicherung oder für die Verwendung auf mehreren Servern.

  • Enable-ExchangeCertificate   Dieses Cmdlet aktiviert spezifische Dienste auf einem Zertifikat.

  • Get-ExchangeCertificate   Dieses Cmdlet zeigt die Attribute eines Zertifikats an.

  • Remove-ExchangeCertificate   Dieses Cmdlet entfernt Zertifikate aus Exchange Server und dem lokalen Zertifikatspeicher.

Weitere Informationen über das Erstellen von Zertifikatanforderungen für Zertifizierungsstellen finden Sie in Erstellen eines Zertifikats oder einer Zertifikatsanforderung für TLS.

Die folgenden Abschnitte enthalten kurze Beispiele, um die Verwendung des Cmdlets ExchangeCertificate zum Ausführen häufiger Zertifikataufgaben zu veranschaulichen. Weitere Informationen und Beispiele finden Sie in der ExchangeCertificate-Cmdlet-Hilfe unter Globale Cmdlets.

Erstellen von selbstsignierten Zertifikaten

Führen Sie den folgenden Befehl aus, um ein selbstsigniertes Zertifikat für die Verwendung durch den SMTP-Dienst für einen Server mit dem Hostnamen Server1 und der Domäne fourthcoffee.com zu erstellen:

New-ExchangeCertificate -DomainName "server1.fourthcoffee.com", "server1" -Services "SMTP"

Duplizieren von selbstsignierten Zertifikaten

Wenn ein selbstsigniertes Zertifikat erneuert werden muss, können Sie es mithilfe des folgenden Befehls duplizieren:

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate

Der Platzhalter thumbprint ist der Fingerabdruck des zu erneuernden Zertifikats. Die Dienste für das neue Zertifikat können außerdem in der folgenden Weise im Befehl angegeben werden:

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate -Services SMTP,POP,IMAP

Anschließend können Sie das Zertifikat durch Ausführen des folgenden Befehls aktivieren:

Enable-ExchangeCertificate <thumbprint>

Erstellen von Zertifikatanforderungen und Installieren von vertrauenswürdigen Zertifikaten

Das Installieren eines öffentlichen Drittanbieter-Zertifikats ist ein komplexerer Vorgang. Sie müssen eine Zertifikatanforderung generieren, das ausgestellte Zertifikat und alle erforderlichen Zertifikate der Zertifizierungsstelle importieren und anschließend das ausgestellte Zertifikat für seine(n) vorgesehenen Verwendungszweck(e) aktivieren.

Dieser Abschnitt enthält ein Beispiel, wie der POP3-Dienst für die Zertifikatverwendung aktiviert werden kann. In diesem Beispiel stellen Clients Verbindungen mit dem POP3-Dienst her, indem sie Verbindungen mit dem FQDN popserver.fourthcoffee.com herstellen.

Zertifikatanforderung

Da das resultierende Zertifikat von einer öffentlichen Drittanbieter-Zertifizierungsstelle stammt, müssen Sie zuerst eine Zertifikatanforderung erstellen, indem Sie den folgenden Befehl ausführen:

New-ExchangeCertificate -DomainName popserver.fourthcoffee.com -SubjectName "c=us,o=contoso corp, cn=popserver.fourthcoffee.com" -PrivateKeyExportable:$True -GenerateRequest:$True -Path "C:\CertRequest.req"

Wenn die Zertifikatanforderung ordnungsgemäß generiert wurde, wird eine Zertifikatanforderungsdatei (.cer oder .der) im Stamm des Systemlaufwerks erstellt, und die Exchange-Verwaltungsshell zeigt einen Fingerabdruck für die Anforderung an.

Hinweis

Die von den Anbietern zurückgegebenen Zertifikate unterstützen verschiedene Erweiterungen für die Zertifikatanforderungsdatei, wie etwa .der oder .cer. Diese Erweiterungen stellen die Codierungsmethode dar, die von der Zertifikatdatei verwendet wird. Standardmäßig erstellt die Anforderung New-ExchangeCertificate eine Base64-codierte Datei (.cer). Verwenden Sie den Parameter BinaryEncoded, um eine DER-Datei zu erstellen.

Im vorstehenden Befehl ist der Parameter PrivateKeyExportable auf $True festgelegt, so dass dieses Zertifikat zusammen mit dem privaten Schlüssel für die Verwendung auf mehreren Exchange-Servern, auf die möglicherweise mithilfe des gleichen FQDNs zugegriffen werden muss, exportiert werden kann. Beispielsweise kann zwischen mehreren ClientAccess-Servern Lastenausgleich für die Unterstützung von POP3-Verbindungen konfiguriert werden.

Hinweis

Der Parameter PrivateKeyExportable ist optional. Er sollte nur angegeben werden, wenn Zertifikatanforderungen für vertrauenswürdige Zertifizierungsstellen generiert werden. Indem der Parameter PrivateKeyExportable auf $True festgelegt wird, können Sie das Zertifikat und die zugeordneten Schlüssel verschieben und archivieren. Bei selbstsignierten Zertifikaten ist dies nicht erforderlich.

Der vorstehende Befehl gibt auch den Parameter Subjectname als X.500-Namen an. Für die meisten Drittanbieter-Zertifizierungsstellen ist die Angabe eines gültigen X.500-Namens für das Zertifikat erforderlich. Als Mindestanforderung verlangen die meisten Zertifizierungsstellen, dass die im Feld organizationName (o=) aufgelistete Organisation im Besitz des Domänennamens ist, der im commonName (cn=) des Webservers genannt ist.

Nach dem Abschluss der Anforderung kann die Anforderungsdatei an einen Zertifikatanbieter gesendet werden, um ein Zertifikat zu erwerben.

Hinweis

Das Cmdlet Get-ExchangeCertificate gibt Zertifikate zurück, einschließlich Zertifikaten, deren Anforderungen noch ausstehen. Zur Unterscheidung weisen Zertifikatanforderungen ein Attribut CertificateRequest auf, das die in der Zertifikatanforderungsatei gespeicherte Ausgabe anzeigt. Diese Ausgabe kann nützlich sein, wenn die Zertifikatanforderungsdatei versehentlich gelöscht oder die Anforderung ohne den Parameter generiert wird. Die CertificateRequest-Daten sind Base64-codiert und können in eine Datei kopiert und im Rahmen einer Zertifikatanforderung an die Zertifizierungsstelle gesendet werden.

Importieren eines Zertifikats

Nachdem ein Zertifikat von einer Zertifizierungsstelle zurückgegeben wird, muss es in den Exchange-Server importiert werden. Führen Sie den folgenden Befehl aus, um ein Zertifikat, für das eine Anforderung mit dem Cmdlet New-ExchangeCertificate erstellt worden war, ordnungsgemäß zu importieren:

Import-ExchangeCertificate -Path "C:\CertificateFile.cer"

Wenn das Zertifikat erfolgreich importiert wurde, gibt dieser Befehl einen Zertifikatfingerabdruck zurück, der zum Aktivieren spezifischer Dienste verwendet werden kann.

Wichtig

Sie müssen das Zertifikat auf dem gleichen Computer importieren, auf dem die Zertifikatanforderung erstellt wurde. Verwenden Sie ferner nicht den Zertifikat-Manager in MMC, um Exchange-Zertifikate zu importieren.

Aktivieren eines Zertifikats

Beim Aktivieren eines Zertifikats kann angegeben werden, welche Dienste ein bestimmtes Zertifikat verwenden können. Mit dem folgenden Befehl wird das ausgestellte Zertifikat für den POP3-Dienst aktiviert:

Enable-ExchangeCertificate <thumprint> -Services:"POP"

Ein Zertifikat kann durch Ausführen des folgenden Befehls zugleich importiert und aktiviert werden:

Import-ExchangeCertificate -Path "C:\CertificateFile.cer" | Enable-ExchangeCertificate -Services:"POP"

Überprüfen der Zertifikatinstallation

Führen Sie den folgenden Befehl aus, um zu bestätigen, dass alle erforderlichen Schritte abgeschlossen wurden und das Zertifikat installiert und einsatzbereit ist:

Get- ExchangeCertificate <thumbprint> | fl *

Hinweis

Wenn Sie Exchange 2007 SP 1 oder höher ausführen, verwenden Sie nicht das Sternchen (*) im Befehlsargument.

Die Ausgabe dieses Befehls gibt Daten ähnlich den folgenden zurück:

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule,System.Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {popserver.fourthcoffee.com, fourthcoffee.com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=3rdPartyCAExample.com
NotAfter           : 8/7/2008 10:04:02 AM
NotBefore          : 8/7/2007 10:04:02 AM
PublicKeySize      : 2048
RootCAType         : ThirdParty
SerialNumber       : 83FAE8B2398F2A9E44485CBA85D548DF
Services           : POP
Status             : Valid
Subject            : C=us,o=contoso corp, CN=fourthcoffee.com 
Thumbprint         : 257C327A164ED8A6FCDAFCA7789D29B60369DCA7

Untersuchen Sie die Ausgabe dieses Befehls, um zu prüfen, ob die folgenden Informationen wahr sind:

  • Die Domänennamen, deren Vorhandensein Sie erwarten, sind im Feld CertificateDomains aufgelistet.

  • Die Eigenschaft HasPrivateKey ist auf True festgelegt.

  • Die Eigenschaft RootCAType ist ordnungsgemäß festgelegt. Weitere Informationen zur Eigenschaft RootCAType finden Sie unter Certificate Properties weiter oben in diesem Dokument.

  • Die erforderlichen Dienste sind für das Zertifikat aktiviert.

  • Der Status ist auf Valid festgelegt.

Zertifikatdienste

Dienste, wie etwa POP, IMAP, IIS und SMTP, können auf einem Zertifikat aktiviert werden. Dienste stellen keine Felder im eigentlichen Zertifikat dar. Vielmehr handelt es sich um Metadateneigenschaften der Zertifikate. Daher können sie geändert werden, ohne dass das Zertifikat entwertet wird.

Wenn Dienste aktiviert werden, treten Konfigurationsänderungen an anderen Komponenten auf, wie etwa in der IIS-Metabasis, dem Dateisystem oder in den IMAP4- und POP3-Einstellungen. In diesem Abschnitt werden die Konfigurationsänderungen beschrieben, die beim Aktivieren eines bestimmten Diensts durch Ausführen des Cmdlets Enable-ExchangeCertificate auftreten.

POP und IMAP

Wenn POP und IMAP einem Zertifikat als weitere Dienste hinzugefügt werden, wird das x509CertificateName-Attribut auf dem POPSettings-Objekt oder dem IMAPSettings-Objekt so aktualisiert, dass die Domäne in den Antragsteller des Zertifikats aufgenommen wird.

Um beispielsweise zu überprüfen, ob das POPSettings-Objekt aktualisiert wurde, führen Sie den folgenden Befehl aus:

Get-POPSettings | fl *

Hinweis

Wenn Sie Exchange 2007 SP 1 oder höher ausführen, verwenden Sie nicht das Sternchen (*) im Befehlsargument.

IIS

Wenn IIS aktiviert ist, wird die IIS-Standardwebsite für die Verwendung dieses bestimmten Zertifikats aktualisiert.

Die Aktivierung eines Zertifikats für IIS kann mithilfe des Cmdlets Enable-ExchangeCertificate ausschließlich für die IIS-Standardwebsite erfolgen. Wenn Sie Outlook Web Access oder AutoErmittlung auf anderen Websites als der standardmäßigen IIS-Website bereitstellen, müssen Sie den IIS-Manager zum Zuweisen eines spezifischen Zertifikats zu den betreffenden Websites verwenden.

SMTP

Wenn der SMTP-Dienst auf einem Zertifikat aktiviert wird, wird dem Konto Netzwerkdienst Lesezugriff auf die entsprechende private Schlüsseldatei im Verzeichnis Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten\Microsoft\Crypto\RSA\MachineKeys erteilt. Durch diese Aktion werden die erforderlichen Berechtigungen bereitgestellt, damit der Microsoft Exchange-Transportdienst auf den privaten Schlüssel zugreifen und ihn zum Entschlüsseln von Nachrichten verwenden kann, die mithilfe von TLS gesichert sind.

Microsoft Exchange Unified Messaging-Dienst

Wenn der Microsoft Exchange Unified Messaging-Dienst für ein Zertifikat aktiviert wird, wird die Zertifikateigenschaft so aktualisiert, dass sie Unified Messaging beinhaltet. Das Zertifikat wird verwendet, wenn folgende Bedingungen erfüllt sind:

  • Die Unified Messaging-Serverfunktion ist auf dem Computer installiert.

  • Das Zertifikat enthält den physikalischen FQDN des lokalen Computers im Zertifikatfeld CertificateDomains.

Return to top

Zertifikatauswahl

Zertifikatauswahl ist ein Vorgang, der von Exchange-Komponenten ausgeführt wird, um zu bestimmen, welches Zertifikat für eine eingehende Verbindung verwendet werden soll. SMTP STARTTLS, POP3 und IMAP4 führen alle einen ähnlichen Auswahlprozess aus, um zu bestimmen, welches Zertifikat für eine bestimmte Sitzung verwendet werden soll. Dieser Prozess ist ziemlich deterministisch. Er kann jedoch irreführend sein, insbesondere, wenn auf dem Computer mehrere Zertifikate installiert sind.

In diesem Abschnitt wird der Auswahlprozess für die Zertifizierung für SMTP STARTTLS, SMTP X-AnonymousTLS, POP3 und IMAP4 beschrieben. Weitere Informationen über die transportspezifische Zertifikatauswahl finden Sie unter SMTP-TLS-Zertifikatauswahl.

SMTP STARTTLS

STARTTLS ist die SMTP-Aktionsart, die eine sichere TLS-Sitzung einleitet. STARTTLS wird von Exchange nur angekündigt, wenn ein gültiges Zertifikat auf dem Computer vorhanden ist, der Exchange ausführt.

Zum Ankündigen oder Verwenden von STARTTLS wählt Exchange ein Zertifikat basierend auf dem FQDN und einem entsprechenden Wert im Feld CertificateDomains eines Zertifikats aus. Der FQDN basiert auf den folgenden Informationen:

  • Outbound STARTTLS   Das Zertifikat wird basierend auf dem Wert von FQDN auf einem Sendeconnector ausgewählt.

  • Inbound STARTTLS   Das Zertifikat wird basierend auf dem Wert von FQDN auf einem Empfangsconnector ausgewählt.

    Hinweis

    Für ausgehendes STARTTLS und eingehendes STARTTLS wird der FQDN des Connectors nicht angegeben, der physikalische FQDN des Exchange-Servers wird für die Zuordnung verwendet.

Nachdem der FQDN bestimmt wurde, durchsucht Exchange den Zertifikatspeicher Persönlich auf dem Hostcomputer nach allen gültigen Zertifikaten. Ein Zertifikat ist gültig für die Verwendung durch TLS, wenn es alle der folgenden Bedingungen erfüllt:

  • Das Feld Enhanced Key Usage enthält entweder den Objektbezeichner für die Serverauthentifizierung (auch als OID bezeichnet) oder ist Null.

  • Die PKI-Zertifikaterweiterung listet einen RSA-Schlüssel mit mindestens 1024 Bit auf.

  • Das Zertifikat überprüft die Zertifikatkette bis hinauf zu einem vertrauenswürdigen Stamm, oder das Zertifikat ist selbstsigniert.

  • Das Zertifikat und die Zertifikatkette bestehen die Sperrprüfung.

  • Der private Schlüssel ist vorhanden und verfügbar.

  • Der private Schlüssel ist nicht auf einem Wechselgerät gespeichert.

  • Der private Schlüssel ist nicht durch ein Kennwort geschützt.

Wenn mehrere gültige Zertifikate gefunden werden, wählt Exchange ein Zertifikat basierend auf den folgenden Kriterien aus:

  • Der Wert im Feld "NotBefore"   Exchange wählt das neueste gültige Zertifikat.

  • Von einer vertrauenswürdigen Zertifizierungsstelle ausgestellte Zertifikate im Vergleich mit selbstsignierten Zertifikaten   Exchange zieht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellte Zertifikate den selbstsignierten Zertifikaten vor.

In den meisten Fällen wählt Exchange ein von einer vertrauenswürdigen Zertifizierungsstelle ausgestelltes Zertifikat zum Nachteil eines selbstsignierten Zertifikats unabhängig vom Alter des Zertifikats aus. Wenn kein gültiges Zertifikat gefunden wird, wird STARTTLS nicht angekündigt.

SMTP X-AnonymousTLS

X-AnonymousTLS wird verwendet, um das Sichern von Verbindungen zwischen zwei Hub-Transport-Servern und zwischen Hub-Transport-Servern und Edge-Transport-Servern zu unterstützen. In Exchange 2007 SP1 wurde der Prozess der Zertifikatauswahl vereinfacht, so dass für den Fall, dass kein Zertifikat gefunden wird, für die Sitzung ein temporärer Verschlüsselungsschlüssel für die Sitzung erstellt wird.

Exchange sucht nach einem internen Transportzertifikat. Wenn kein gültiges internes Transportzertifikat gefunden wird, sucht Exchange nach einem gültigen Zertifikat von einer Zertifizierungsstelle.

Daher tritt kein Fehler bei der SMTP-Sitzung auf, wenn in der Hub-zu-Hub-Kommunikation mit Authentifizierung durch das Kerberos-Protokoll kein gültiges internes Transportzertifikat vorliegt. Die SMTP-Sitzung wird mithilfe des temporären Verschlüsselungsschlüssels verschlüsselt. In diesem Fall wird ein Ereignis protokolliert, und Sie müssen durch Ausführen des Cmdlets New-ExchangeCertificate ohne Argumente auf dem Computer, der das Ereignis generiert hat, ein neues internes Transportzertifikat erstellen.

Bei der Hub-zu-Edge-Kommunikation mit einem bei der Organisation abonnierten Edge-Transport-Server tritt ein Fehler bei der Sitzung auf, und es wird ein Fehler im Protokoll aufgezeichnet, wenn kein gültiges internes Transportzertifikat gefunden wird. In diesem Fall müssen Sie das Cmdlet New-ExchangeCertificate ohne Argumente auf dem Computer ausführen, der das Ereignis generiert hat, und anschließend den Microsoft Exchange-EdgeSync-Dienst erneut ausführen.

POP3 und IMAP4

Wie auch beim Zertifikatauswahlprozess für SMTP STARTTLS, muss Exchange im Prozess für POP3 und IMAP4 einen FQDN auswählen und basierend auf einem passenden Wert im Feld CertificateDomains ein Zertifikat suchen. Der FQDN wird auf der Basis des Attributs X509CertificateName in den Einstellungen des POP3- oder IMAP4-Diensts ausgewählt. Sie können das Attribut X509CertificateName anzeigen, indem Sie das Cmdlet Get-POPSettings oder das Cmdlet Get-IMAPSettings ausführen. Weitere Informationen finden Sie unter Get-POPSettings und Get-IMAPSettings.

Der Auswahlprozess für POP3 und IMAP4 in Exchange 2007 SP1 ist gleich dem Prozess für SMTP STARTTLS.

Hinweis

In Exchange 2007 RTM bestehen zwei wichtige Ausnahmen im Zertifikatauswahlprozess für POP3 und IMAP4. Von einer vertrauenswürdigen Zertifizierungsstelle ausgestellte Zertifikate werden nicht gegenüber selbstsignierten Zertifikaten vorgezogen. Vielmehr wählt Exchange 2007 das neueste Zertifikat aus. Außerdem unterstützen in Exchange 2007 RTM POP3 und IMAP4 keine Platzhalterdomänen in Zertifikaten. Dies bedeutet, dass, wenn das Attribut X509CertificateName für die POP3-Einstellungen oder die IMAP4-Einstellungen auf mail.fourthcoffee.com festgelegt ist, Exchange 2007 ein Zertifikat nicht unterstützt, das nur *.fourthcoffee.com als Zertifikatdomäne enthält.

Unified Messaging

Wenn der Microsoft Exchange Unified Messaging-Dienst im sicheren Modus gestartet wird, sucht er im lokalen Zertifikatspeicher Persönlich nach einem gültigen Zertifikat für die Verwendung von TLS zum Aktivieren der Verschlüsselung. Der Microsoft Exchange Unified Messaging-Dienst sucht zuerst nach einem gültigen Zertifikat, das von einer privaten PKI oder einer öffentlichen Zertifizierungsstelle ausgestellt wurde. Wenn kein entsprechendes Zertifikat gefunden wird, sucht der Dienst nach einem selbstsignierten Zertifikat. Wenn weder ein PKI-Zertifikat noch ein öffentliches oder selbstsigniertes Zertifikat gefunden wird, erstellt der Microsoft Exchange Unified Messaging-Dienst ein selbstsigniertes Zertifikat, das für den Start im gesicherten Modus verwendet wird. Wenn der UM-Server im ungesicherten Modus gestartet wird, ist kein Zertifikat erforderlich.

Sämtliche Details des zum Starten im sicheren Modus verwendeten Zertifikats werden protokolliert, sobald ein Zertifikat verwendet oder geändert wird. Folgende Details werden beispielsweise protokolliert:

  • Name des Ausstellers

  • Seriennummer

  • Fingerabdruck

Beim Fingerabdruck handelt es sich um den SHA1-Hash (Secure Hash Algorithm). Er kann verwendet werden, um das verwendete Zertifikat eindeutig zu identifizieren. Sie können das vom Microsoft Exchange Unified Messaging-Dienst für das Starten im sicheren Modus verwendete Zertifikat aus dem lokalen Zertifikatspeicher exportieren und dieses Zertifikat in den vertrauenswürdigen Zertifikatspeicher auf den Unified Messaging-IP-Gateways und IP-Nebenstellenanlagen in Ihrem Netzwerk importieren.

Nachdem ein geeignetes Zertifikat gefunden und verwendet wurde, protokolliert der Microsoft Exchange Unified Messaging-Dienst einen Monat vor dem Ablaufen des verwendeten Zertifikats ein Ereignis. Wenn Sie das Zertifikat in dieser Zeit nicht ändern, trägt der Microsoft Exchange Unified Messaging-Dienst täglich ein Ereignis in das Protokoll ein, bis das Zertifikat abläuft, sowie an jedem Tag nach Ablauf des Zertifikats.

Wenn der Unified Messaging-Server ein Zertifikat zur Verwendung von MTLS für das Einrichten eines verschlüsselten Kanals benötigt, sucht er danach im vertrauenswürdigen Stammzertifikatspeicher. Wenn mehrere Zertifikate gültig sind und von unterschiedlichen Ausstellern stammen, wählt der Unified Messaging-Server das gültige Zertifikat mit der längsten Gültigkeitsdauer aus. Sind mehrere Zertifikate vorhanden, wählt der Unified Messaging-Server die Zertifikate basierend auf dem Aussteller und dem Ablaufdatum des Zertifikats aus. Der Unified Messaging-Server sucht in der folgenden Reihenfolge nach gültigen Zertifikaten:

  1. PKI- oder öffentliches Zertifikat mit dem längsten Ablaufzeitraum.

  2. PKI- oder kommerzielles Zertifikat mit dem kürzesten Ablaufzeitraum.

  3. Selbstsigniertes Zertifikat mit dem längsten Ablaufzeitraum.

  4. Selbstsigniertes Zertifikat mit dem kürzesten Ablaufzeitraum.

Return to top

Weitere Informationen

Auf die folgende Dokumentation wurde im Rahmen dieses Themas verwiesen:

Return to top