S/MIME und private Enterprise CAs

Inhalt

E-Mail-Verschlüsslung mit Hilfe von S/MIME ist keine neue Technologie. Umso mehr verwundert es, das gerade große Unternehmen, die vordergründig die Verschlüsselung der E-Mail-Kommunikation propagieren, ebendiese verschlüsselte Kommunikation unmöglich machen. Eine nicht vollständig durchdachte Implementierung kann sogar dazu führen, dass gar keine E-Mail-Kommunikation mehr möglich ist.

Schauen wir uns die Details an.

Das Problem

Der Lieferant hatte von einem seiner Finanzdienstleister die Anforderung zur Nutzung einer verpflichtenden S/MIME-verschlüsselten E-Mail-Kommunikation erhalten. Um die Ausstellung und Pflege der S/MIME-Zertifikate und die Nutzung durch die Anwendenden so einfach wie nur möglich zu gestalten, hatte man sich für ein S/MIME-Gateway entschieden. So kann die Ver- und Entschlüsselung zentral erfolgen und die S/MIME-Zertifikate müssen nicht kompliziert auf ein oder mehrere Endgeräte ausgerollt werden.

Nach Inbetriebnahme des Gateways kam es zu Störungen in der E-Mail-Kommunikation mit einigen wenigen Kunden. Eingehende E-Mail-Nachrichten wurden durch die Gateway-Software abgelehnt, da sie gegen Richtlinien verstießen.

Was war passiert? Und welche Kunden waren betroffen?

Ausgangssituation

Das folgende Schaubild zeigt die vereinfachte technische Konfiguration der S/MIME-Implementierungen auf Lieferanten- und Kundenseite. Die Darstellung der Kundenseite basiert auf den Annahmen, die aufgrund des Fehlerbildes und der E-Mail-Header von Nachrichten, die vor dem Auftreten des Fehlers, empfangen wurden.

Lieferantenseite

Nutzung eines S/MIME-Gateway mit automatischer Ausstellung von S/MIME-Zertifikaten über eine öffentliche Zertifizierungsstelle
Die Zertifikate der Stamm- und Zwischenzertifizierungsstellen sind öffentlich bekannt und Teil der meisten Betriebssysteme
Ausgehende E-Mail-Nachrichten erhalten automatisch eine S/MIME-Signatur, wodurch das persönliche S/MIME-Zertifikat der Absenderadresse Teil der E-Mail-Nachricht wird

Kundenseite

Nutzung eines S/MIME-Gateway mit automatischer Ausstellung von S/MIME-Zertifikaten über eine interne Unternehmenszertifizierungsstelle (Enterprise CA)
Die Zertifikate der Stamm- und Zwischenzertifizierungsstellen sind öffentlich nicht bekannt
Ausgehende E-Mail-Nachrichten erhalten automatisch eine S/MIME-Signatur, wodurch das persönliche S/MIME-Zertifikat der Absenderadresse Teil der E-Mail-Nachricht wird

So viel zur Ausgangssituation.

Was passiert?

Schritt 1 – Automatischer Zertifikat-Import Kunde zu Lieferant

In diesem ersten Schritt wird eine E-Mail-Nachricht des Kunden an den Lieferanten gesendet.

Das Gateway des Kunden signiert die ausgehende E-Mail-Nachricht automatisch, das persönliche Zertifikat wird Teil der E-Mail-Nachricht.
Das Gateway des Lieferanten erkennt die S/MIME-signierte Nachricht und importiert das Zertifikat.
Die Zertifikatkette kann nicht überprüft werden, da die Zertifikate der ausstellenden Zertifizierungsstellen nicht vorhanden sind. Das Zertifikat ist für das S/MIME-Gateway ungültig.

Das folgende Schaubild verdeutlicht die beiden Schritte.

Die E-Mail wird an die empfangende Person beim Lieferanten zugestellt und kann problemlos gelesen werden.

Schritt 2 – Automatischer Zertifikat-Import Lieferant zu Kunde

Die ausgehende Nachricht des Lieferanten erhält automatisch eine S/MIME-Signatur und das Zertifikat wird Teil der E-Mail.
Das Gateway erkennt zwar, dass ein Zertifikat der Empfängeradresse vorhanden ist, nutzt dies aber nicht, da es ungültig ist.
Die Gateway-Lösung auf Kundenseite erkennt, dass die eingehende E-Mail-Nachricht eine S/MIME-Signatur enthält und greift das in der E-Mail enthaltene Zertifikat ab und speichert es in der lokalen Zertifikat-Datenbank.
Das Gateway prüft die vollständige Zertifikatkette des importierten Zertifikates und prüft über die erreichbaren CRL-Endpunkte, ob das Zertifikate nicht zurückgezogen wurde. Bei positiver Prüfung erkennt das Gateway das Zertifikat als gültig an.

Das folgende Schaubild verdeutlicht die beiden Schritte.

Zu diesem Zeitpunkt kann die empfangende Person auf Kundenseite die E-Mail lesen und darauf antworten.

Aber nun beginnt das Dilemma.

Schritt 3 – S/MIME-Verschlüssung Kunde zu Lieferant

