Unterstützung von Outlook Web Access mit dem S/MIME-Steuerelement in der PKI

  • Artikel

 

Letztes Änderungsdatum des Themas: 2006-09-11

In einem Nachrichtensicherheitssystem unter Exchange 2003 resultiert die S/MIME-Funktionaliät in erster Linie aus der Interaktion zwischen den E-Mail-Clients und der PKI. Als PKI-Administrator dient Ihnen die Dokumentation der eingesetzten PKI als wichtigste Quelle für Fragen zu Anforderungen und Konfiguration. Darüber hinaus sollten Sie den Administrator der E-Mail-Clients für Informationen zu den PKI-Anforderungen in Bezug auf die Unterstützung der eingesetzten Clients heranziehen.

Exchange 2003 stellt S/MIME-Funktionen für E-Mail-Clients mit Outlook Web Access unter Verwendung des S/MIME-Steuerelements bereit. In diesem Abschnitt finden PKI-Administratoren Informationen zur Integration ihrer PKI in Outlook Web Access unter Verwendung des S/MIME-Steuerelements.

Outlook Web Access und digitale Zertifikate

In diesem Abschnitt wird die Interaktion zwischen Outlook Web Access mit S/MIME-Steuerelement und digitalen Zertifikaten in den folgenden Bereichen ausführlicher erläutert:

  • Verarbeitung von Zertifikaten in Outlook Web Access mit S/MIME-Steuerelement
  • Outlook Web Access mit S/MIME-Steuerelement und Abrufen von digitalen Zertifikaten
  • Outlook Web Access mit S/MIME-Steuerelement und Überprüfen von Zertifikaten
  • Outlook Web Access mit S/MIME-Steuerelement und S/MIME-Vorgänge
  • Outlook Web Access mit S/MIME-Steuerelement und Smartcards
  • Outlook Web Access mit S/MIME-Steuerelement und S/MIME-Verschlüsselungsfunktionen

Verarbeitung von Zertifikaten in Outlook Web Access mit S/MIME-Steuerelement

Der Exchange-Server des Benutzers stellt die Zertifikatsüberprüfung für alle digitalen Zertifikate bereit. Bei Verwendung von Outlook Web Access mit S/MIME-Steuerelement führt der Exchange-Server des Benutzers gleichzeitig die wesentlichen Verarbeitungsschritte in Bezug auf öffentliche Schlüssel aus. Bei der Verarbeitung der Zertifikate in Bezug auf private Schlüssel des Benutzers erhält das S/MIME-Steuerelement jedoch das auf dem Client des Benutzers gespeicherte digitale Zertifikat.

Wenn der Exchange-Server des Benutzers alle Überprüfungsvorgänge der digitalen Zertifikate durchführt, wird der Umfang der notwendigen Datenübertragung zwischen Client und Exchange-Server reduziert. Dies führt zu einer verbesserten Leistung. Die Verwaltung der Zertifikate wird vereinfacht, da lediglich der Exchange-Server des Benutzers zur Unterstützung der Zertifikatsüberprüfung konfiguriert werden muss. Da der Client nur den Zertifikatspeicher zur Verfügung stellt, gibt es keine Anforderung zur Zertifikatsverarbeitung auf dem Client. Wenn der Client die digitalen Zertifikate mit dem privaten Schlüssel des Benutzers speichert, wird sichergestellt, dass der private Schlüssel des Benutzers niemals über das Netzwerk übertragen wird. Der private Schlüssel wird in diesem Fall nicht direkt von Outlook Web Access mit S/MIME-Steuerelement verarbeitet. Stattdessen erfolgt die Verarbeitung von privaten Schlüsseln durch das Betriebssystem. Outlook Web Access mit S/MIME-Steuerelement nutzt die Kryptografiefunktionen des Betriebssystems. In der folgenden Abbildung wird die Architektur von Outlook Web Access mit S/MIME-Steuerelement dargestellt.

e3fc5d17-8881-4073-a552-9fe22b043348

Wie aus der Abbildung ersichtlich, ist die Verarbeitung von Zertifikaten mit Outlook Web Access mit S/MIME-Steuerelement eine Folge von Vorgängen mit eindeutiger Eigentümerschaft. Der Exchange-Server des Benutzers führt alle Überprüfungen der Zertifikate durch und erhält die meisten digitalen Zertifikate für öffentliche Schlüssel, während der Client des Benutzers alle digitalen Zertifikate mit privaten Schlüsseln speichert.

Der Exchange-Server verlässt sich bei allen Verarbeitungsfunktionen auf den Zertifikatspeicher des zugrunde liegenden Betriebssystems. Dabei wird der persönliche Zertifikatspeicher des LocalSystem-Kontos auf dem Exchange-Server verwendet. Der persönliche Zertifikatspeicher ist der „Eigene Speicher“ der CryptoAPI im Benutzerprofil. Da Exchange 2003 entweder Microsoft Windows® 2000 Server oder Windows Server 2003 als Betriebssystem voraussetzt, die beide den persönlichen Zertifikatspeicher zur Verfügung stellen, gibt es keine weiteren Anforderungen an das Betriebssystem zur Unterstützung von Outlook Web Access mit S/MIME-Steuerelement auf dem Exchange-Server.

Für Outlook Web Access mit S/MIME-Steuerelement gelten folgende Systemanforderungen:

  • Windows 2000 oder höher (für Funktionen des persönlichen Zertifikatspeichers zum Speichern digitaler Zertifikate mit privaten Schlüsseln)
  • Internet Explorer 6 oder höher (zur Nutzung von Sicherheitserweiterungen)

Auch wenn Windows-Versionen vor Windows 2000 und andere Browser als Internet Explorer 6 oder höher nicht mit Outlook Web Access mit S/MIME-Steuerelement verwendet werden können, können diese mit Outlook Web Access ohne S/MIME-Steuerelement eingesetzt werden.

Outlook Web Access mit S/MIME-Steuerelement und Abrufen von digitalen Zertifikaten

Auch wenn für den Exchange-Server des Benutzers zur Überprüfung von Zertifikaten Windows 2000 oder höher erforderlich ist, können digitale Zertifikate nahezu aller öffentlichen Schlüssel abgerufen werden. Auf dem Clientsystem des Benutzers werden von Outlook Web Access mit S/MIME-Steuerelement digitale Zertifikate für private Schlüssel abgerufen.

Suchen von Zertifikaten mit Outlook Web Access mit S/MIME-Steuerelement

