Sophos Email: S/MIME-Verschlüsselung einrichten und betreiben

S/MIME in Sophos Email verbindet drei voneinander abhängige Ebenen: den globalen S/MIME-Dienst, passende Zertifikate und eine Secure Message Policy. Erst ein Test über alle drei Ebenen belegt, dass eine Nachricht signiert, verifiziert, verschlüsselt oder entschlüsselt wird. Dieser Ablauf betrifft die S/MIME-Verarbeitung durch Sophos Email in Sophos Fusion (ehemals Sophos Central). SMTP-TLS schützt dagegen die Transportverbindung, Sophos Secure Message Portal ist ein anderes Verschlüsselungsverfahren und die S/MIME Certificate API gehört in einen eigenen Automatisierungsablauf.

Warnung: Reset ist keine normale Fehlerbehebung. Die Aktion löscht den lokalen CA-Datensatz sowie alle lokalen und externen Zertifikate, entfernt die privaten Schlüssel und schaltet S/MIME aus. S/MIME-Einstellungen in Policies bleiben bestehen. Ein heruntergeladenes PEM-Root-Zertifikat kann weder die CA noch private Schlüssel wiederherstellen. Reset deshalb nur mit genehmigtem Change und vollständigem Wiederaufbauplan ausführen, der festhält, welche autorisierten PKCS#12-Dateien tatsächlich erneut importiert werden können und welche von Sophos erzeugten Schlüssel endgültig verloren gehen.

Voraussetzungen und Verantwortlichkeiten klären

Vor der Konfiguration benötigt man:

eine Lizenz beziehungsweise ein Entitlement, das S/MIME umfasst; im EMS mode lässt sich die globale Einstellung nicht konfigurieren;
einen Sophos Fusion-Administrator mit Zugriff auf Global Settings > Products and Services > Email > S/MIME und auf My Products > Email Security > Policies;
je interner Identität die genaue, in Sophos Fusion vorhandene E-Mail-Adresse;
bei eigenen Zertifikaten eine passwortgeschützte PKCS#12-Datei mit .p12, Zertifikat und privatem Schlüssel;
für externe Empfänger deren S/MIME-Zertifikate oder einen kontrollierten Weg, diese aus verifizierten signierten Nachrichten zu übernehmen;
Owner für CA, Zertifikate, Passwörter, Erneuerung und Notfallwiederherstellung.

Der Change erfasst vorab den aktuellen S/MIME-Status, Policy-Scope und -Reihenfolge, alle vorhandenen Zertifikate mit E-Mail-Adresse, Aussteller, Fingerprint und Ablaufdatum sowie Testpartner und Abnahmekriterien. Private Schlüssel und PKCS#12-Passwörter gehören in den freigegebenen Secret- beziehungsweise Zertifikatsspeicher, nicht ins Ticket. Sophos bietet keine Sperrung von S/MIME-Zertifikaten an; bei Kompromittierung muss das betroffene Zertifikat ersetzt und bei den Kommunikationspartnern ausgetauscht werden.

Zertifikatsmodell und Zuordnung

Beim ersten Setup muss in Sophos Email immer eine lokale CA erstellt werden, auch wenn bereits Zertifikate einer internen oder öffentlichen CA verwendet werden. Die neue lokale CA muss danach nicht zum Ausstellen der Benutzerzertifikate verwendet werden. Dokumentiere Organisationsdaten und Fingerprint. Das selbstsignierte Root-Zertifikat kann im PEM-Format als öffentliches Vertrauensmaterial heruntergeladen und externen Partnern übergeben werden. Das PEM enthält keinen privaten Schlüssel und ist keine wiederherstellbare Sicherung der lokalen CA.

User Certificates gehören zu internen Sophos Fusion-Benutzern. Sophos verwendet sie, um ausgehende Nachrichten im Namen des Benutzers zu signieren und eingehende verschlüsselte Nachrichten zu entschlüsseln. Jeder teilnehmende Benutzer benötigt ein eigenes, zur E-Mail-Adresse passendes Zertifikat. Beim Upload muss die Adresse einen bestehenden Benutzer eindeutig treffen; andernfalls wird Full name nicht gefüllt und der Upload schlägt fehl. Ein Upload ersetzt das vorhandene Benutzerzertifikat.