Der Ansprechpartner beim Kunden antwortet auf die empfangene Nachricht des Lieferanten.

Das Gateway des Kunden erkennt, dass für die Empfängeradresse der E-mail-Nachricht ein gültiges S/MIME-Zertifikat vorhanden und verschlüsselt die E-Mail-Nachricht.
Das Gateway des Lieferanten erkennt, dass die empfangene Nachricht S/MIME-verschlüsselt wurde. Die Prüfung des Zertifikates des Absenderadresse schlägt jedoch fehl, da das Zertifikat ungültig ist (s. Schritt 1), und lehnt den Empfang der Nachricht mit einem SMTP-Fehlercode ab.
Das Gateway des Kunden verarbeitet den empfangenen Fehlercode und erstellt eine Nichtzustellbar-Nachricht (NDR) und sendet diese an die Absenderadresse.

Der Kunde kann nicht mehr auf Nachrichten des Lieferanten antworten.

Neue E-Mail-Nachrichten des Lieferanten an den Kunden sind für den Ansprechpartner beim Kunden weiterhin lesbar, da diese, wie in Schritt 2 beschrieben, nur signiert, aber nicht verschlüsselt werden.

Lösung (Die Eigentliche)

Um das Gateway des Lieferanten zu befähigen, die Zertifikatkette der persönlichen S/MIME-Zertifikate überprüfen zu können, müssen die Zertifikate der Stamm- und Zwischenzertifizierungsstellen manuell importiert werden. Hierzu muss die Gegenseite diese Zertifikate nur bereitstellen.

Manche Großunternehmen, die Zertifzierungsstellen selbst betreiben, stellen diese Zertifikate auf ihrer Webseite bereit. BASF geht in diesem Zusammenhang mit gutem Beispiel voran. Eine einfache Internetsuche nach “BASF S/MIME Root CA” führte schnell zum Ziel.

Nach dem Import der von BASF bereitgestellten Zertifikate kann der Lieferant aus unserem Beispiel fehlerfrei S/MIME-verschlüsselte Nachrichten austauschen.

Lösung (Der Workaround)

Der in unseren Beispiel genannte Kunde geht mit dem Thema S/MIME nicht so offen um, wie man es sich wünschen möchte. Weder eine Internetsuche, noch eine direkte Suche über die Suchfunktion des Webauftrittes führten zum Erfolg.

Die IT des Lieferanten sah nur einen Ausweg, die IT des Kunden musste kontaktiert werden.

Wie der IT-Support des Kunden reagiert

Der Anwender auf Lieferantenseite hat von der eigenen IT eine vorformulierte Nachricht für die IT des Kunden erhalten. Dies war verbunden mit der Bitte, den Ansprechpartner auf Kundenseite zu bitten, diese Nachricht an die interne IT zu senden. Die IT des Lieferanten konnte sich nicht direkt an die IT auf Kundenseite wenden, da die Herausgabe von Kontaktdaten auf Kundenseite untersagt war.

Der betroffene Anwender beim Kunden hat sich gegenüber dem Ansprechpartner beim Lieferanten anschließend wie folgt geäußert:

“Unsere IT sieht die Umstellung oder Änderung bei Ihnen. Ihre Standards sind höher als unsere. Daher sehe ich den den Bedarf zur Anpassung bei Ihnen.”

Es fand keinerlei direkte Kontaktaufnahme von Seiten der IT des Kunden in Richtung der IT des Lieferanten statt. Ich kann hier nur mutmaßen, dass es sich um keine “eigene” IT-Abteilung mehr handelt, sondern das die Anfrage von Mitarbeitenden eines externen Helpdesk-Dienstleistern beantwortet wurde. Dies ist sowohl für den Ansprechpartner auf Kundenseite, wie auch für alle Beteiligten auf Lieferantenseiten sehr unzufriedenstellend.

Der Workaround

Der Workaround ist einfach, aber auch bitter. Die Nutzung von S/MIME musste für den im Beispiel genannten Kunden deaktiviert werden. Dies erforderte folgenden Schritte:

Konfiguration der S/MIME-Deaktivierung, keine Signierung oder Verschlüsselung, für die Kundendomänen
Löschung aller im Gateway importierten persönlich S/MIME-Zertifikate
Bitte an den internen Ansprechpartner, den Ansprechpartner auf Kundenseite zu bitten, dass die IT die importierten S/MIME-Zertifikate löscht

Eine Bitte

Ich habe eine persönliche Bitte an die Unternehmen, die sich für den Betrieb einer eigenen Zertifizierungsstelle entschieden haben oder in Zukunft entscheiden werden.

Stellt die Zertifikate auf der Unternehmenswebseite zum Download bereit. Dies erleichtert anderen Unternehmen die korrekte Konfiguration und stellt eine verschlüsselte E-Mail-Kommunikation sicher. Sollte dies, aus welchen Gründen auch immer, nicht möglich sein, stellt im Intranet Informationen zur S/MIME-Nutzung bereit. Auf der Seite sollten, auch die Kontaktinformationen der IT-Abteilung aufgeführt sein, die MItarbeitende an externe Personen weitergeben können, um S/MIME richtig einrichten zu können.

S/MIME und private Enterprise CAs