Bei der Verwendung von Outlook Web Access mit S/MIME-Steuerelement suchen Outlook und der Exchange-Server des Benutzers passende Zertifikate nach folgenden Kriterien:

  • Abgleichen der Routingadressen der E-Mail-Nachricht mit denen im Zertifikat   Der Exchange-Server des Benutzers oder Outlook Web Access mit S/MIME-Steuerelement versuchen, die Routingadressen der Nachricht eindeutig denen zuzuordnen, die im Zertifikat identifiziert wurden. Der Vorgang versucht, die Routingadressen der E-Mail-Nachricht denen des Zertifikatantragstellers eindeutig zuzuordnen. Wenn keine Übereinstimmung erzielt werden kann, wird versucht, die Routingadressen der Nachricht denen des alternativen Antragstellernamens zuzuordnen. Wenn keine Übereinstimmung mit den Routingadressen der E-Mail-Nachricht erzielt werden kann, wird versucht, die Routingadressen der Nachricht den Proxyadressen auf SMTP-Basis im Verzeichnis zuzuordnen. Die Suche nach SMTP-Proxyadressen kann durch Festlegen des Registrierungswerts CertMatchingDoNotUseProxies deaktiviert werden.

    noteAnmerkung:
    Weitere Informationen hierzu finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.

  • Ermitteln der Zertifikatseigenschaften   Wenn mehrere Zertifikate gefunden wurden, wird die Verwendung jedes Zertifikatsschlüssels zur Ermittlung der Zertifikatseigenschaften geprüft, sowohl digitale Signatur und/oder Nachrichtenverschlüsselung. Wenn ein Zertifikat nur eine Schlüsselverwendung aufweist und diese dem aktuellen Vorgang entspricht, wird dieses Zertifikat mit Vorrang vor Zertifikaten mit mehreren Schlüsselverwendungen gewählt. Wenn der aktuelle Vorgang beispielsweise eine digitale Signatur ist und zwei Zertifikate gefunden wurden, eines mit einer Verwendung ausschließlich für digitale Signaturen und ein anderes Zertifikat mit Verwendung für digitale Signaturen und Verschlüsselung, wird das Zertifikat mit der ausschließlichen Verwendung für digitale Signaturen gewählt.

  • Auswählen der Zertifikate nach Anfangs- und Ablaufdatum   Es werden ausschließlich in Bezug auf Anfangs- und Ablaufdatum gültige digitale Zertifikate ausgewählt.

  • Prüfen der von Smartcards übermittelten digitalen Zertifikate   Wenn der Wert SmartCardOnly auf dem Exchange-Server des Benutzers festgelegt ist, werden beim Abrufen der privaten Schlüssel des Benutzers lediglich die von Smartcards übermittelten digitalen Zertifikate geprüft.

    noteAnmerkung:
    Weitere Informationen hierzu finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.

Nach dem Erhalt eines digitalen Zertifikats wird die vollständige Vertrauensliste des Zertifikats überprüft.

Beziehen von digitalen Zertifikaten für öffentliche Schlüssel

Zum Überprüfen einer digitalen Signatur ruft das S/MIME-Steuerelement das in der signierten Nachricht enthaltene digitale Zertifikat ab und verwendet dieses Zertifikat für die Gültigkeitsprüfung.

Wenn Sie eine verschlüsselte Nachricht senden möchten und dafür ein digitales Zertifikat abrufen, um aus einem Verzeichnis den entsprechenden öffentlichen Schlüssel zu beziehen, durchsucht der Exchange-Server des Benutzers hintereinander die folgenden Orte, bis ein gültiges digitales Zertifikat für den angeforderten Vorgang gefunden wurde. Sobald ein gültiges Zertifikat gefunden ist, endet der Suchvorgang und dieses Zertifikat wird verwendet.

  • Das Attribut userCertificate im Active Directory-Objekt des anderen Benutzers
  • Das Attribut userSMIMECertificate im Active Directory-Objekt des anderen Benutzers
  • Das Attribut userCertificate im Active Directory-Kontaktobjekt des anderen Benutzers (auf dem Exchange-Server im Posteingang des Benutzers im Ordner Kontakte)
  • Das Attribut userSMIMECertificate im Active Directory-Kontaktobjekt des anderen Benutzers (auf dem Exchange-Server im Posteingang des Benutzers im Ordner Kontakte)
noteAnmerkung:
Obwohl Outlook Web Access ein digitales Zertifikat verwenden kann, das in Exchange einem Objekt im Ordner Kontakte angehängt ist, können Sie mit Outlook Web Access kein digitales Zertifikat zu einem Objekt im Ordner Kontakte hinzufügen. Sie müssen Outlook verwenden, um einem Kontakt ein digitales Zertifikat hinzuzufügen.

Wenn der Exchange-Server des Benutzers an keinem dieser Speicherorte ein Zertifikat für den öffentlichen Schlüssel des anderen Benutzers findet, wird eine Warnung ausgegeben. Beim Senden einer verschlüsselten E-Mail-Nachricht kann der Absender die Nachricht unverschlüsselt oder verschlüsselt senden. Im zweiten Fall erhält er eine Warnung, dass einige Benutzer die Nachricht möglicherweise nicht lesen können.

Beziehen von digitalen Zertifikaten für private Schlüssel eines Benutzers

Beim Auswählen eines digitalen Zertifikats, um den privaten Schlüssel des Benutzers zu beziehen, durchsucht Outlook Web Access mit S/MIME-Steuerelement den Speicher für persönliche Zertifikate des gerade angemeldeten Benutzers. Outlook Web Access mit S/MIME-Steuerelement durchsucht die verfügbaren Zertifikate im Zertifikatspeicher, bis ein gültiges digitales Zertifikat für den angeforderten Vorgang gefunden wurde. Outlook Web Access mit S/MIME-Steuerelement verwendet immer hardwarebasierte digitale Zertifikate (auch Smartcards), wenn sowohl ein softwarebasiertes als auch ein hardwarebasiertes Zertifikat gefunden wird. Wenn auf dem Exchange-Server des Benutzers der Wert SmartCardOnly gesetzt ist, werden nur von Smartcards übermittelte digitale Zertifikate untersucht.

Wenn Outlook Web Access mit S/MIME-Steuerelement kein Zertifikat für den privaten Schlüssel des Benutzers findet, wird eine Warnung ausgegeben. Beim Lesen einer verschlüsselten E-Mail-Nachricht kann der Empfänger die Nachricht nicht entschlüsseln oder anzeigen. Beim Senden einer signierten E-Mail-Nachricht wird in Outlook Web Access eine Warnmeldung angezeigt.

noteAnmerkung:
Bei der Verwendung hardwarebasierter Zertifikate müssen die Benutzer das entsprechende Gerät aktivieren, um das Zertifikat zur Verfügung zu stellen. Wenn Sie beispielsweise Smartcards verwenden, muss die Smartcard in ein Lesegerät eingeschoben und eine PIN (Persönliche Identifikationsnummer) eingegeben werden, bevor das Zertifikat verwendet werden kann.

Outlook Web Access mit S/MIME-Steuerelement und Zertifikatsüberprüfung

