Zertifikatarten
Nicht jedes Zertifikat ist gleich gut für die Verwendung mit SMIME geeignet und es gibt sehr wohl unterschiede zwischen Zertifikaten für die individuelle Verschlüsselung der Mails von Einzelpersonen, den Einsatz eines Gateway-Zertifikats und Zertifikaten für SSL/TLS-Verbindungen.
- Benutzerzertifikate
Diese Zertifikate dienen zur Signierung eigener Mails und zum Empfang verschlüsselter Nachrichten. Im Zertifikat ist in der Regle die Mailadresse des Nutzers hinterlegt - TLS/SSL-Zertifikat
Diese Zertifikate kommen meist auf Webservern oder SMTP-Servern zum Einsatz um die TCP-Kommunikation per SSL zu sichern. So können die Daten auf der Leitung verschlüsselt werden, ohne das die Mail selbst verschlüsselt sein muss. Sie können diese Zertifikate z.B. beim Zugriff auf ihr Homebanking. - Gateway-Zertifikat
Ein solches Zertifikat kommt bei Gateway-Lösungen zu Einsatz, welche Mails für komplette Domains signieren und entschlüsseln.
Die Steuerung, wie Zertifikate ausgestellt werden, übernehmen Templates der Zertifizierungsstelle. Schauen wir uns die einzelnen Zertifikate genauer an:
S/Mime-Benutzerzertifikate
Ein Zertifikat besteht aus mehreren Feldern, wie Sie schon bei der Anzeige erkennen können: Damit Outlook und OWA diese Zertifikate für Mail verwendet, müssen ein paar Randbedingungen erfüllt sein
Feld | Bild | Bedeutung |
---|---|---|
Gültigkeit und Aussteller |
|
Abgelaufene Zertifikate werden von Outlook und OWA nicht berücksichtigt. Auch muss die Kette der Vertrauensstellungen komplett auflösbar sein. Wer also Zertifikate von privaten CAs verwendet, muss diese auch als "vertrauenswürdig" auf dem Client addieren. Prüfen Sie hier auch oben links das Zertifikatssymbol. Erscheint hier ein gelbes Warnzeichen oder sogar ein Rotes Stop-Zeichen, dann wird Outlook das Zertifikat nicht verwenden. abgelaufen, zurückgezogen o.ä. Aussteller kann nicht überprüft werden |
Antragsteller |
|
Dieses Feld enthält weitergehende Informationen. Outlook nutzt dieses Feld, um das Zertifikat zu einer Mailadresse zuzuordnen. Es muss aber nicht zwingend ein "E="-Feld vorhanden sein. Outlook 2007 z.B.: akzeptiert auch Zertifikate, die im alternativen Namen ein RFC822-Feld haben. |
Alternativer Name |
|
Dieser Name ist wichtig, damit Outlook das Zertifikat der Mailadresse zuordnen kann. Ich konnte Zertifikate nutzen, die nur an dieser Stelle meine Mailadresse hatten und z.B. im Subject kein E=-Feld hatten. |
Schlüsselverwendung und erweiterte Schlüsselverwendung |
|
Über die Schlüsselverwendung kann der
Zertifikatinhaber bzw. die CA steuern,
wie das ausgestellte Zertifikat
verwendet wird. Allerdings hat ein Zertifikat in der Schlüsselverwendung nur die "Digitale Signatur (80)" während das andere Zertifikat nur die "Schlüsselverschlüsselung (20)" enthält. Das führt dazu, dass Sie auf eine empfangene signierte Mail nicht immer auch verschlüsselt antworten können. Das kann durchaus gewollt sein, wenn eine Firma seinen Mitarbeitern ein Zertifikat zum Signieren überlässt, aber eine eingehende Verschlüsselung verhindern möchte oder den privaten Schlüssel zum Zertifikat zur Verschlüsselung zusätzlich speichern muss (z.B. für Archiv, Virenscan, Revision etc.) Es gibt natürlich auch Zertifikat, die beide Funktionen bereit stellen. |
Damit Outlook mit so einem Zertifikat auch arbeiten kann, muss er natürlich Zugriff auf das Zertifikat haben. Ein Zertifikat zum Signieren liegt daher meist in ihrem lokalen Zertifikatsspeicher vor während die zur Verschlüsselung erforderlichen Zertifikate der Empfänger bei den Kontakte in Outlook oder Active Directory hinterlegt sind. Outlook muss aber diesem Zertifikat vertrauen. Das kann über die Einstellung in Outlook z.B. konfiguriert werden. Normalerweise nutzt Outlook die Vertrauensstufe der ausstellenden CA.
Sie können als Anwender aber auch abweichend davon einem Zertifikat vertrauen, auch wenn der Aussteller nicht überprüfbar ist.
SSL/TLS-Zertifikat
Sie können sicher die Funktion per HTTPS auf einer Webseite "sicher" zuzugreifen. Damit dies funktioniert, benötigen Sie natürlich auch ein Zertifikat auf dem Webserver, welcher dieser an den Client ausliefert. Der Client prüft Name, Gültigkeitsdatum und Aussteller und erst wenn alles passt oder der Benutzer eine Warnung bestätigt, ist die Gegenstelle verifiziert der der Client kann mit dem im Zertifikat enthaltenen "Public Key" eine verschlüsselte Verbindung aufbauen. Die hierfür zum Einsatz kommenden Zertifikate sind ganz normale Serverzertifikate:
Wichtig ist hierbei, dass die Schlüsselverwendung wieder sowohl die digitale Signatur als auch die Schlüsselverschlüsselung erlaubt und die erweiterte Verwendung die Serverauthentifizierung enthält.
Die gleichen Zertifikate werden gerne auf Mailservern eingesetzt, damit die SMTP-Server sich gegenseitig authentifizieren und vor allem die Übertragung verschlüsseln können. Die Verschlüsselung findet hier aber immer nur zwischen den beiden beteiligten MTAs statt. Sie können also nie sicher sein, dass die komplette Strecke gesichert ist.
Mit den gleichen Zertifikaten können Sie auch POP3, IMAP4, HTTP (OWA) und SMTP-Server ausstatten, damit die Kommunikation zwischen Client und Postfachserver verschlüsselt und verifizierbar ist.
Gateway-Zertifikat
Eine besondere Rolle kommt den Zertifikaten zu, die auf Signaturgateways wie NoSpamProxy Encryption eingesetzt werden. Mit solchen Zertifikaten werden z.B. ausgehende Mails digital signiert und eingehende Mails entschlüsselt werden können. Besitzt ein Gateway ein Zertifikat einer Gegenstelle, dann kann es auch ausgehende Mails damit verschlüsseln.
Hier sehen Sie das offizielle Zertifikat, welches z.B. Net at Work mit NoSpamProxy Encryption verwendet:
Der Verwendungszweck ist "Sichere E-Mail" und die Schlüsselverwendung erlaubt die digitale Signatur und Schlüsselverschlüsselung. Allerdings kann man im Zertifikat als "Mailadresse" nun nicht alle gültigen internen Adressen hinterlegen und auch der Einsatz einer "Wildcard"-Adresse wie RFC822-Name=*@netatwork.de funktioniert hier nicht.
Es gibt keinen 100% sicheren Weg, um ein Zertifikat als "Gateway-Zertifikat" zu erkennen. Eine Software könnten allenfalls vermuten, wenn eine Mail von einer Adresse einkommt und von einer anderen Adresse unterschrieben ist. Allerdings gibt es Möglichkeiten dem Empfänger einen Tipp zu geben
- DOMSEC
Ein Attribut, das angibt, das der Absender eine Domänensignatur verwendet
(RFC3183 - Domain Security Services using S/MIME http://www.faqs.org/rfcs/rfc3183.html) - Preferred Encryption Certificate Attribute
Damit kann ein Versender angeben, dass ein Gateway-Zertifikat zum Verschlüsseln verwendet werden soll.
Qualifizierte Signatur
Ein Begriff, der beim Thema Verschlüsseln und Signieren immer mal wieder fällt, ist die "Qualifizierte Signatur". Damit ist aber nicht die Signierung von Mails per S/MIME oder PGP gemeint, sondern die Signierung von Dokumenten, z.B. elektronischen Rechnungen. Sie können dies z.B. wenn Sie ihre Rechnung der Telekom per Mail bekommen. Sie erhalten dann eine ZIP-Datei, in welcher die Rechnung als PDF und eine pkcs7-Datei enthalten ist
Mit der passenden Software können Sie damit überprüfen, dass die PDF-Datei tatsächlich vom Aussteller ist und nicht verändert wurde. Andere Firmen wie z.B. HostEurope bieten direkt signierte PDF-Dateien an, die im Betrachter geprüft werden können ,z.B.
Auch hierzu werden Zertifikate verwendet, die aber für die Übertragung der Information selbst nicht von Belang sind. Daher gehe ich hier nicht weiter darauf ein. Es gibt allerding SMTP-Gateway-Lösungen wie z.B. NoSpamProxy Encryption, die auch diese Funktionalität enthalten, d.h. Anlagen z.B. digital signieren.
Weitere Links
- Verzeichnisabgleich
- Alles zu Kontakten und Adressen
- Benutzerzertifikate im AD
- 811418 "No Certificate Templates Could Be Found" error message when a User requests certificate from CA Web enrollment pages
- Windows 2003 Adminpack: Certificate Services in Windows Server
2003
http://www.microsoft.com/downloads/details.aspx?FamilyID=C16AE515-C8F4-47EF-A1E4-A8DCBACFF8E3&displaylang=en - Publish S/MIME certificates für external contacts to Active
Directory für use with Exchange Server 2007
http://blogs.technet.com/b/exchange/archive/2008/04/23/448761.aspx - How Do I Distribute the SBS 2008 Self-Signed SSL Certificate to
My Users?
http://blogs.technet.com/sbs/archive/2008/09/30/how-do-i-distribute-the-sbs-2008-self-signed-ssl-certificate-to-my-Users.aspx