Verwalten von S/MIME für Outlook Web App
Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Letztes Änderungsdatum des Themas: 2016-11-28
Sie können die Registrierung auf einem Microsoft Exchange Server 2010-Clientzugriffsserver so konfigurieren, dass Sie das Verhalten von Secure/Multipurpose Internet Mail Extensions (S/MIME) für Outlook Web App verwalten können.
Sie können die Registrierung auf einem Servercomputer mit Exchange 2010 ändern, auf dem die Clientzugriffs-Serverrolle installiert ist, um das Verhalten von S/MIME in Outlook Web App zu steuern. Diese Änderungen werden für jeden Server vorgenommen. Wenn Sie mehrere Clientzugriffsserver verwenden und das gleiche S/MIME-Verhalten auf allen Clientzugriffsservern benötigen, müssen Sie auf jedem Server die gleichen Änderungen vornehmen. Änderungen an den S/MIME-Einstellungen in der Registrierung werden sofort wirksam und wirken sich auf die Outlook Web App-Benutzer bei ihrer nächsten Aktion aus, bei der das S/MIME-Steuerelement verwendet wird. Die Benutzer müssen nicht gezwungen werden, sich abzumelden oder Dienste neu zu starten.
Möchten Sie wissen, welche anderen Verwaltungsaufgaben es im Zusammenhang mit der Outlook Web App-Sicherheit gibt? Weitere Informationen finden Sie hier: Verwalten der Sicherheit von Outlook Web App.
Voraussetzungen
Wenn Sie mit der Verwaltung von PKIs (Public-Key-Infrastruktur) und Zertifikaten nicht vertraut sind, sollten Sie zunächst unter Active Directory-Zertifikatdienste und Verwaltung öffentlicher Schlüssel (möglicherweise in englischer Sprache) nachlesen.
S/MIME-Steuerungseinstellungen
Die folgenden Tabellen listen die Namen, die möglichen Werte, die Standardeinstellungen und das Verhalten der Registrierungseinstellungen auf, die Sie zum Steuern des Verhaltens des S/MIME-Steuerelements in Outlook Web App verwenden können.
Überprüfen der Zertifikatsperrliste beim Senden
Exchange 2010-Wertname und -typ |
CheckCRLOnSend (DWORD) |
Exchange 2007-Wertname und -typ |
CheckCRLOnSend (DWORD) |
Exchange 2003-Wertname und -typ |
CheckCRL (DWORD) |
Werte und Standardeinstellungen |
1 = True, 0 = False (Standard) |
Erklärung |
Wenn beim Senden einer signierten oder verschlüsselten E-Mail-Nachricht während der Überprüfung auf Sperren auf einen Verteilungspunkt für Zertifikatssperrlisten (Certificate Revocation List, CRL) in der Zertifikatkette nicht zugegriffen werden kann, weist Outlook Web App standardmäßig in einem Dialogfeld darauf hin, dass das Zertifikat nicht überprüft werden kann. Die E-Mail-Nachricht kann jedoch gesendet werden. Wenn CheckCRLonSend auf "true" festgelegt ist und beim Senden einer signierten oder verschlüsselten E-Mail-Nachricht während der Überprüfung auf Sperren kein Zugriff auf einen CRL-Verteilungspunkt in der Zertifikatkette möglich ist, gibt Outlook Web App einen Fehler aus und verhindert, dass die E-Mail-Nachricht gesendet wird. |
Timeout bei der Aufgliederung der Verteilerliste
Exchange 2010-Wertname und -typ |
DLExpansionTimeout (DWORD) |
Exchange 2007-Wertname und -typ |
DLExpansionTimeout (DWORD) |
Exchange 2003-Wertname und -typ |
DLExpansionTimeout (DWORD) |
Werte und Standardeinstellungen |
Das Timeout bei der Aufgliederung der Verteilerliste gibt die Zeitdauer in Millisekunden an, bevor eine Anforderung zur Aufgliederung einer Verteilerliste mit einem Timeout beendet wird. Der Standardwert ist 60000 (60 Sekunden). Der Mindestwert ist 0. Wenn Sie DLExpansionTimeout auf 0 festlegen, können keine verschlüsselten E-Mail-Nachrichten an Verteilerlisten gesendet werden. Der Höchstwert ist 2.147.483.647. Wenn DLExpansionTimeout auf den Höchstwert festgelegt wird, gibt es kein Timeout für die Aufgliederung von Verteilerlisten und Outlook Web App wartet unabhängig von der Dauer der Aufgliederung, bis die Verteilerliste aufgegliedert wurde. |
Erklärung |
Über dieses Attribut wird festgelegt, wie lange (in Millisekunden) Outlook Web App beim Senden einer verschlüsselten E-Mail-Nachricht wartet, bis eine Verteilerliste in Active Directory aufgegliedert wurde, bevor der Vorgang fehlschlägt. Wenn verschlüsselte E-Mail-Nachrichten an eine Verteilerliste gesendet werden, muss Outlook Web App die Verteilerliste aufgliedern, um das Verschlüsselungszertifikat der einzelnen Empfänger für den Verschlüsselungsvorgang abzurufen. Die dafür erforderliche Zeit hängt von der Größe der Verteilerliste und der Leistung der zugrunde liegenden Active Directory-Infrastruktur ab. Während der Erweiterung der Verteilerliste erhält der Absender keine Rückmeldung von Outlook Web App. Über dieses Attribut wird festgelegt, wie lange Outlook Web App auf die Aufgliederung der gesamten Verteilerliste wartet. Wird der Vorgang nicht innerhalb der durch diesen Wert angegebenen Zeit abgeschlossen, schlägt der Vorgang fehl und die E-Mail-Nachricht wird nicht gesendet. Der Absender gelangt zum Entwurfsformular zurück, das eine Informationsleiste mit der folgenden Fehlermeldung enthält: Die Aktion konnte nicht abgeschlossen werden. Versuchen Sie es erneut. Wenden Sie sich an den technischen Support für Ihre Organisation, wenn das Problem weiterhin besteht. |
Verwenden sekundärer Proxys beim Suchen nach Zertifikaten
Exchange 2010-Wertname und -typ |
UseSecondaryProxiesWhenFindingCertificates (DWORD) |
Exchange 2007-Wertname und -typ |
UseSecondaryProxiesWhenFindingCertificates (DWORD) |
Exchange 2003-Wertname und -typ |
CertMatchingDoNotUseProxies (DWORD) |
Werte und Standardeinstellungen |
1 = True (Standard), 0 = False |
Erklärung |
Beim Senden von verschlüsselten E-Mail-Nachrichten versucht Outlook Web App, in Active Directory das richtige Zertifikat für den Empfänger zu finden. Die Werte für den Inhaber des Zertifikats oder für alternative Namen können eine SMTP-Adresse (Simple Mail Transfer Protocol) als Wert enthalten. Da ein Empfänger über mehrere SMTP-Proxyadressen im Verzeichnis verfügen kann, stimmen der Antragsteller des Zertifikats oder die alternativen Namen ggf. nicht mit der primären SMTP-Adresse überein. Möglicherweise stimmen sie stattdessen mit einer der Proxyadressen überein. Wenn UseSecondaryProxiesWhenFindingCertificates auf "true" festgelegt ist, akzeptiert Outlook Web App Zertifikate, die nicht mit der primären SMTP-Adresse des Empfängers übereinstimmen. Wenn UseSecondaryProxiesWhenFindingCertificates auf "false" festgelegt ist, akzeptiert Outlook Web App nur die Zertifikate, die mit der primären SMTP-Adresse des Empfängers übereinstimmen. |
CRL-Verbindungstimeout
Exchange 2010-Wertname und -typ |
CRLConnectionTimeout (DWORD) |
Exchange 2007-Wertname und -typ |
CRLConnectionTimeout (DWORD) |
Exchange 2003-Wertname und -typ |
RevocationURLRetrievalTimeout (DWORD) |
Werte und Standardeinstellungen |
Das CRL-Verbindungstimeout gibt die Zeit in Millisekunden an, nach der eine CRL-Verbindungsanforderung mit einem Timeout beendet wird. Der Standardwert ist 60000 (60 Sekunden). Der Mindestwert ist 5.000 (5 Sekunden). Es kann ein Höchstwert von 2.147.483.647 angegeben werden. Wenn CRLConnectionTimeout auf den Höchstwert festgelegt ist, findet kein Timeout der Verbindung statt. |
Erklärung |
Das CRL-Verbindungstimeout gibt die Zeit in Millisekunden an, die Outlook Web App beim Herstellen einer Verbindung wartet, um bei einer Zertifikatsüberprüfung eine einzelne Zertifikatsperrliste (CRL) abzurufen. Zum Überprüfen eines Zertifikats muss die CRL der Zertifizierungsstelle (CA) von einem CRL-Verteilungspunkt abgerufen werden, der im Zertifikat angegeben ist. Dieser Vorgang muss für jedes Zertifikat in der gesamten Zertifikatkette vorgenommen werden. Wenn mehrere CRLs abgerufen werden müssen, gilt dieser Schlüssel für jede Verbindung. Wenn beispielsweise drei CRLs abgerufen werden sollen und CRLConnectionTimeout auf 60 Sekunden festgelegt ist, gilt für jeden CRL-Abruf ein Timeoutgrenzwert von 60 Sekunden. Wenn die CRL nicht innerhalb des angegebenen Timeoutgrenzwerts abgerufen werden kann, schlägt der Vorgang fehl. Wenn für CRLConnectionTimeout ein Wert von weniger als 5.000 festgelegt ist, wird der Standardwert (60.000) verwendet. Wenn für CRLConnectionTimeout der Höchstwert (2.147.483.647) festgelegt ist, findet kein Timeout der Verbindung statt. |
CRL-Abruftimeout
Exchange 2010-Wertname und -typ |
CRLRetrievalTimeout (DWORD) |
Exchange 2007-Wertname und -typ |
CRLRetrievalTimeout (DWORD) |
Exchange 2003-Wertname und -typ |
CertURLRetrievalTimeout (DWORD) |
Werte und Standardeinstellungen |
Das CRL-Abruftimeout gibt die Zeit in Millisekunden an, die Outlook Web App beim Herstellen der Verbindung wartet, um alle CRL-Abrufvorgänge für eine einzelne Nachricht auszuführen. Der Standardwert ist 10.000 (10 Sekunden). Der Mindestwert ist 0, der Höchstwert 2.147.483.647. |
Erklärung |
Dieses Attribut ähnelt dem CRL-Verbindungstimeout. Hier wird jedoch die Zeit in Millisekunden festgelegt, die Outlook Web App beim Herstellen der Verbindung wartet, um für die Überprüfung des Zertifikats alle CRLs abzurufen. Wenn nicht alle CRLs innerhalb des angegebenen Timeoutgrenzwerts abgerufen werden können, schlägt der Vorgang fehl. Für die Einstellung dieses Werts ist es wichtig, dass bei einer Zertifikatsüberprüfung das CRL-Verbindungstimeout für jeden einzelnen CRL-Abrufvorgang sowie für den gesamten Abrufvorgang aller CRLs gilt. Wenn beispielsweise drei CRLs abgerufen werden müssen und der Wert CRLConnectionTimeout auf 60 Sekunden und der Wert CRLRetrievalTimeout auf 120 Sekunden festgelegt ist, gilt für jeden einzelnen CRL-Abrufvorgang ein Timeoutwert von 60 Sekunden und für den gesamten Vorgang ein Timeoutwert von 120 Sekunden. Wenn in diesem Beispiel einer der CRL-Abrufvorgänge länger als 60 Sekunden dauert, schlägt der Vorgang fehl. Wenn alle CRL-Abrufvorgänge zusammen mehr als 120 Sekunden dauern, schlägt der Vorgang ebenfalls fehl. |
Deaktivieren der CRL-Überprüfung
Exchange 2010-Wertname und -typ |
DisableCRLCheck (DWORD) |
Exchange 2007-Wertname und -typ |
DisableCRLCheck (DWORD) |
Exchange 2003-Wertname und -typ |
DisableCRLCheck (DWORD) |
Werte und Standardeinstellungen |
1 = True, 0 = False (Standard) |
Erklärung |
Wenn DisableCRLCheck auf "true" festgelegt wird, wird die Überprüfung von CRLs bei der Überprüfung der Zertifikate verhindert. Wenn Sie die CRL-Überprüfung deaktivieren, kann die Überprüfung der Signaturen signierter E-Mail-Nachrichten ggf. länger dauern. Auch werden widerrufene E-Mail-Nachrichten, die mit widerrufenen Zertifikaten signiert sind, als gültig anstatt als ungültig angezeigt. |
Immer signieren
Exchange 2010-Wertname und -typ |
AlwaysSign (DWORD) |
Exchange 2007-Wertname und -typ |
AlwaysSign (DWORD) |
Exchange 2003-Wertname und -typ |
AlwaysSign (DWORD) |
Werte und Standardeinstellungen |
1 = True, 0 = False (Standard) |
Erklärung |
Wenn AlwaysSign auf "true" festgelegt ist, müssen E-Mail-Nachrichten bei der Verwendung von Outlook Web App mit dem S/MIME-Steuerelement vom Benutzer digital signiert werden. Außerdem wird die Option "Signierte E-Mail senden" auf der Seite "Optionen" und im Dialogfeld "Nachrichtenoptionen" als aktiviert angezeigt. |
Immer verschlüsseln
Exchange 2010-Wertname und -typ |
AlwaysEncrypt (DWORD) |
Exchange 2007-Wertname und -typ |
AlwaysEncrypt (DWORD) |
Exchange 2003-Wertname und -typ |
AlwaysEncrypt (DWORD) |
Werte und Standardeinstellungen |
1 = True, 0 = False (Standard) |
Erklärung |
Wenn AlwaysEncrypt auf "true" festgelegt ist, müssen E-Mail-Nachrichten bei der Verwendung von Outlook Web App mit dem S/MIME-Steuerelement vom Benutzer verschlüsselt werden. Außerdem wird die Option "Verschlüsselte E-Mail" auf der Seite "Optionen" und im Dialogfeld "Nachrichtenoptionen" als aktiviert angezeigt. |
Transparent signieren
Exchange 2010-Wertname und -typ |
ClearSign (DWORD) |
Exchange 2007-Wertname und -typ |
ClearSign (DWORD) |
Exchange 2003-Wertname und -typ |
ClearSign (DWORD) |
Werte und Standardeinstellungen |
1 = True (Standard), 0 = False |
Erklärung |
Wenn ClearSign auf "true" festgelegt ist, muss jede von Outlook Web App gesendete digital signierte E-Mail-Nachricht transparent signiert sein. Die Standardeinstellung für dieses Attribut ist "true". Wird dieser Wert auf "false" festgelegt, wird von Outlook Web App eine nicht transparente Signatur verwendet. Transparent signierte E-Mails sind größer als nicht-transparent signierte Signaturen, können jedoch mit den meisten E-Mail-Clients geöffnet und gelesen werden – auch von solchen, die S/MIME nicht unterstützen. |
Zertifikatkette ohne Stammzertifikat einschließen
Exchange 2010-Wertname und -typ |
IncludeCertificateChainWithoutRootCertificate (DWORD) |
Exchange 2007-Wertname und -typ |
IncludeCertificateChainWithoutRootCertificate (DWORD) |
Exchange 2003-Wertname und -typ |
SecurityFlags (Wert 0x001) |
Werte und Standardeinstellungen |
1 = True, 0 = False (Standard) |
Erklärung |
In der Standardeinstellung bindet Outlook Web App beim Senden von signierten oder verschlüsselten E-Mail-Nachrichten nur Signatur- und Verschlüsselungszertifikate und nicht die entsprechenden Zertifikatketten ein. Diese Option kann für die Zusammenarbeit mit anderen Clients oder in einer Umgebung erforderlich sein, in der Zwischenzertifizierungsstellen weder mithilfe des Attributs Authority Information Access noch durch das Festlegen der Zwischenzertifizierungsstelle im Computerkonto des Exchange 2010-Postfachservers als "vertrauenswürdig" eingestuft werden können. Wenn IncludeCertificateChainWithoutRootCertificate auf "true" festgelegt wird, enthalten signierte oder verschlüsselte E-Mail-Nachrichten die vollständige Zertifikatkette mit Ausnahme des Stammzertifikats. Durch diese Einstellung werden signierte und verschlüsselte Nachrichten größer. |
Zertifikatkette und Stammzertifikat einschließen
Exchange 2010-Wertname und -typ |
IncludeCertificateChainAndRootCertificate (DWORD) |
Exchange 2007-Wertname und -typ |
IncludeCertificateChainAndRootCertificate (DWORD) |
Exchange 2003-Wertname und -typ |
SecurityFlags (Wert 0x002) |
Werte und Standardeinstellungen |
1 = True, 0 = False (Standard) |
Erklärung |
Die Option zum Einschließen der Zertifikatkette und des Stammzertifikats ähnelt der Option zum Einschließen der Zertifikatkette ohne das Stammzertifikat. Wenn dieses Attribut jedoch auf "true" festgelegt wird, werden das Stammzertifikat und die vollständige Zertifikatkette eingefügt. Wenn IncludeCertificateChainAndRootCertificate auf "true" festgelegt wird, werden signierte und verschlüsselte Nachrichten größer als mit der Option IncludeCertificateChainWithoutRootCertificate. |
Temporäre Puffer verschlüsseln
Exchange 2010-Wertname und -typ |
EncryptTemporaryBuffers (DWORD) |
Exchange 2007-Wertname und -typ |
EncryptTemporaryBuffers (DWORD) |
Exchange 2003-Wertname und -typ |
SecurityFlags (Wert 0x004) |
Werte und Standardeinstellungen |
1 = True (Standard), 0 = False |
Erklärung |
Standardmäßig werden alle clientseitigen temporären Puffer, in denen Nachrichtendaten gespeichert werden, mithilfe eines temporären Schlüssels und des 3DES-Algorithmus verschlüsselt. Diese Einstellung kann zum Aktivieren bzw. Deaktivieren der Verschlüsselung der temporären Puffer verwendet werden. Wenn Sie die Verschlüsselung der Puffer deaktivieren, kann dies die Leistung des Outlook Web App-Clients steigern. Die Informationen im Puffer des lokalen Systems sind in diesem Fall jedoch unverschlüsselt. Bevor Sie diese Funktion deaktivieren, ziehen Sie die Sicherheitsrichtlinie Ihrer Organisation zu Rate. |
Signiertes E-Mail-Zertifikat einbeziehen
Exchange 2010-Wertname und -typ |
SignedEmailCertificateInclusion (DWORD) |
Exchange 2007-Wertname und -typ |
SignedEmailCertificateInclusion (DWORD) |
Exchange 2003-Wertname und -typ |
SecurityFlags (Wert 0x008) |
Werte und Standardeinstellungen |
1 = True (Standard), 0 = False |
Erklärung |
In der Standardeinstellung schließt Outlook Web App bei installiertem S/MIME-Steuerelement sowohl Signatur- als auch Verschlüsselungszertifikate in signierte E-Mail-Nachrichten ein. Wenn Sie diese Einstellung deaktivieren, indem Sie SignedEmailCertificateInclusion auf "false" festlegen, verringert sich die Größe der von Outlook Web App mit dem S/MIME-Steuerelement gesendeten Nachrichten. Der Empfänger hat jedoch in der empfangenen Nachricht keinen Zugriff auf das Verschlüsselungszertifikat des Absenders und muss dieses auf anderem Wege abrufen. Dies ist aus einem Verzeichnis oder direkt vom Absender möglich. |
Bcc-Verzweigung von verschlüsselten E-Mail-Nachrichten
Exchange 2010-Wertname und -typ |
BccEncryptedEmailForking (DWORD) |
Exchange 2007-Wertname und -typ |
BccEncryptedEmailForking (DWORD) |
Exchange 2003-Wertname und -typ |
SecurityFlags (Werte 0x040, 0x080) |
Werte und Standardeinstellungen |
0 = Eine verschlüsselte Nachricht pro Bcc-Empfänger (Standardwert) 1 = Eine einzige verschlüsselte Nachricht für alle Bcc-Empfänger 2 = Eine verschlüsselte Nachricht ohne Bcc-Verzweigung |
Erklärung |
Standardmäßig übermittelt Outlook Web App eine separate verschlüsselte Nachricht für jeden Empfänger in der Zeile "Bcc" einer verschlüsselten Nachricht. Diese Option bietet die höchste Sicherheit für Bcc-Empfänger einer verschlüsselten Nachricht. Durch Angabe eines anderen Wertes für BCCEncryptedEmailForking können Sie festlegen, dass Outlook Web App eine einzelne verschlüsselte Nachricht für alle Bcc-Empfänger oder nur eine verschlüsselte Nachricht ohne eine separate Nachricht für jeden Bcc-Empfänger erstellen muss. |
S/MIME-Informationen in die Nachricht einschließen
Exchange 2010-Wertname und -typ |
IncludeSMIMECapabilitiesInMessage (DWORD) |
Exchange 2007-Wertname und -typ |
IncludeSMIMECapabilitiesInMessage (DWORD) |
Exchange 2003-Wertname und -typ |
SecurityFlags (Wert 0x100) |
Werte und Standardeinstellungen |
1 = True, 0 = False (Standard) |
Erklärung |
Wenn IncludeSMIMECapabilitiesInMessage auf "true" festgelegt wird, fügt Outlook Web App ausgehenden signierten und verschlüsselten Nachrichten Attribute hinzu, die angeben, welche Verschlüsselungs- und Signierungsalgorithmen und Schlüssellängen unterstützt werden. Wenn Sie dieses Attribut aktivieren, werden Nachrichten größer. Durch die Aktivierung kann jedoch die Zusammenarbeit mit Outlook Web App für einige E-Mail-Clients vereinfacht werden. |
Empfängerkopfzeilen kopieren
Exchange 2010-Wertname und -typ |
CopyRecipientHeaders (DWORD) |
Exchange 2007-Wertname und -typ |
CopyRecipientHeaders (DWORD) |
Exchange 2003-Wertname und -typ |
SecurityFlags (Wert 0x200) |
Werte und Standardeinstellungen |
1 = True, 0 = False (Standard) |
Erklärung |
Wenn CopyRecipientHeaders auf "true" festgelegt ist, wird eine Kopie der Empfängerkopfzeilen "From", "To" und "Cc" in den signierten Teil der Nachricht eingefügt. Anhand dieser Information kann der Empfänger überprüfen, ob die Kopfzeilen während des Sendens der Nachricht manipuliert wurden. Wenn Sie diese Funktion aktivieren, werden Nachrichten größer. |
Verwenden nur von Smartcard
Exchange 2010-Wertname und -typ |
OnlyUseSmartCard (DWORD) |
Exchange 2007-Wertname und -typ |
OnlyUseSmartCard (DWORD) |
Exchange 2003-Wertname und -typ |
SmartCardOnly (DWORD) |
Werte und Standardeinstellungen |
1 = True, 0 = False (Standard) |
Erklärung |
Wenn OnlyUseSmartCard auf "true" festgelegt ist und Sie Outlook Web App zusammen mit dem S/MIME-Steuerelement einsetzen, müssen auf Smartcard basierende Zertifikate zum Signieren und Verschlüsseln verwendet werden. Benutzer können keine Zertifikate verwenden, die sich nicht auf einer Smartcard befinden. |
Dreifach verschlüsselte Nachrichten
Exchange 2010-Wertname und -typ |
TripleWrapSignedEncryptedMail (DWORD) |
Exchange 2007-Wertname und -typ |
TripleWrapSignedEncryptedMail (DWORD) |
Exchange 2003-Wertname und -typ |
TripleWrap (DWORD) |
Werte und Standardeinstellungen |
1 = True (Standard), 0 = False |
Erklärung |
Wenn TripleWrapSignedEncryptedMail auf "true" festgelegt ist, werden digital signierte verschlüsselte Nachrichten dreifach verschlüsselt ("triple-wrapped"). Wenn eine Nachricht dreifach verschlüsselt ist, wird die digital signierte Nachricht zuerst verschlüsselt und anschließend digital signiert. Wenn das Attribut auf "false" festgelegt ist, wird die signierte Nachricht lediglich verschlüsselt. Sie wird nach der Verschlüsselung nicht noch zusätzlich digital signiert. In der Standardeinstellung ist dieses Attribut auf "true" festgelegt. Dreifach verschlüsselte Nachrichten bieten die höchste Sicherheit für digital signierte und verschlüsselte E-Mail-Nachrichten gemäß dem S/MIME-Standard, sind jedoch auch größer als Nachrichten, die nicht dreifach verschlüsselt sind. |
Verwenden von Schlüssel-ID
Exchange 2010-Wertname und -typ |
UseKeyIdentifier (DWORD) |
Exchange 2007-Wertname und -typ |
UseKeyIdentifier (DWORD) |
Exchange 2003-Wertname und -typ |
UseKeyIdentifier (DWORD) |
Werte und Standardeinstellungen |
1 = True, 0 = False (Standard) |
Erklärung |
Beim Verschlüsseln von E-Mail-Nachrichten codiert Outlook Web App standardmäßig die Lockbox, in der das asymmetrisch verschlüsselte Token gespeichert wird, das zum Entschlüsseln der restlichen Nachricht erforderlich ist. Die Lockbox wird durch Angabe des Ausstellers und der Seriennummer des Zertifikats der einzelnen Empfänger codiert. Anhand dieser Angaben können anschließend das Zertifikat und der private Schlüssel zum Entschlüsseln der Nachricht ermittelt werden. Eine weitere Möglichkeit, das Zertifikat und den privaten Schlüssel zum Entschlüsseln von Nachrichten zu ermitteln, besteht darin, die Schlüssel-ID eines Zertifikats zu verwenden, indem UseKeyIdentifier auf "true" festgelegt wird. Da ein Schlüsselpaar in neuen Zertifikaten erneut verwendet werden kann, müssen Benutzer durch die Verwendung der Schlüssel-ID für verschlüsselte E-Mail-Nachrichten lediglich das aktuelle Zertifikat mit dem zugehörigen privaten Schlüssel aufbewahren. Es ist nicht erforderlich, alle alten Zertifikate beizubehalten, die nur nach Aussteller und Seriennummer verglichen werden können. Da einige E-Mail-Clients die Suche nach Zertifikaten über eine Schlüssel-ID nicht unterstützen, verwendet Outlook Web App standardmäßig den Aussteller und die Seriennummer der einzelnen Empfängerzertifikate. Durch das Aktivieren dieser Funktion kann die Verwaltung verschlüsselter Nachrichten jedoch vereinfacht werden, da die Benutzer alte, abgelaufene Zertifikate nicht mehr in ihrem System aufbewahren müssen. |
S/MIME-Verschlüsselungsalgorithmen
Exchange 2010-Wertname und -typ |
EncryptionAlgorithms (Reg-SZ) |
Exchange 2007-Wertname und -typ |
EncryptionAlgorithms (Reg-SZ) |
Exchange 2003-Wertname und -typ |
EncryptionAlgorithms (Reg_SZ) |
Werte und Standardeinstellungen |
Dieser Schlüssel enthält eine durch Semikolons getrennte Liste der symmetrischen Verschlüsselungsalgorithmen, die beim Verschlüsseln von Nachrichten mit Outlook Web App und dem S/MIME-Steuerelement verwendet werden sollen. Listenformat: {Bekannte Algorithmus-ID}[:zu verwendende Schlüssellänge]|[,Benutzerdefinierte Ersetzungsalgorithmus-OID]; {Bekannte Algorithmus-ID}[:zu verwendende Schlüssellänge]|[,Benutzerdefinierte Ersetzungsalgorithmus-OID]; … Unterstützte Algorithmen und ihre ALG_IDs:
Die Schlüssellänge gilt nur für Algorithmen mit variabler Schlüssellänge, wenn die Schlüssellänge nicht in der Algorithmus-ID selbst codiert ist. RC2 ist der einzige Algorithmus in der Liste oben, der diese Bedingung erfüllt. Benutzerdefinierte Ersetzungsalgorithmus-OID Sie können einen eigenen Algorithmus bereitstellen, indem Sie diesen in einem CSP (Cryptographic Service Provider, Kryptografiedienstanbieter) implementieren, ihm eine benutzerdefinierte Objekt-ID zuweisen und anschließend die OID mithilfe des Schlüssels EncryptionAlgorithms angeben. Eine OID muss zusammen mit einer bekannten Algorithmus-ID angegeben werden. Outlook Web App benötigt eine bekannte Algorithmus-ID, um ermitteln zu können, wie der Algorithmus verwendet werden soll. Um beispielsweise eine benutzerdefinierte Ersetzung für den 3DES-Algorithmus bereitzustellen, geben Sie die ALG_ID von 3DES (0x6603) sowie die benutzerdefinierte OID des Ersetzungsalgorithmus an. Die Werte des Registrierungsschlüssels sollten von der längsten zur kürzesten Schlüssellänge angeordnet sein, da durch die Reihenfolge die Priorität der Verwendung festgelegt wird. Beispiel: Für die Auflistung von 3DES, RC2-128, RC2-64, DES, RC2-56 und RC2-40 müssen Sie den Wert folgendermaßen eingeben: 6603;6602:128;6602:64;6601;6602:56;6602:40 Wenn der Registrierungsschlüssel vorhanden ist, werden die im Schlüssel angegebenen Algorithmen immer verwendet. Wenn der Schlüssel nicht vorhanden ist, verwendet Outlook Web App die interne Standardliste. Diese Liste beginnt mit AES256 auf Computern, auf denen Windows Vista verwendet wird, und mit 3DES auf Computern, auf denen Windows XP verwendet wird. Die AES-Algorithmen werden nur verwendet, wenn sie vom Computer des Benutzers unterstützt werden. AES wird unter Windows XP nicht unterstützt und mithilfe von AES verschlüsselte Nachrichten können nicht auf Computern gelesen werden, auf denen Windows XP verwendet wird. |
Erklärung |
Outlook Web App versucht, den stärksten Algorithmus mit dem längsten verfügbaren Schlüssel auf dem Computer des Benutzers zu verwenden. Wenn der Verschlüsselungsalgorithmus oder die minimale Schlüssellänge auf dem Computer des Benutzers nicht verfügbar ist, lässt Outlook Web App keine Verschlüsselung zu. |
S/MIME-Standardsignaturalgorithmus
Exchange 2010-Wertname und -typ |
SigningAlgorithms (Reg_SZ) |
Exchange 2007-Wertname und -typ |
SigningAlgorithms (Reg_SZ) |
Exchange 2003-Wertname und -typ |
DefaultSigningAlgorithm (reg_SZ) |
Werte und Standardeinstellungen |
Durch den Schlüssel SigningAlgorithms werden die Signaturalgorithmen festgelegt, die zum Signieren von Nachrichten unter Verwendung von Outlook Web App mit dem S/MIME-Steuerelement verwendet werden. In der folgenden Tabelle sind die Signaturalgorithmen, die entsprechenden Algorithmus-IDs sowie die unterstützten Schlüssellängen aufgeführt. Format: {Bekannte Algorithmus-ID} Bekannte Algorithmus-IDs und Schlüssellängen
Wenn der Registrierungsschlüssel vorhanden ist, wird immer der im Schlüssel angegebene Algorithmus verwendet. Wenn der Schlüssel nicht vorhanden ist, verwendet Outlook Web App die interne Standardliste. Diese Liste beginnt mit SHA-1. Nachrichten, die mithilfe von CALG_SHA_256 digital signiert wurden, können auf Computern mit Windows XP nicht überprüft werden. |
Erklärung |
Dieses Attribut gibt den zu verwendenden Signaturalgorithmus an, der zum digitalen Signieren von Nachrichten unter Verwendung von Outlook Web App mit dem S/MIME-Steuerelement herangezogen wird. |
Erzwingen von S/MIME-Clientaktualisierung
Exchange 2010-Wertname und -typ |
ForceSMIMEClientUpgrade (DWORD) |
Exchange 2007-Wertname und -typ |
ForceSMIMEClientUpgrade (DWORD) |
Exchange 2003-Wertname und -typ |
Nicht verfügbar. Diese Funktion war neu in Exchange 2007. |
Werte und Standardeinstellungen |
1 = True (Standard), 0 = False |
Erklärung |
Wenn ForceSMIMEClientUpgrade auf "true" festgelegt und die Clientsteuerungsversion auf dem Computer des Benutzers älter als die Version auf dem Server ist, muss der Benutzer das neue Steuerelement herunterladen und installieren, bevor er mit der Verwendung von S/MIME-Lese- oder -Entwurfsformularen fortfahren kann. Wenn dieser Wert auf "false" festgelegt ist, erhält der Benutzer eine Warnung, wenn das S/MIME-Steuerelement auf seinem Computer älter als die Version auf dem Server ist. Er kann jedoch S/MIME auch weiterhin verwenden, ohne das Steuerelement aktualisieren zu müssen. |
Verwenden des Registrierungs-Editors zum Ändern der Einstellungen des S/MIME-Steuerelements für Outlook Web App
Bevor Sie dieses Verfahren ausführen können, müssen Ihnen die entsprechenden Berechtigungen zugewiesen werden. Informationen zu den von Ihnen benötigten Berechtigungen finden Sie unter "Registrierungs-Editor" im Thema Clientzugriffsberechtigungen.
.gif "Vorsicht") Achtung: |
|---|
| Eine fehlerhafte Bearbeitung der Registrierung kann zu schwerwiegenden Problemen führen, die eine Neuinstallation des Betriebssystems erforderlich machen kann. Durch fehlerhafte Bearbeitung der Registrierung verursachte Probleme können unter Umständen nicht mehr behoben werden. Sichern Sie alle wichtigen Daten, bevor Sie die Registrierung bearbeiten. |
Starten Sie den Registrierungs-Editor ("regedit").
Suchen Sie nach dem folgenden Registrierungsunterschlüssel:
HKLM\System\CurrentControlSet\Services\MSExchange OWA\SMIME
Suchen Sie nach dem Registrierungsschlüssel, den Sie ändern möchten.
Legen Sie den Schlüssel auf den Wert fest, der für Ihre Organisation erforderlich ist.
Wenn der von Ihnen benötigte Schlüssel nicht vorhanden ist, erstellen Sie einen neuen DWORD-Wert mit diesem Namen und legen Sie diesen anschließend auf den Wert fest, der für Ihre Organisation erforderlich ist.
© 2010 Microsoft Corporation. Alle Rechte vorbehalten.