Zum Auswählen eines digitalen Zertifikats gehört auch die Ermittlung, ob ein verfügbares digitales Zertifikat gültig ist. Der Exchange-Server des Benutzers ist zum Ausführen von Zertifikatsüberprüfungen auf die Verarbeitungsfunktionen für Zertifikate des zugrunde liegenden Windows-Betriebssystems angewiesen. Eine ausführliche Übersicht über den Vorgang der Zertifikatsüberprüfung finden Sie unter Troubleshooting Certificate Status and Revocation. Der PKI-Administrator sollte im Hinblick auf Zertifikatsüberprüfungen in Outlook Web Access mit S/MIME-Steuerelement die folgenden Verfahren in Erwägung ziehen:

  • Gültigkeitszeitraumüberprüfung (wird für alle Zertifikate ausgeführt)
  • Überprüfung der Zertifikatssperrung (wird ausgeführt, wenn die Überprüfung der CRL (Certificate Revocation List, Zertifikatssperrliste) nicht über der Registrierungseinstellung DisableCRLCheck deaktiviert wurde)
  • Überprüfung der Vertrauenswürdigkeit (wird ausgeführt, wenn die Zertifizierungsstelle (Certification Authority, CA), die das Zertifikat ausgegeben hat, im Zertifikatspeicher des Systems, auf dem das Zertifikat abgerufen wurde, nicht vorhanden ist)

Gültigkeitszeitraumüberprüfung

Bei der Erstellung eines Zertifikats durch eine Zertifizierungsstelle wird das Zertifikat mit einem Gültigkeitszeitraum versehen. Der Gültigkeitszeitraum wird in den Zertifikatsattributen Gültig ab und Gültig bis angegeben. Zusammen bilden diese beiden Attribute ein Zeitfenster, in dem das Zertifikat gültig ist.

Wenn ein digitales Zertifikat abgerufen wird, überprüft der Exchange-Server des Benutzers, ob das aktuelle Datum in dem Zeitrahmen liegt, der durch die Attribute Gültig ab und Gültig bis festgelegt ist. Wenn das Zertifikat abgelaufen ist (das aktuelle Datum liegt nach dem Datum in Gültig bis) oder wenn das Zertifikat noch nicht gültig ist (das aktuelle Datum liegt vor dem Datum in Gültig ab) wird in Outlook Web Access eine Warnung angezeigt, dass das Zertifikat ungültig ist.

Überprüfen der Zertifikatssperrung

Eine CRL (Certificate Revocation List, Zertifikatssperrliste) ist eine Liste von Zertifikaten, die derzeit in Bezug auf den Gültigkeitszeitraum gültig sind, von der Zertifizierungsstelle jedoch als ungültig gekennzeichnet wurden. Von der Zertifizierungsstelle wird die Liste über CRL-Verteilungspunkte zur Verfügung gestellt. Ein CRL-Verteilungspunkt ist ein im digitalen Zertifikat angegebener Speicherort. Diese Liste kann von Systemen, die digitale Zertifikate dieser PKI überprüfen müssen, beispielsweise über HTTP oder LDAP (Lightweight Directory Access Protocol) bezogen werden.

Mit CRLs können PKI-Administratoren Zertifikate als ungültig kennzeichnen, bevor der Gültigkeitszeitraum abläuft. Dieser Widerruf wird vorgenommen, wenn das Zertifikat beeinträchtigt wurde (z. B. durch den Verlust oder die Bekanntgabe des privaten Schlüssels des Zertifikatsinhabers) oder wenn der Aussteller nicht länger für den Zertifikatsinhaber bürgen kann (z. B. durch Beendigung der Beschäftigung).

Entsprechend der X.509-Spezifikation kann jeder S/MIME-fähige E-Mail-Client ein digitales Zertifikat auf Widerruf überprüfen. Diese Überprüfung kann z. B. mit einer von der PKI ausgestellten CRL durchgeführt werden. Der Exchange-Server des Benutzers führt eine CRL-Prüfung mithilfe der Verschlüsselungsfunktionen des Betriebssystems ab Windows 2000 durch. In der Standardeinstellung ist für Outlook Web Access mit S/MIME-Steuerelement die CRL-Prüfung aktiviert, jedoch kann sie deaktiviert werden, indem der Wert DisableCRLCheck auf dem Exchange-Server des Benutzers auf True gesetzt wird. Weitere Informationen hierzu finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.

Da der Abrufvorgang einer CRL einige Zeit in Anspricht nehmen kann, wird die von der PKI abgerufene CRL von einem System nach dem Abruf zwischengespeichert, bis sie abgelaufen ist. Zusätzlich können Exchange-Administratoren durch die Registrierungseinstellungen RevocationURLRetrievalTimeout und CertURLRetrievalTimeout die Zeitdauer einstellen, die für das Abrufen von CRLs zur Verfügung steht, bevor ein Fehler zurückgegeben wird. Weitere Informationen hierzu finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.

Nachdem der Exchange-Server des Benutzers ein digitales Zertifikat bezogen und den Gültigkeitszeitraum überprüft hat, findet die folgende Abfolge statt.

  1. Der Exchange-Server überprüft das Zertifikat anhand der CRL. Der Exchange-Server des Benutzers überprüft, ob die CRL-Prüfung für dieses Zertifikat aktiviert ist.
  2. Wenn die CRL-Prüfung aktiviert ist, ruft der Exchange-Server eine zwischengespeicherte Kopie der CRL ab.
  3. Wenn keine zwischengespeicherte CRL gefunden werden kann, stellt der Exchange-Server eine Verbindung zum CRL-Verteilungspunkt her und bezieht eine aktuelle CRL.
  4. Wenn der Exchange-Server keine CRL beziehen kann, ist das weitere Vorgehen vom Registrierungsschlüssel CheckCRL abhängig. In der Standardeinstellung gibt Outlook Web Access keinen Fehler aus und lässt das Senden der Nachricht zu.
  5. Wenn die Registrierungseinstellung CheckCRL von der Standardeinstellung abweicht, gibt Outlook Web Access einen Fehler aus, lässt das Senden der Nachricht jedoch dennoch zu. Weitere Informationen über die Registrierungseinstellung CheckCRL finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.
  6. Wenn der Exchange-Server des Benutzers die CRL beziehen kann oder eine zwischengespeicherte Kopie der CRL findet, wird das aktuelle Zertifikat anhand der CRL geprüft.
    • Wenn das Zertifikat in der CRL vorhanden ist, wird es als ungültig markiert und nicht verwendet.
    • Wenn das Zertifikat in der CRL nicht vorhanden ist, wird es als gültig angenommen und verwendet.

Überprüfung der Vertrauenswürdigkeit