S/MIME CAs enthalten zusätzlich vertraute Aussteller für die Prüfung eingehender Signaturen. Vor einem Upload prüft man, ob Sophos die CA bereits global erkennt. External S/MIME Certificates gehören zu externen Kommunikationspartnern und ermöglichen insbesondere verschlüsselte Antworten an diese Empfänger. Diese drei Bestände dürfen im Inventar nicht vermischt werden.

S/MIME aktivieren und lokale CA erstellen

Öffne Global Settings > Products and Services > Email > S/MIME.
Aktiviere auf Secure MIME Settings die Option S/MIME.
Entscheide separat über Enable automatic S/MIME certificate extraction. Die Automatik speichert ein Zertifikat nur aus einer eingehenden signierten Nachricht, deren Signatur erfolgreich verifiziert wurde.
Erstelle die zwingend erforderliche lokale CA mit den freigegebenen Organisations- und CA-Daten.
Notiere Fingerprint und Erstellungszeit, lade das öffentliche Root-Zertifikat im PEM-Format zur kontrollierten Vertrauensverteilung herunter und prüfe es gegen den dokumentierten Fingerprint. Behandle das PEM nicht als CA- oder Private-Key-Backup.

Automatische Extraktion setzt ausserdem voraus, dass Verify inbound message in der zutreffenden Secure-Message-Policy aktiv ist. Ist die Prüfung ausgeschaltet, wird trotz aktivierter Extraktion kein Zertifikat übernommen. Das verhindert, dass ungeprüfte Zertifikate in den Vertrauensbestand gelangen. Wenn der Betrieb nur verschlüsseln und keine Signaturen prüfen soll, müssen externe Zertifikate manuell hochgeladen werden; manuell hochgeladene Zertifikate gelten dabei als vertraut.

Interne Benutzerzertifikate bereitstellen

Für ein von Sophos erzeugtes Zertifikat:

Öffne User Certificates > Add user.
Gib unter Email address die bestehende Sophos Fusion-Adresse ein und kontrolliere den automatisch gefüllten Full name.
Klicke auf Add. Sophos erstellt das individuelle Zertifikat automatisch.

Für mehrere Benutzer verwendet man Import users mit einer CSV- oder TXT-Datei, die pro Zeile genau eine gültige E-Mail-Adresse eines vorhandenen Sophos Fusion-Benutzers enthält. Nach dem Import gleicht man erfolgreiche Einträge und Fehler gegen die Soll-Liste ab.

Für ein vorhandenes Zertifikat:

Prüfe vorab Subject/SAN-E-Mail-Adresse, Aussteller, Gültigkeitszeitraum, Verwendungszweck, Schlüssellänge und vorhandenen privaten Schlüssel.
Konvertiere eine PFX-Datei bei Bedarf mit einem freigegebenen Werkzeug in einen passwortgeschützten PKCS#12-Container mit .p12.
Wähle User Certificates > Upload certificate, gib die bestehende Benutzeradresse und das PKCS#12-Passwort ein, wähle die Datei und klicke auf Upload.
Bestätige danach Adresse, Aussteller, Fingerprint und Ablaufdatum. Da der Upload ein bestehendes Zertifikat ersetzt, muss sein Rückweg vorab feststehen.

Ein heruntergeladenes Benutzerzertifikat enthält nur öffentliches Vertrauensmaterial, niemals den privaten Schlüssel, und liegt als verschlüsselte PKCS#12-Datei vor. Es kann den Signatur- oder Entschlüsselungsschlüssel des Benutzers daher nicht wiederherstellen. Man verteilt es an Partner, deren System Zertifikate nicht automatisch aus signierten Nachrichten extrahiert oder die eigene CA nicht kennt. Bei ausgehenden Nachrichten hängt Sophos das Benutzerzertifikat an, nicht das CA-Zertifikat, mit dem es signiert wurde.

Vertrauens- und Empfängerzertifikate hinzufügen

Unter S/MIME CAs vergleicht man Aussteller und Zertifikatskette mit den von Sophos bereits als global erkannt angezeigten CAs. Upload wird nur verwendet, wenn die benötigte CA dort fehlt. Vorher verifiziert man Datei, Fingerprint und Herkunft über einen unabhängigen, freigegebenen Kanal. Für einen einzelnen externen Empfänger lädt man dessen Zertifikat unter External S/MIME Certificates > Upload hoch oder lässt es aus einer erfolgreich verifizierten, signierten eingehenden Nachricht extrahieren. Danach kontrolliert man Identität, E-Mail-Adresse, Aussteller, Fingerprint und Gültigkeit.

