This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Email Verschlüsselung SG UTM

Hallo,

ich habe eine Frage zu der Email Verschlüsselung auf der SG UTM mit S/MIME. Ist es möglich die Email Verschlüsselung auf bestimmte Domains, Unternehmen etc. einzuschränken?

Das Problem ist, das externe Empfänger die Stammzertifizierungsstelle der UTM nicht kennen bzw. vertrauen. Dieses Zertifikat muss erst mit den Unternehmen ausgetauscht bzw. bei dem Zielunternehmen eingebunden werden, damit diese keine Fehlermeldung bekommen.

Daher möchte ich nur mit den Unternehmen signierte und verschlüsselte Emails austauschen, mit denen ich diese Daten bereits ausgetauscht bzw. besprochen habe.

Aber auf der UTM habe ich bisher keine Option gefunden das einzuschränken. Somit kommen auch signierte Emails bei Unternehmen an, mit denen wir bisher nichts ausgetauscht haben. Das Problem hierbei ist, das dort dann natürlich eine Fehlermeldung kommt, das die Signatur ungültig ist, da die Stammzertifizierungsstelle auf der UTM ja immer eine selbst signierte Stammzertifizierungsstelle ist.

Das führt bei den Empfängern zu Verunsicherung und zu Problemen. Kann ich irgendwie einschränken, mit wem signierte und verschlüsselte Emails ausgetauscht werden?



This thread was automatically locked due to age.
Parents
  • Hallo,

    nein, so ein Feature bringt die UTM m.E. nicht mit. Der Mechanismus der UTM sieht folgende Konfiguration vor:

    - Als Absender immer signieren und ggf. verschlüsseln (sofern der public-key des Empfängers bereits bekannt ist bzw. von der UTM automatisch ausgelesen wurden)
    - Das automatische Auslesen funktioniert ebenfalls nur über offizielle S/MIME-Zertifikate (self signed ist hier raus - dafür muss die CA des Gegenüber eingespielt werden)

    Generell würde ich von der Verwendung von self-signed Zertifikaten komplett absehen, das führt nur zu Irritationen und Mehraufwand auf beiden Seiten. Wenn der Gegenüber z.B. keine zentrale Lösung wie eine UTM besitzt und das ganze im Client macht, muss beim On-Boarding neuer Mitarbeiter das ganze immer nachgezogen werden und so weiter.. das "Spielchen" würde ich z.B. nicht mitmachen.

    Ein offizielles Zertifikat kostet ja nicht die Welt und wenn es mehr als 20 Mitarbeiter sind, würde ich eine MPKI empfehlen, da bist du komplett flexibel und schnell bei der Ausstellung neuer Zertifikate, kannst problemlos Zertifikate ungültig erklären, usw.

    Das ganze Thema mit der CRLs / OCSP ist somit auch erledigt. Bei self-signed müsstest du ja konsequenterweise die CRLs oder OCSP online zur Verfügung stellen, damit bei ausgeschiedenen Mitarbeitern das Zertifikat ungültig erklärt wird. In deinem Szenario bedeutet das, du musst allen Kommunikationspartnern mit Verschlüsselung die ungültigen Zertifikate mitteilen - nicht praxistauglich.

    Leider gibt es ja für S/MIME noch keine Lösung wie z.B. Let's encrypt für SSL-Zertifikate. Hier warte ich auch darauf, dass sich jemand diesem Thema mal annimmt.

    Zum Vergleich (soll keine Werbung darstellen, ist lediglich meine persönliche Vorliebe) - Ich selbst betreibe bei meinen Kunden meist eine MPKI von swissSign in der Ausprägung "E-Mail ID silver (DV)" und stelle die Zertifikate für 3 Jahre aus, das macht dann pro Benutzer im Jahr Stand heute 17,- EUR.

Reply
  • Hallo,

    nein, so ein Feature bringt die UTM m.E. nicht mit. Der Mechanismus der UTM sieht folgende Konfiguration vor:

    - Als Absender immer signieren und ggf. verschlüsseln (sofern der public-key des Empfängers bereits bekannt ist bzw. von der UTM automatisch ausgelesen wurden)
    - Das automatische Auslesen funktioniert ebenfalls nur über offizielle S/MIME-Zertifikate (self signed ist hier raus - dafür muss die CA des Gegenüber eingespielt werden)

    Generell würde ich von der Verwendung von self-signed Zertifikaten komplett absehen, das führt nur zu Irritationen und Mehraufwand auf beiden Seiten. Wenn der Gegenüber z.B. keine zentrale Lösung wie eine UTM besitzt und das ganze im Client macht, muss beim On-Boarding neuer Mitarbeiter das ganze immer nachgezogen werden und so weiter.. das "Spielchen" würde ich z.B. nicht mitmachen.

    Ein offizielles Zertifikat kostet ja nicht die Welt und wenn es mehr als 20 Mitarbeiter sind, würde ich eine MPKI empfehlen, da bist du komplett flexibel und schnell bei der Ausstellung neuer Zertifikate, kannst problemlos Zertifikate ungültig erklären, usw.

    Das ganze Thema mit der CRLs / OCSP ist somit auch erledigt. Bei self-signed müsstest du ja konsequenterweise die CRLs oder OCSP online zur Verfügung stellen, damit bei ausgeschiedenen Mitarbeitern das Zertifikat ungültig erklärt wird. In deinem Szenario bedeutet das, du musst allen Kommunikationspartnern mit Verschlüsselung die ungültigen Zertifikate mitteilen - nicht praxistauglich.

    Leider gibt es ja für S/MIME noch keine Lösung wie z.B. Let's encrypt für SSL-Zertifikate. Hier warte ich auch darauf, dass sich jemand diesem Thema mal annimmt.

    Zum Vergleich (soll keine Werbung darstellen, ist lediglich meine persönliche Vorliebe) - Ich selbst betreibe bei meinen Kunden meist eine MPKI von swissSign in der Ausprägung "E-Mail ID silver (DV)" und stelle die Zertifikate für 3 Jahre aus, das macht dann pro Benutzer im Jahr Stand heute 17,- EUR.

Children
  • Vielen Dank für die Antwort.

    Ich werde mir das einmal genauer anschauen.

    Ich habe aber noch ein weiteres Problem, das selbst bei öffentlichen SMIME Zertifikaten auftritt. Das Problem ist das die Gegenseite alle Ihre Emails mit einem Zertifikat verschlüsselt und signiert. Zum Beispiel steht dort, das die Email von Max.Mustermann@domain.de ist und signiert von Admin@domain.de

    Das Problem ist das die Gegenseite zu mir verschlüsselt senden kann, ich aber nicht zu dieser. Denn die UTM hat „nur“ das Zertifikat für Admin@domain.de. Schicke ich dort eine Email hin wird diese verschlüsselt. Doch schicke ich an Max.Mustermann@domain.de, wird diese nicht verschlüsselt. Kann man der UTM irgendwie beibringen, das sie für alle Adressen von @domain.de immer das Zertifikat Admin@domain.de verwendet?

    Die Gegenseite verwendet nämlich ein Email Gateway und daher wird dort alles über ein Zertifikat geregelt.

    Kennt ihr dort eine Lösung?