Die Überprüfung der Vertrauenswürdigkeit wird für alle Zertifikate durchgeführt. Zum Überprüfen des Zertifikats ruft der Exchange-Server des Benutzers die Verschlüsselungsfunktionen des Betriebssystems auf. Dabei werden alle Zertifikate der Zertifikatkette überprüft, bis ein vertrauenswürdiges Stammzertifikat erreicht wird. Normalerweise geschieht dies, indem mithilfe des Pfads im Zertifikat für den Zugriff auf die Stelleninformationen die Zwischenzertifikate bezogen werden, bis hin zum vertrauenswürdigen Stammzertifikat. Zwischenzertifikate können auch in digital signierten E-Mail-Nachrichten enthalten sein. Wenn das System ein vertrauenswürdiges Stammzertifikat erkennt, wird die Kette der digitalen Zertifikate für dieses digitale Zertifikat als gültig und vertrauenswürdig betrachtet und das Zertifikat kann verwendet werden.

Wenn das System kein vertrauenswürdiges Stammzertifikat findet oder wenn das ursprünglich bezogene digitale Zertifikat auf dem Exchange-Server im Zertifikatspeicher für nicht vertrauenswürdige Zertifikate zu finden ist, wird dieses Zertifikat als ungültig und nicht vertrauenswürdig betrachtet. Outlook Web Access mit S/MIME-Steuerelement gibt bei der Verwendung dieses nicht vertrauenswürdigen digitalen Zertifikats einen Fehler aus.

Als PKI-Administrator können Sie sich dafür entscheiden, von anderen PKIs ausgegebenen digitalen Zertifikaten zu vertrauen. Auf diese Wese vermeiden Sie Fehler, die beim Verwenden digitaler Zertifikate auftreten, die von PKIs ohne vertrauenswürdiges Stammzertifikat ausgegeben wurden. Sie können dem Stammzertifikat der anderen PKI vertrauen, jedoch wird dadurch jedem von dieser PKI ausgegebenen Zertifikat vertraut. Wahlweise können Sie sich auch für eine Strategie mit gegenseitiger Zertifizierung entscheiden und so nur ausgewählten Zertifikaten dieser PKI vertrauen.

Informationen über die Risiken und Vorteile der einzelnen Ansätze und darüber, wie Sie in Ihrer PKI eine gegenseitige Zertifizierung implementieren können, finden Sie in der PKI-Dokumentation. Weitere Informationen über gegenseitige Zertifizierung in Windows Server 2003 finden Sie im Dokument Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003. Im Allgemeinen wird eine Strategie mit gegenseitiger Zertifizierung empfohlen.

Unabhängig von der gewählten Strategie müssen Sie sicherstellen, dass auf dem Exchange-Server die entsprechenden Stammzertifikate verfügbar sind, um die Überprüfung der Vertrauenswürdigkeit zu ermöglichen. Diese Stammzertifikate können manuell hinzugefügt oder mit Gruppenrichtlinien übermittelt werden. Die Verwendung von Gruppenrichtlinien wird empfohlen.

Weitere Informationen über die Verwendung von Gruppenrichtlinien zur Übermittlung digitaler Zertifikate finden Sie in der Dokumentation von Windows Server 2003. Weitere Informationen über die erforderlichen Schritte zum manuellen Hinzufügen digitaler Zertifikate zum System des Benutzers finden Sie unter S/MIME-Problembehandlung in Exchange Server 2003.

Nachdem der Gültigkeitszeitraum eines digitalen Zertifikats anhand der CRL überprüft und die Vertrauenswürdigkeit bestätigt wurde, wird es vom Exchange-Server als gültiges Zertifikat anerkannt und kann für digitale Signaturen und Verschlüsselungen verwendet werden, je nach dem Verwendungszweck, für den das Zertifikat ausgegeben wurde.

Outlook Web Access mit S/MIME-Steuerelement und S/MIME-Vorgänge

In diesem Abschnitt werden die folgenden S/MIME-Vorgänge erläutert:

  • Digitale Signaturen in Outlook Web Access mit S/MIME-Steuerelement
  • Verschlüsselungsvorgänge in Outlook Web Access mit S/MIME-Steuerelement
  • Digitale Signaturen und Verschlüsselung in Outlook Web Access mit S/MIME-Steuerelement

Digitale Signaturen in Outlook Web Access mit S/MIME-Steuerelement

In diesem Abschnitt werden die folgenden Themen erläutert:

  • Senden einer digital signierten E-Mail-Nachricht
  • Überprüfen einer digital signierten E-Mail-Nachricht

Senden einer digital signierten E-Mail-Nachricht

Zum Senden einer digital signierten E-Mail-Nachricht muss Outlook Web Access den privaten Schlüssel des Absenders beziehen. Der Outlook Web Access ausführende Client (nicht der Exchange-Server des Benutzers) ist für das Beziehen des digitalen Zertifikats und des privaten Schlüssels zuständig.

noteAnmerkung:
In dieser Abfolge werden unverschlüsselt signierte Nachrichten beschrieben. Dabei handelt es sich um das Standardverhalten von Outlook Web Access mit S/MIME-Steuerelement. Dieses Verhalten wird auf dem Exchange-Server des Absenders mit der Registrierungseinstellung ClearSign gesteuert. Diese Option ist in der Standardeinstellung aktiviert. Weitere Informationen über die Registrierungseinstellung ClearSign finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.

Beim Senden einer digital signierten E-Mail-Nachricht findet die folgende Abfolge statt.

  1. Die Nachricht wird erfasst (durchgeführt vom Client).
  2. Der Hashwert der Nachricht wird mit dem im Schlüssel defaultSigningAlgorithms angegebenen Algorithmus berechnet (durchgeführt vom Client und vom Exchange-Server des Benutzers).
    Weitere Informationen über die Registrierungseinstellung defaultSigningAlgorithms finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.
  3. Der private Schlüssel aus dem digitalen Zertifikat des Absenders wird abgerufen (durchgeführt vom Client).
  4. Das digitale Zertifikat des Absenders wird überprüft (durchgeführt vom Exchange-Server des Benutzers).
  5. Der Hashwert wird mit dem privaten Schlüssel des Absenders verschlüsselt (durchgeführt vom Client und vom Exchange-Server des Benutzers).
  6. Der verschlüsselte Hashwert wird als digitale Signatur an die Nachricht angehängt (durchgeführt vom Client).
  7. Die Nachricht wird gesendet (durchgeführt vom Client).

Überprüfen einer digital signierten E-Mail-Nachricht

Zum Überprüfen einer digital signierten E-Mail-Nachricht muss Outlook Web Access den öffentlichen Schlüssel des Absenders beziehen. Der Exchange-Server des Empfängers ist für das Beziehen des digitalen Zertifikats und des öffentlichen Schlüssels zuständig.