Ein Zertifikat darf nicht nur nach Dateiname oder Anzeigename zugeordnet werden. Stimmen E-Mail-Adresse oder Vertrauenskette nicht, wird es nicht durch eine breite CA-Freigabe passend gemacht. Stattdessen korrigiert der Zertifikats-Owner das Zertifikat beziehungsweise die Zuordnung.

Secure-Message-Policy zuweisen

Erst wenn die Zertifikate vorhanden sind, öffnet man My Products > Email Security > Policies und erstellt oder ändert eine Policy der Familie Secure Message. Man dokumentiert:

internen Benutzer-, Gruppen- oder Domain-Scope und gegebenenfalls den externen Partner-Scope;
Richtung und gewünschtes Verhalten für Signieren, Verifizieren, Verschlüsseln und Entschlüsseln;
Policy-Reihenfolge und Enforcement-Status;
Pilotbenutzer und Kontrollbenutzer ausserhalb des Scopes.

Man startet mit einem kleinen Pilot-Scope. Die globale S/MIME-Aktivierung allein erzwingt keine gewünschte Nachrichtenbehandlung; umgekehrt kann eine erhalten gebliebene Policy nach einem Reset nicht funktionieren, bis S/MIME und lokale CA neu konfiguriert sowie die benötigten Zertifikate erneut importiert oder erzeugt wurden.

Sende- und Empfangsverhalten abnehmen

Für jede Nachricht notiert man Zeitpunkt, Richtung, Envelope-Absender, Envelope-Empfänger und Message-ID. Der Testplan umfasst mindestens:

eine normale unsignierte eingehende und ausgehende Kontrollnachricht;
eine ausgehende signierte Nachricht eines Pilotbenutzers, die der externe Partner erfolgreich verifiziert;
eine eingehende signierte Nachricht einer vertrauten externen Identität, deren Signatur Sophos erfolgreich prüft;
eine ausgehende verschlüsselte Nachricht an einen Empfänger mit passendem externem Zertifikat, die nur der vorgesehene Empfänger entschlüsseln kann;
eine eingehende verschlüsselte Nachricht an einen internen Benutzer mit passendem Zertifikat und privatem Schlüssel;
bei aktivierter Extraktion eine verifizierte signierte Nachricht eines Testpartners und anschliessend eine verschlüsselte Antwort.

Zusätzlich prüft man beim externen Partner das verwendete Absenderzertifikat und die Vertrauenskette und kontrolliert in Sophos Fusion das beobachtete Nachrichtenresultat. Ein sichtbares S/MIME-Symbol im Mailclient oder eine erfolgreiche Zustellung allein beweist weder die richtige Policy noch die richtige Zertifikatsidentität. Negativtests verwenden eine kontrolliert falsche Empfängeridentität, ein abgelaufenes Testzertifikat oder einen nicht vertrauten Testaussteller nur in einer isolierten Pilotbeziehung; produktive Schlüssel werden nicht absichtlich beschädigt.

Technische Grenzen einplanen

Unterstützt werden Zertifikate nach S/MIME Version 3 Message Specification oder neuer.
Bei RSA/DSA akzeptiert Sophos keine Schlüssel unter 1024 Bit, bei EC keine Kurve unter P-224. Schwache Schlüssel werden nicht hochgeladen. Für neue eigene Zertifikate gelten die strengeren Vorgaben der eigenen PKI.
Von Sophos erzeugte Zertifikate verwenden SHA-256, RSA mit 2048 Bit und AES-256 CBC für den Inhalt. Hochgeladene Zertifikate behalten ihren unterstützten RSA-, DSA- oder EC-Algorithmus; die Inhaltsverschlüsselung ist AES-256 CBC.
Nicht MIME-konforme ausgehende Nachrichten werden möglicherweise nicht mit S/MIME verarbeitet.
Signierte Nachrichten zwischen Sophos Email Security und Sophos UTM können nicht verifiziert werden, wenn SMTP-Envelope-From und RFC822-From voneinander abweichen.
Wird ein bereits gespeichertes Absenderzertifikat extern erneuert, kann die erste Nachricht mit dem neuen Zertifikat abgewiesen werden. Sophos speichert das extrahierte neue Zertifikat; die nächste und weitere Nachrichten werden danach akzeptiert.

