|
|
|
|
 |
|
 |
| · · · · · · · · · · · · · · · · · · · · · · · |
|
| · · · · · · · · · · · · · · · · · · · · · · · |
|
| · · · · · · · · · · · · · · · · · · · · · · · |
|
| · · · · · · · · · · · · · · · · · · · · · · · |
|
| · · · · · · · · · · · · · · · · · · · · · · · |
|
|
|
|
|
 |
|
|
|
 |
|
|
OWA - S/MIME - Control
|
Exchange 2003 S/MIME Unterstützung |
| |
|
|
|
Microsoft lieferte mit seiner E-Mailserver MS Exchange immer die notwendigen PKI Fähigkeiten für den Einsatz von S/MIME mit. Das Key Management Service von Exchange übernahm dabei die Aufgaben der PKI, wie die Ausgabe von Zertifikaten, ab 5.5. auch X.509.v3 Zertifikate, Widerruf und Schlüsselarchivierung etc. Mit der Einführung der Zertifikatsdienste in Windows 2000 Server (MS-Zertifizierungsstelle) gingen Aufgaben des Key Management Service auf diese Zertifikatsdienste über.
Mit der Integration von MS Exchange 2000 in das Active Directory gingen weitere Funktionen auf die Zertifikatsdienste über, sodass bei MS Exchange 2000 lediglich Schlüsselarchivierung und Wiederherstellung (Anm. der privaten Schlüssel) beim Key Management Service verblieb, da dieses Feature beim Zertifikatsdienst von Windows 2000 Server nicht vorhanden ist. Mit Windows Server 2003 ist auch das letztgenannte Feature in die Zertifikatsdienste integriert worden und das Key Management Service ist aus Exchange 2003 vollständig entfernt.
|
Lokalisierung des richtigen öffentlichen Schlüssel |
Bei erhaltenen E-Mails mit Signaturen wird der öffentliche Schlüssel des zumeist mitgelieferten Zertifikats herangezogen.
Beim Senden von verschlüsselten Mails muss unter Umständen der öffentliche Schlüssel aus mehreren Zertifikaten gewählt werden. Die Suchreihenfolge der gefundenen Zertifikate im Active Directory ist dabei folgende:
1. Attribut userCertificate und Attribut userSMIMECertificate im Active Directory-Objekt des Empfängers.
2. Attribut userCertificate und Attribut userSMIMECertificate im Active Directory-Kontaktobjekt des Empfängers, sprich in den persönlichen Kontakten des Senders.
Zu beachten ist, dass z.B. Outlook 2003 erst userSMIMECertificate heranzieht und Outlook Web Access erst userCertificate untersucht - und damit unter Umständen unterschiedliche Zertifikate für die Verschlüsselung herangezogen werden.
Wird ein Zertifikat gefunden wird nicht mehr weitergesucht. Ein Veröffentlichen des Zertifikates in der Global Adress List (GAL) über die Schaltfläche "In GAL veröffentlichen" durch den Inhaber eines Zertifikates hat zur Folge, dass die Signatur (ExchangeUserSignature) und alle Zertifikate (ExchangeUser certificates) des Benutzers inklusive Zertifizierungspfad im PKCS #7-Format im userSMIMECertificate-Attribut des Benutzerobjekts gespeichert werden. Die Zertifikate (ExchangeUser certificates) des Benutzers werden auch im DER-Format im userCertificate-Attribut des Benutzerobjekts in Active Directory veröffentlicht. Der Administrator kann unter "Active Directory-Benutzer und -Computer" auf der Registerkarte Veröffentlichte Zertifikate dem userCertificate-Attribut ein Zertifikat hinzufügen, das jedoch nicht gleichzeitig dem userSMIMECertificate-Attribut hinzugefügt werden kann.
Werden E-Mails verschlüsselt versendet, so werden Kopien in anderen Ordnern wie "Gesendete Objekte" ebenso verschlüsselt. Diese Verschlüsselung ist aber für den Absender gedacht, d.h. zur Verschlüsselung wird natürlich der öffentliche Schlüssel des Absenders herangezogen, deshalb ist in diesem Fall beim Senden von verschlüsselten E-Mails ein Zugriff auf das eigene Verschlüsselungszertifikat notwendig. Ist dies nicht der Fall wird die Fehlermeldung angezeigt, dass nicht für alle Empfänger ein Zertifikat gefunden werden konnte, wird diese Meldung ignoriert, kann man auf die Kopie in den "Gesendeten Objekten" nicht mehr zugreifen. Für die Entschlüsselung benötigt der Benutzer seinen privaten Schlüssel.
|
|
|
|
Der E-Mail-Client und die PKI stellen zusammen Funktionen für Nachrichtensicherheit, digitale Signaturen und Verschlüsselung bereit. Der Exchange-Server ist lediglich für das Zustellen und Speichern von S/MIME-Nachrichten zuständig, Ausnahme OWA mit S/MIME-Control
. Zum erfolgreichen Speichern von S/MIME E-Mail-Nachrichten in Exchange muss als einzige Voraussetzung eine entsprechende Konfiguration des Nachrichtenspeichers für die Erkennung von S/MIME-Signaturen erfolgen, was standardmäßig der Fall ist.
Bei E-Mailsignaturen können "Event Sinks" oder Antivirensoftware Probleme auslösen. "Event Sinks" führen am E-Mailserver bestimmte Aktionen während der Verarbeitung eines E-Mails aus. "Event Sinks" können auch den Inhalt oder Headerinformationen eines E-Mails ändern, Inhaltsänderungen führen dazu, dass die Signatur ungültig ist, eine Änderung des "From"-Headers kann dazu führen, dass Empfänger-Clients die Signatur für ungültig erklären, da gemäß S/MIME Spezifikation die E-Mailadresse im Zertifikat, wenn vorhanden, mit dem Absender zusammenpassen muss. Ab 2000 akzeptiert Outlook auch verschiedene E-mailadressangaben in Zertifikat und "From"-Header und zeigt dafür eine neue signed-by Zeile an, wo der Zertifikatsinhaber ausgewiesen wird.
Antivirensoftware die nach dem Signieren E-Mails überprüft, kann ebenfalls die Signatur ungültig machen. Verschlüsselte E-Mails können am Server nicht auf Malicious Code hin geprüft werden. Für diesen Fall sind eigene Lösungen notwendig, welche die Ver- und Entschlüsselung serverseitig vornehmen.
|
Exchange 2003 Clients OHNE S/MIME Unterstützung |
Die folgenden Clients besitzen keine S/MIME Unterstützung - auf Ihnen können aber unverschlüsselte signierte Nachrichten angezeigt werden, die Signaturen werden dabei aber NICHT überprüft.
|
|
 |
Outlook Web Access-Clients ohne S/MIME-Steuerelement |
|
Outlook Mobile Access-Clients |
|
Exchange ActiveSync-Clients |
|
|
|
|
|
Linktipps |
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