Beim Überprüfen einer digital signierten E-Mail-Nachricht findet die folgende Abfolge statt.

  1. Die Nachricht wird empfangen (durchgeführt vom Exchange-Server des Benutzers).
  2. Die digitale Signatur, die den verschlüsselten Hashwert enthält, wird aus der Nachricht abgerufen (durchgeführt vom Client).
  3. Die Nachricht wird abgerufen (durchgeführt vom Client).
  4. Der Hashwert der Nachricht wird berechnet (durchgeführt vom Client und vom Exchange-Server des Benutzers).
  5. Der öffentliche Schlüssel des Absenders wird aus der E-Mail-Nachricht abgerufen (durchgeführt vom Client).
  6. Der verschlüsselte Hashwert wird mit dem öffentlichen Schlüssel des Absenders entschlüsselt (durchgeführt vom Client).
  7. Der entschlüsselte Hashwert wird mit dem beim Empfang erstellten Hashwert verglichen (durchgeführt vom Client).
  8. Wenn die Werte übereinstimmen, wurde die Nachricht während der Übertragung nicht verändert (durchgeführt vom Client).
  9. Das digitale Zertifikat des Absenders wird überprüft (durchgeführt vom Exchange-Server des Benutzers).
    noteAnmerkung:
    Die Nachricht wird während der Überprüfung des Zertifikats angezeigt, um den Umgang mit digital signierten E-Mail-Nachrichten beim Lesen zu erleichtern.

Verschlüsselungsvorgänge in Outlook Web Access mit S/MIME-Steuerelement

In diesem Abschnitt werden die folgenden Themen erläutert:

  • Senden einer verschlüsselten E-Mail-Nachricht.
  • Anzeigen einer verschlüsselten E-Mail-Nachricht.

Senden einer verschlüsselten E-Mail-Nachricht

Zum Senden einer verschlüsselten E-Mail-Nachricht muss Outlook Web Access den öffentlichen Schlüssel des Empfängers beziehen. Der Exchange-Server des Absenders ist für das Beziehen des digitalen Zertifikats und des öffentlichen Schlüssels zuständig.

Beim Senden einer verschlüsselten E-Mail-Nachricht findet die folgende Abfolge statt.

  1. Die Nachricht wird erfasst (durchgeführt vom Client).
  2. Der öffentliche Schlüssel wird aus dem digitalen Zertifikat des Empfängers abgerufen (durchgeführt vom Exchange-Server des Benutzers).
  3. Das digitale Zertifikat des Empfängers wird überprüft (durchgeführt vom Exchange-Server des Benutzers).
  4. Ein symmetrischer Sitzungsschlüssel zur einmaligen Verwendung wird erstellt (durchgeführt vom Client).
  5. Die Nachricht wird mit dem Sitzungsschlüssel verschlüsselt (durchgeführt vom Client).
  6. Der Sitzungsschlüssel wird mit dem öffentlichen Schlüssel des Empfängers verschlüsselt (durchgeführt vom Client).
  7. Der verschlüsselte Sitzungsschlüssel wird der verschlüsselten Nachricht hinzugefügt (durchgeführt vom Client).
  8. Die Nachricht wird gesendet (durchgeführt vom Client).

Anzeigen einer verschlüsselten E-Mail-Nachricht

Zum Anzeigen einer verschlüsselten E-Mail-Nachricht muss Outlook Web Access den privaten Schlüssel des Empfängers beziehen. Der Outlook Web Access ausführende Client (nicht der Exchange-Server des Benutzers) ist für das Beziehen des digitalen Zertifikats und des privaten Schlüssels zuständig.

Beim Anzeigen einer verschlüsselten E-Mail-Nachricht findet die folgende Abfolge statt.

  1. Die Nachricht wird empfangen (durchgeführt vom Exchange-Server des Benutzers).
  2. Die verschlüsselte Nachricht und der verschlüsselte Sitzungsschlüssel werden aus der Nachricht abgerufen (durchgeführt vom Client).
  3. Der private Schlüssel aus dem digitalen Zertifikat des Empfängers wird abgerufen (durchgeführt vom Client).
  4. Der Sitzungsschlüssel wird mit dem privaten Schlüssel aus dem digitalen Zertifikat des Empfängers entschlüsselt (durchgeführt vom Client).
  5. Die Nachricht wird mit dem entschlüsselten Sitzungsschlüssel entschlüsselt (durchgeführt vom Client).
  6. Die unverschlüsselte Nachricht wird an den Empfänger zurückgegeben (durchgeführt vom Client).

Digitale Signaturen und Verschlüsselung in Outlook Web Access mit S/MIME-Steuerelement

Es werden die folgenden Vorgänge untersucht:

  • Senden einer digital signierten und verschlüsselten E-Mail-Nachricht
  • Anzeigen einer digital signierten und verschlüsselten E-Mail-Nachricht

Senden einer digital signierten und verschlüsselten E-Mail-Nachricht

Zum Senden einer digital signierten und verschlüsselten E-Mail-Nachricht muss Outlook Web Access den privaten Schlüssel des Absenders und den öffentlichen Schlüssel des Empfängers beziehen. Der Outlook Web Access ausführende Client (nicht der Exchange-Server des Benutzers) bezieht das digitale Zertifikat und den privaten Schlüssel des Absenders. Der Exchange-Server des Absenders bezieht das digitale Zertifikat und den öffentlichen Schlüssel des Empfängers.

Beim Senden einer digital signierten und verschlüsselten E-Mail-Nachricht findet die folgende Abfolge statt.

noteAnmerkung:
In dieser Abfolge werden Nachrichten beschrieben, bei denen die Nachricht signiert, verschlüsselt und dann nochmals signiert wird. Dieser Vorgang wird als dreifache Verschlüsselung („triple wrapped“) bezeichnet. Dabei handelt es sich um das Standardverhalten von Outlook Web Access mit S/MIME-Steuerelement. Dieses Verhalten wird auf dem Exchange-Server des Absenders mit der Registrierungseinstellung TripleWrap gesteuert. Diese Option ist in der Standardeinstellung aktiviert. Weitere Informationen über die Registrierungseinstellung TripleWrap finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.
  1. Die Nachricht wird erfasst (durchgeführt vom Client).
  2. Der Hashwert der Nachricht wird berechnet (durchgeführt vom Client).
  3. Der private Schlüssel aus dem digitalen Zertifikat des Absenders wird abgerufen (durchgeführt vom Client).
  4. Das digitale Zertifikat des Absenders wird überprüft (durchgeführt vom Exchange-Server des Benutzers).
  5. Der öffentliche Schlüssel wird aus dem digitalen Zertifikat des Empfängers abgerufen (durchgeführt vom Exchange-Server des Benutzers).
  6. Das digitale Zertifikat des Empfängers wird überprüft (durchgeführt vom Exchange-Server des Benutzers).
  7. Der Hashwert wird mit dem privaten Schlüssel des Absenders verschlüsselt (durchgeführt vom Client).
  8. Der verschlüsselte Hashwert wird als digitale Signatur an die Nachricht angehängt (durchgeführt vom Client und vom Exchange-Server des Benutzers).
  9. Ein symmetrischer Sitzungsschlüssel zur einmaligen Verwendung wird erstellt (durchgeführt vom Client).
  10. Die Nachricht wird mit dem Sitzungsschlüssel verschlüsselt (durchgeführt vom Client).
  11. Der Sitzungsschlüssel wird mit dem öffentlichen Schlüssel des Empfängers verschlüsselt (durchgeführt vom Client).
  12. Der verschlüsselte Sitzungsschlüssel wird der verschlüsselten Nachricht hinzugefügt (durchgeführt vom Exchange-Server des Benutzers).
  13. Der Hashwert der Nachricht einschließlich des verschlüsselten Sitzungsschlüssels wird berechnet (durchgeführt vom Client).
  14. Der Hashwert wird mit dem privaten Schlüssel des Absenders verschlüsselt (durchgeführt vom Client).
  15. Der verschlüsselte Hashwert wird als digitale Signatur an die Nachricht angehängt (durchgeführt vom Client und vom Exchange-Server des Benutzers).
  16. Die Nachricht wird gesendet (durchgeführt vom Client).