Erneuerung, Entfernung und Rollback

Mindestens 60, 30 und 14 Tage vor Ablauf prüft der Zertifikats-Owner Inventar und Kommunikationspartner. Ein neues internes Zertifikat wird zuerst auf E-Mail-Adresse, privaten Schlüssel und Vertrauenskette geprüft. Danach führt man den ersetzenden Upload in einem Wartungsfenster aus und wiederholt die Signatur- und Verschlüsselungstests in beiden Richtungen. Historische Inhalte lassen sich nur mit dem zugehörigen alten privaten Schlüssel entschlüsseln. Dieser darf nur als autorisiertes, passwortgeschütztes PKCS#12-Archiv gemäss Aufbewahrungsrichtlinie erhalten bleiben. Für von Sophos erzeugte Zertifikate gibt es keinen unterstützten Export des privaten Schlüssels; deshalb darf nach deren Ersatz oder nach einem Reset keine historische Entschlüsselung versprochen werden.

Bei einem externen Zertifikatswechsel plant man die dokumentierte mögliche Ablehnung der ersten signierten Nachricht ein oder lädt das neue Zertifikat vorab über einen verifizierten Kanal hoch. Nach erfolgreicher Abnahme entfernt man veraltete externe Zertifikate und nicht mehr benötigte CA-Einträge gezielt. Benutzer-Offboarding umfasst Policy-Scope, User Certificate, externe Vertrauensbeziehungen, Backup-Aufbewahrung und einen Abschluss-Test; es ist kein Anlass für einen tenantweiten Reset.

Scheitert ein Pilot, setzt man die neue Secure-Message-Policy auf den vorherigen Enforcement-Status zurück, stellt ihre Reihenfolge wieder her und entfernt nur die im Change neu hinzugefügten Zertifikate beziehungsweise CA-Einträge. Anschliessend bestätigt man mit Kontrollnachrichten den vorherigen Mailfluss. Ein Reset ist nur der letzte, genehmigte Wiederaufbauweg.

Fehler systematisch eingrenzen

Menü oder Schalter fehlt: Entitlement, Admin-Rolle und EMS mode prüfen.
Upload schlägt fehl: .p12, Passwort, vorhandenen privaten Schlüssel, S/MIME-Version, Algorithmus und Mindestschlüssellänge prüfen. Danach bestätigen, dass die E-Mail-Adresse als bestehender Sophos Fusion-Benutzer erkannt und Full name gefüllt wird.
Signatur wird nicht vertraut: Gültigkeit, Fingerprint, vollständige Kette und passende S/MIME CA prüfen. Vor einem CA-Upload kontrollieren, ob Sophos den Aussteller bereits global erkennt.
Automatische Extraktion bleibt leer: Sicherstellen, dass die Nachricht eingehend und signiert war, die Signatur erfolgreich verifiziert wurde, Enable automatic S/MIME certificate extraction aktiv ist und die passende Policy Verify inbound message nicht deaktiviert.
Ausgehende Verschlüsselung fehlt: Policy-Scope und -Reihenfolge sowie das gültige, zur Empfängeradresse passende External S/MIME Certificate prüfen.
Eingehende Nachricht lässt sich nicht entschlüsseln: internes Benutzerzertifikat, privaten Schlüssel, Empfängeradresse, Ablaufdatum und einen möglicherweise überschreibenden Zertifikatsupload prüfen.
Nur die erste Nachricht nach Erneuerung scheitert: das bekannte Extraktionsverhalten bei neuem Absenderzertifikat berücksichtigen, gespeicherten Fingerprint kontrollieren und mit einer zweiten kontrollierten Nachricht testen.
Verarbeitung bleibt unerwartet: MIME-Konformität sowie bei Sophos UTM die Übereinstimmung von SMTP-Envelope-From und RFC822-From prüfen.

Für eine Eskalation sammelt man Message-IDs, UTC-Zeit, Richtung, Envelope-Adressen, Policy-Scope und -Reihenfolge, Zertifikats-Subject, Aussteller, Fingerprint, Ablaufdatum und den exakten Fehlertext. Private Schlüssel, PKCS#12-Dateien und Passwörter werden niemals an ein normales Ticket angehängt.