Ausgangssituation:
Bei einer eingehenden, signierten E-Mail wurde die Signatur vom SEPPmail Secure E-Mail Gateway als gültig erkannt. Im Betreff der E-Mail ist das entsprechende Kennzeichen (im Standard [signed OK]) zu sehen.
Das SEPPmail Secure E-Mail Gateway ist so konfiguriert, dass erfolgreich geprüfte Signaturen nicht abgeschnitten werden.
Im empfangenden E-Mail Client wird nun die Signatur jedoch als ungültig angezeigt.
Wird die Signatur im Detail geprüft, lautet die Meldung, dass
a) die E-Mail verändert worden sei.
Ursache:
1.Die E-Mail wurde zwischen SEPPmail Secure E-Mail Gateway und E-Mail Client durch einen unbefugten Dritten verändert.
Bei korrekter Konfiguration der Systeme ist der Weg vom SEPPmail Secure E-Mail Gateway bis zum E-Mail Client verschlüsselt und diese Möglichkeit somit ausgeschlossen.
2.Zwischen SEPPmail Secure E-Mail Gateway und dem E-Mail Client wurde die E-Mail durch ein dazwischen liegendes Relay verändert (zum Beispiel ein Zeilenumbruch oder ähnliches).
Individuelle Abhilfe:
In diesem Fall wären die dazwischenliegenden Relays zu prüfen.
3.Der Absender hat beim Signieren der E-Mail das Padding-Verfahren RSA-PSS verwendet, der E-Mail Client kann jedoch mit diesem Verfahren nicht umgehen.
RSA-PSS wird zum Beispiel nach EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) gefordert. Da das SEPPmail Secure E-Mail Gateway mit diesem Standard umgehen kann, wird die Signatur hier als gültig erkannt. Da die meisten E-Mail Clients jedoch nicht mit RSA-PSS umgehen können, erkennen diese die Signatur als ungültig.
Individuelle Abhilfe:
Erfolgreich geprüfte Signaturen sollten vom SEPPmail Secure E-Mail Gateway abgeschnitten werden (siehe Mail Processing Ruleset generator Signing Incoming e-mails Remove signature if S/MIME signature check succeeds).
|
Aufgrund dieser Problematik wird dringend vom Verwenden des Padding-Verfahrens RSA-PSS als globale Einstellung für das Signieren abgeraten. |
b) das Zertifikat von einer unbekannten Zertifizierungsstelle stammt
Ursache:
4.Die ausstellende CA ist am SEPPmail Secure E-Mail Gateway unter «X.509 Root Certificates» vorhanden und als «trusted» eingestuft.
Im E-Mail Client ist dieselbe CA nicht bekannt oder als «untrusted» eingestuft.
5.Die Signatur wurde beim Absender nicht RFC konform erstellt. Benötigte Zwischenzertifikate fehlen.
Auf dem SEPPmail Secure E-Mail Gateway sind die fehlenden Zwischenzertifikate bekannt, weshalb die Zertifikatskette nachvollzogen und die Herkunft des Zertifikats dennoch festgestellt werden kann.
Am E-Mail Client sind die Zwischenzertifikate nicht bekannt. Die Zertifikatskette ist dort somit nicht bekannt. Die Herkunft des Zertifikats kann somit nicht festgestellt werden.
Individuelle Abhilfe:
Zwischenzertifikate dezentral in den E-Mail-Clients importieren.
c) der Absender der E-Mail nicht mit dem Antragsteller des Zertifikats in der Signatur übereinstimmt.
Ursache:
Für das Verifizieren des Absenders einer E-Mail prüft das SEPPmail Secure E-Mail Gateway sowohl den FROM-, wie auch den SENDER- Header auf das Übereinstimmen mit dem Antragsteller des Zertifikates.
Der eingesetzte E-Mail Client prüft anhand anderer Kriterien auf das Übereinstimmen des Absenders mit dem Antragsteller des Zertifikates.
Individuelle Abhilfe:
Erfolgreich geprüfte Signaturen sollten vom SEPPmail Secure E-Mail Gateway abgeschnitten werden (Remove signature if S/MIME signature check succeeds).
Generelle Abhilfe:
In der SEPPmail Secure E-Mail Gateway Konfiguration sollten erfolgreich geprüfte Signaturen abgeschnitten werden (siehe Mail Processing Ruleset generator Signing Incoming e-mails Remove signature if S/MIME signature check succeeds).