Anzeigen einer digital signierten und verschlüsselten E-Mail-Nachricht

Zum Anzeigen einer digital signierten und verschlüsselten E-Mail-Nachricht muss Outlook Web Access den privaten Schlüssel des Empfängers (zum Anzeigen der Nachricht) und den öffentlichen Schlüssel des Absenders (zum Überprüfen der Signatur der Nachricht) beziehen. Der Outlook Web Access ausführende Client (nicht der Exchange-Server des Benutzers) bezieht das digitale Zertifikat und den privaten Schlüssel des Empfängers. Der Exchange-Server des Benutzers bezieht das digitale Zertifikat und den öffentlichen Schlüssel des Absenders.

Beim Senden einer digital signierten und verschlüsselten E-Mail-Nachricht findet die folgende Abfolge statt.

noteAnmerkung:
In dieser Abfolge werden dreifach verschlüsselte („triple wrapped“) Nachrichten beschrieben. Dabei handelt es sich um das Standardverhalten von Outlook Web Access mit S/MIME-Steuerelement. Dieses Verhalten wird auf dem Exchange-Server des Absenders mit der Registrierungseinstellung TripleWrap gesteuert. Diese Option ist in der Standardeinstellung aktiviert. Weitere Informationen über die Registrierungseinstellung TripleWrap finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.
  1. Die Nachricht wird empfangen (durchgeführt vom Exchange-Server des Benutzers).
  2. Die digitale Signatur, die den verschlüsselten Hashwert der Nachricht mit dem verschlüsselten Sitzungsschlüssel enthält, wird aus der Nachricht abgerufen (durchgeführt vom Client).
  3. Die Nachricht und der verschlüsselte Sitzungsschlüssel werden aus der Nachricht abgerufen (durchgeführt vom Client).
  4. Der Hashwert der Nachricht und der verschlüsselte Sitzungsschlüssel werden berechnet (durchgeführt vom Client).
  5. Der öffentliche Schlüssel des Absenders wird aus der Nachricht abgerufen (durchgeführt vom Exchange-Server des Benutzers).
  6. Der verschlüsselte Hashwert der Nachricht mit dem verschlüsselten Sitzungsschlüssel wird mit dem öffentlichen Schlüssel des Absenders entschlüsselt (durchgeführt vom Client).
  7. Der entschlüsselte Hashwert der Nachricht mit dem verschlüsselten Sitzungsschlüssel wird mit dem beim Empfang erzeugten Hashwert der Nachricht mit dem verschlüsselten Sitzungsschlüssel verglichen (durchgeführt vom Client).
  8. Wenn die Werte übereinstimmen, wurde die Nachricht während der Übertragung nicht verändert (durchgeführt vom Client).
  9. Die verschlüsselte Nachricht und der verschlüsselte Sitzungsschlüssel werden aus der Nachricht abgerufen (durchgeführt vom Client).
  10. Der private Schlüssel aus dem digitalen Zertifikat des Empfängers wird abgerufen (durchgeführt vom Client).
  11. Der Sitzungsschlüssel wird mit dem privaten Schlüssel aus dem digitalen Zertifikat des Empfängers entschlüsselt (durchgeführt vom Client).
  12. Die Nachricht wird mit dem entschlüsselten Sitzungsschlüssel entschlüsselt (durchgeführt vom Client).
  13. Die digitale Signatur, die den verschlüsselten Hashwert enthält, wird aus der Nachricht abgerufen (durchgeführt vom Client).
  14. Der Hashwert der Nachricht wird berechnet (durchgeführt vom Client).
  15. Der verschlüsselte Hashwert wird mit dem öffentlichen Schlüssel des Absenders entschlüsselt (durchgeführt vom Client).
  16. Der entschlüsselte Hashwert wird mit dem beim Empfang erstellten Hashwert verglichen (durchgeführt vom Client).
  17. Wenn die Werte übereinstimmen, wurde die Nachricht während der Übertragung nicht verändert (durchgeführt vom Client).
  18. Die unverschlüsselte Nachricht wird an den Empfänger zurückgegeben (durchgeführt vom Client).
  19. Das digitale Zertifikat des Absenders wird überprüft (durchgeführt vom Exchange-Server des Benutzers).
noteAnmerkung:
Die Nachricht wird während der Überprüfung des Zertifikats angezeigt, um den Umgang mit digital signierten E-Mail-Nachrichten beim Lesen zu erleichtern.

Outlook Web Access mit S/MIME-Steuerelement und Smartcards

PKI-Administratoren können in Outlook Web Access mit S/MIME-Steuerelement auf Smartcards digitale Benutzerzertifikate und private Schlüssel speichern. Auf Systemen mit mehreren Clients werden Smartcards von Outlook Web Access mit S/MIME-Steuerelement bevorzugt.

Da Outlook Web Access mit S/MIME-Steuerelement auf einem Betriebssystem ab Windows 2000 aufbaut, ist die Unterstützung digitaler Zertifikate auf Smartcards direkt von der Unterstützung durch das Betriebssystem abhängig. Wenn Sie in Ihrer PKI die Unterstützung von Smartcards implementieren möchten, finden Sie entsprechende Informationen in der Dokumentation von Windows 2000 (oder höher). Die folgenden Informationen beziehen sich speziell auf die Integration der Smartcard-Unterstützung in Outlook Web Access mit S/MIME-Steuerelement. Durch diese Informationen werden Ihre PKI-Dokumentation und die Dokumentation von Windows 2000 (oder höher) erweitert.

Funktionsweise der Smartcard-Unterstützung von Outlook Web Access mit S/MIME-Steuerelement

Die Unterstützung für Smartcards von Outlook Web Access mit S/MIME-Steuerelement wird von dem Betriebssystem bereitgestellt, auf dem der Client aufgeführt wird. Das Betriebssystem integriert Smartcards nahtlos in die Verarbeitungsfunktionen für Zertifikate, sodass Outlook Web Access diese Zertifikate nicht verarbeiten oder verwalten muss. Outlook Web Access mit S/MIME-Steuerelement überwacht die Smartcard auf Änderungen, weist das Betriebssystem an, wenn zusätzliche digitale Zertifikate von der Smartcard in den Speicher für persönliche Zertifikate zu verschieben sind, und entfernt diese Zertifikate, wenn der Benutzer sich von Outlook Web Access abmeldet.

Über Smartcards werden digitale Zertifikate zur Verfügung gestellt, indem das Zertifikat beim Einlegen einer Smartcard in den Speicher für persönliche Zertifikate kopiert wird, sobald das digitale Zertifikat mit dem privaten Schlüssel des Benutzers freigegeben wird. Dadurch wird das digitale Zertifikat am selben Speicherort gespeichert wie bei der Verwendung von softwarebasierten Zertifikaten. Anwendungen müssen zum Verwenden von Smartcard-basierten digitalen Zertifikaten keine besonderen Vorgänge durchführen, da das Windows-Betriebssystem für alle Vorgänge im Umgang mit Smartcard-basierten Zertifikaten zuständig ist.

Stellen Sie bei der Verwendung von Smartcards mit Outlook Web Access sicher, dass die ausgegebenen digitalen Zertifikate, je nach den Anforderungen Ihrer Implementierung, Funktionen für die digitale Signatur und Verschlüsselung bieten.

Sie können Outlook Web Access mit S/MIME-Steuerelement so konfigurieren, dass nur Smartcard-basierte digitale Zertifikate anerkannt werden, indem Sie auf dem Exchange-Server des Benutzers die Registrierungseinstellung SmartCardOnly setzen. Diese Option ist in der Standardeinstellung deaktiviert. Weitere Informationen über die Registrierungseinstellung SmartCardOnly finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.

Unterstützung von Terminaldiensten

Der im Lieferumfang von Windows Server 2003 enthaltene Remotedesktopclient unterstützt die Umleitung von Smartcards. Mit dem Remotedesktopclient von Windows Server 2003 können Smartcards, die in einen am Remotedesktopclient (z. B. einem Kiosk) angeschlossenen Kartenleser eingelegt werden, in der Terminalsitzung verwendet werden.

Mit der Umleitung von Smartcards in Outlook Web Access mit S/MIME-Steuerelement können Sie Benutzern einer Terminalsitzung die Verwendung Smartcard-basierter Zertifikate ermöglichen.

Der Remotedesktopclient von Windows Server 2003 unterliegt einigen Einschränkungen bezüglich der Kombinationen von Clients und Servern, bei denen die Umleitung von Smartcards verwendet werden kann. In Tabelle 6.1 werden die unterstützten Kombinationen von Clients und Servern für die Umleitung von Smartcards bei Verwendung des Remotedesktopclients von Windows Server 2003 aufgeführt.

Tabelle 6.1   Unterstützte Plattformen von Clients und Servern zur Umleitung von Smartcards bei Verwendung des Windows Server 2003-Remotedesktopclients

Windows Server 2003-Remotedesktop ausführendes Clientsystem Remotedesktopdienste ausführendes Serversystem

Windows XP

Windows XP-Remotedesktop

Windows XP

Windows Server 2003

Windows 2000

Windows XP-Remotedesktop

Windows 2000

Windows Server 2003

Windows Server 2003

Windows XP-Remotedesktop

Windows Server 2003

Windows Server 2003

Wie in der Tabelle dargestellt, muss der Server, der Terminal Services bereitstellt, Windows XP oder Windows Server 2003 sein. Windows 2000, Windows XP, und Windows Server 2003 können alle als Clientplattformen zum Ausführen von Windows Server 2003 Remote Desktop verwendet werden. Andere Windows-Versionen können mit dem Remotedesktopclient von Windows Server 2003 keine Umleitung von Smartcards zur Verfügung stellen. Weitere Informationen über die Umleitung von Smartcards finden Sie in der Dokumentation zu Windows 2003 Server.

Outlook Web Access mit S/MIME-Steuerelement und S/MIME-Verschlüsselungsfunktionen

Wenn Sie Outlook Web Access mit S/MIME-Steuerelement verwenden, können Sie Benutzer dazu zwingen, E-Mail-Nachrichten mit einem festgelegten Verschlüsselungsalgorithmus zu verschlüsseln. Anstatt nur auf die im Verschlüsselungszertifikat des Benutzers einzeln aufgeführten S/MIME-Verschlüsselungsfunktionen angewiesen zu sein, überprüft Outlook Web Access mit S/MIME-Steuerelement Informationen in der Registrierung auf dem Exchange-Server des Absenders, um festzulegen, welcher Verschlüsselungsalgorithmus und welche Tiefe verwendet werden sollen. Mit dieser Funktion können Sie die genauen Richtlinien der Organisation in Bezug auf Verschlüsselung von E-Mail-Nachrichten durchsetzen. Mit der Registrierungseinstellung EncryptionAlgorithms wird die Auswahl der Verschlüsselungsalgorithmen geregelt. Weitere Informationen über die Registrierungseinstellung EncryptionAlgorithms finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.

Wenn der Exchange-Server des Absenders nicht in der Lage ist, ein Verschlüsselungszertifikat für einen Empfänger zu beziehen, dessen Funktionen den in der Registrierung eingestellten Anforderungen entsprechen, verarbeitet Outlook Web Access mit S/MIME-Steuerelement die Nachricht entsprechend der Registrierungseinstellung AlwaysEncrypt. Wenn AlwaysEncrypt deaktiviert ist (die Standardeinstellung), kann der Absender die Nachricht unverschlüsselt an diesen Empfänger senden. Wenn AlwaysEncrypt aktiviert ist, kann der Absender die Nachricht nicht senden. Weitere Informationen über die Registrierungseinstellung AlwaysEncrypt finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement. Wenn Outlook Web Access mit S/MIME-Steuerelement ein Verschlüsselungszertifikat für einen Empfänger findet, das den vorgeschriebenen Algorithmus nicht oder nicht im vorgeschriebenen Verschlüsselungsgrad unterstützt, wird fortgefahren, als ob kein Zertifikat gefunden wurde. Die Nachricht wird entsprechend der Einstellung AlwaysEncrypt verarbeitet.

Unterstützen von S/MIME-Nachrichten aus anderen Organisationen

Wenn Sie Outlook Web Access mit S/MIME-Steuerelement zum Austausch von S/MIME-E-Mail-Nachrichten mit den Benutzern anderer Organisationen verwenden, führt der Exchange-Server des Benutzers die Gültigkeitsprüfung der Zertifizierung von S/MIME-Nachrichten stellvertretend für den Benutzer durch. Zum erfolgreichen Überprüfen von S/MIME-Nachrichten aus anderen Organisationen muss der Exchange-Server des Benutzers die gesamte Zertifikatkette bis zu einem vertrauenswürdigen Stammzertifikat überprüfen. Wenn Sie die Verwendung von S/MIME für den Austausch von E-Mail-Nachrichten mit anderen Organisationen planen und mit den Zertifikaten einer anderen Organisation eine digitale Signatur überprüfen möchten, müssen Sie in Ihrer PKI Vertrauensstellungen mit den Zertifikaten der anderen Organisation implementieren.

Exchange 2003 vertraut dem Zertifikat, wenn das Stammzertifikat des Ausstellers vertrauenswürdig ist oder durch einen Prozess mit PKI übergreifender Zertifizierung. Der Exchange-Administrator kann die Vertrauenswürdigkeit für das Stammzertifikat des Ausstellers aktivieren, indem er auf dem Exchange-Server des Benutzers im lokalen Zertifikatspeicher dieses Stammzertifikat dem Ordner Vertrauenswürdige Stammzertifizierungsstellen hinzufügt. Beraten Sie sich zur Umsetzung dieses Vorgangs mit dem Exchange-Administrator. Weitere Informationen, einschließlich schrittweisen Anweisungen zum Importieren eines gegenseitig zertifizierten Zertifikats, finden Sie unter Digitale Signaturen des Absenders können nicht überprüft werden, wenn das digitale Zertifikat der Stammzertifizierungsstelle des Absenders nicht auf dem lokalen Computer im Zertifikatspeicher des Exchange-Servers des Empfängers verfügbar ist.

Sie können dieses Problem durch Hinzufügen des Stammzertifikats des Ausstellers beheben, dadurch werden jedoch alle von dieser PKI ausgestellten Zertifikate implizit als vertrauenswürdig eingestuft. Eine solche Vertrauensstufe widerspricht möglicherweise der Sicherheitsrichtlinie Ihrer Organisation. Eine andere Möglichkeit besteht darin, nur die akzeptablen Zertifikate der PKI der anderen Organisation übergreifend zu zertifizieren, indem Sie auf dem Exchange-Server des Benutzers im lokalen Zertifikatspeicher dieses Zertifikat dem Ordner für eigene vertrauenswürdige Zertifikate hinzufügen.

Weitere Informationen zur Implementierung übergreifender Zertifizierung finden Sie in der Dokumentation Ihrer PKI. Weitere Informationen über das Implementieren gegenseitiger Zertifizierung in Windows Server 2003 finden Sie im Dokument „Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003“ (https://go.microsoft.com/fwlink/?LinkId=17806).

Der Exchange-Server eines Benutzers muss nicht nur dem Stammzertifikat des Ausstellers eines Zertifikats vertrauen, sondern auch auf alle Zwischenzertifikate zugreifen und diese erfolgreich überprüfen. Abhängig davon, wie der PKI-Administrator der anderen Organisation die PKI konfiguriert hat, können diese Zwischenzertifikate möglicherweise in signierten E-Mail-Nachrichten enthalten sein, oder sie sind an einem Speicherort zugänglich, der im Parameter eines Zertifikats für den Zugriff auf die Stelleninformationen angegeben ist. Um Zugriff auf Zwischenzertifikate zu ermöglichen, muss der Exchange-Administrator sicherstellen, dass der Exchange-Server des Benutzers erfolgreich eine Verbindung herstellen und Zertifikate abrufen kann, die durch den Parameter eines Zertifikats für den Zugriff auf die Stelleninformationen zur Verfügung stehen. Um die Gültigkeitsprüfung von Zwischenzertifikaten zu ermöglichen, muss der Exchange-Administrator sicherstellen, dass der Exchange-Server des Benutzers erfolgreich eine Verbindung zum CRL-Verteilungspunkt herstellen und überprüfen kann, ob die CRL im digitalen Zertifikat angegeben ist. Damit der Exchange-Server eines Benutzers auf Zwischenzertifikate zugreifen und diese erfolgreich überprüfen kann, muss der Exchange-Administrator die Verbindungen zwischen dem Exchange-Server des Benutzers und den Speicherorten sicherstellen, die in den Parametern des digitalen Zertifikats für die CRL-Verteilungspunkte und den Zugriff auf Stelleninformationen angegeben sind. In den meisten Organisationen findet dieser Vorgang auf einem Proxyserver zwischen den Exchange-Servern und dem Internet statt. Der Exchange-Administrator muss sicherstellen, dass die entsprechende Proxysoftware für den Client installiert und konfiguriert ist. Wenn Sie für die Gültigkeitsprüfung nicht auf Zwischenzertifikate zugreifen können, kann der Exchange-Administrator die CRL-Prüfung mit dem Registrierungsschlüssel disableCRLCheck deaktivieren. Weitere Informationen zu dieser Einstellung finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.

Weitere Informationen für den Exchange-Administrator finden Sie unter „Konfigurieren von Exchange-Servern“ in Implementieren von Outlook Web Access mit dem S/MIME-Steuerelement.

Konfigurieren der Verarbeitung von Zwischenzertifikaten in Ihrer PKI

In der Standardeinstellung enthalten E-Mail-Nachrichten, die mit Outlook Web Access mit S/MIME-Steuerelement gesendet werden, nur die Signatur- und Verschlüsselungszertifikate der Nachricht. Das Stammzertifikat und die Zwischenzertifikate sind nicht enthalten. Sie können diese Einstellung mit dem Registrierungsschlüssel SecurityFlags konfigurieren. Weitere Informationen zu dieser Einstellung finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.

In der Standardeinstellung sendet Outlook Web Access mit S/MIME-Steuerelement nur die Signatur- und Verschlüsselungszertifikate. Daher wird empfohlen, in Ihrer PKI den Parameter des Zertifikats für den Zugriff auf die Stelleninformationen zu verwenden und Ihre Zwischenzertifikate über LDAP oder HTTP öffentlich zur Verfügung zu stellen. Weitere Informationen über die Verwendung dieser Funktion finden Sie in der Dokumentation Ihrer PKI.

Wenn Sie Zwischenzertifikate nicht über den Zugriff auf Stelleninformationen zur Verfügung stellen können, sollten Sie Outlook Web Access mit S/MIME-Steuerelement so konfigurieren, dass die Zwischenzertifikate in E-Mail-Nachrichten enthalten sind. Beraten Sie sich bezüglich der erforderlichen Änderungen mit dem Exchange-Administrator. Weitere Informationen über die Konfiguration des Registrierungsschlüssels SecurityFlags finden Sie unter Einstellungen im Zusammenhang mit dem Outlook Web Access-S/MIME-Steuerelement.