S/MIME-Zertifikate zur sicheren E-Mail-Kommunikation

Damit man sicher E-Mail austauschen kann, sollten die Gesprächspartner über S/MIME-Zertifikate verfügen.

Hierüber können Mails mit einem Stempel/Signum versehen werden und bescheinigen einen vertrauenswürdigeren Eindruck, da der Stempel/ Signum bescheinigt, dass die E-Mail auch tatsächlich von der E-Mail-Adresse (Class1) oder der echten Person mit seiner E-Mail-Adresse (Class2) stammt. E-Mails mit Signum können an jede andere Person/ E-Mail-Adresse versendet werden.

Zudem kann man aber auch untereinander verschlüsselte E-Mails schicken. Hierbei wird der E-Mail-Text (Body) und deren Anlagen verschlüsselt und kann nur vom Gesprächspartner geöffnet/ gelesen werden. Zu beachten ist jedoch, dass der Betreff einer E-Mail NIE verschlüsselt wird.

Dies grob zur Verwendung von E-Mail-Zertifikaten. Nun kommt es zum spezifischen …

Egal ob mit eigener CA und über Drittanbieter (z.B. Certum), unter Office 365 lassen sich die .pfx-Zertifikate nicht gleichermassen nutzen.

In Microsoft Office Outlook als Desktop-App ist das Einrichten und Verwenden von S/Mime-Zertifikaten recht schnell und einfach umgesetzt.
Auch das Einrichten auf mobilen Geräten (z.B. iPad/ iPhone) gestaltet sich einfach, solange man dort nur die Apple-Mail-App verwendet.

Möchte ich jedoch die Microsoft Outlook App für iOS oder Android nutzen und soll dort ein S/Mime-Zertifikat zum Einsatz kommen, fangen die Probleme an!!

Wie sehen die Probleme aus?

Zum einem reicht das Installieren eines Zertifikates über die Profile von Apple nicht aus. So installierte Zertifikate werden in der Outlook iOS-App nicht gefunden.

Desweiteren unterscheidet Outlook iOS zwischen Business- und privaten Mail-Accounts. Wer sich bei Microsoft eine *@outlook.com-Adresse privat zulegt, der kommt innerhalb der Outlook iOS-App nie in das Vergnügen ein Zertifikat sich einrichten zu können. Die Installation selbst funktioniert, aber für das Aktivieren fehlt der Menüpunkt „Sicherheit“ unter den Mailkonten-Einstellungen.

Anders bei geschäftlichen Account. Dort steht der Menüpunkt „Sicherheit“ zur Verfügung und man kann beginnen sich das Zertifikat zu Installieren/ Einzurichten.

Zum Installieren in Outlook für iOS muss man sich am besten das .pfx-Zertifikat selbst per Mail an sich selbst senden. Erst jetzt kann man es durch Öffnen der Datei so installieren, dass es in Outlook für iOS zu sehen und einzurichten geht.

Über den Menüpunkt „Sicherheit“ aktiviert man die generelle Funktion S/MIME. Danach sieht man unter Zertifikate alle Zertifikate, welche zu seiner E-Mail-Adresse installiert worden sind. Hier findet demnach ein Abgleich statt, so dass man kein Zertifikat für eine andere ausgestellte E-Mail-Adresse aktivieren kann.

Leider kam nun die nächste böse Überraschung! Das aktivieren von Signieren und Verschlüsseln war nicht möglich, weil im Zertifikat bei Überprüfung „nicht vertrauenswürdig“ stand?

Laut Microsoft und Telekom-Support ist mal wohl gezwungen sich eine Office 365-Liznez zu erwerben, in der Intune mit enthalten ist 🙁
Aus meiner Sicht ist dies aber eine FEHLINFORMATION, weil es mit einem kleinen Zusatzschritt doch möglich wird.

Outlook für iOS prüft das S/Mime-Zertifikat mit seinem in O365 hinterlegten Stamm-Zertifikaten. Passen diese nicht zusammen, so wird IMMER innerhalb der App die Validierung des S/Mime-Zertifikates schiefgehen.

Was muss man also machen?

Man benötigt eine .SST-Datei, in der das Root- & die Zwischenzertifizierungsstellen eingebunden sind. Diese .SST muss dann nur noch nach O365 importiert werden. Den Usern schiebt man noch schnell das öffentliche Zertifikat im O365 unter und fügt bei AD-Connect-Nutzung auch das öffentliche Zertifikat (.cer) über den lokalen Domain-Controller das Zertifikat hinzu. Und dann wird am Client das Zertifikat als gültig angezeigt und kann für das Signieren und Verschlüsseln verwendet werden.

    1. Root- & Intermediante-Zertifikate als .SST-File nach O365 exportieren

Eigene Windows-CA

Hier exportiert man aus dem Zertmanager die erforderlichen Root- und Zwischenzertifikate als .SST

Fremde CA

Hat man Zertifikate von Drittdienstleistern wie Certum, dann schaut man in einem bereits erstellen S/Mime-Zertifikat und analysiert hier die Zischen- und das Root-Zertifikat.

Im Normalfall findet man diese bereits auf jedem Win10/11-PC im Zertifikatsspeicher unter Zwischenzertifikate oder Stammzertifikate. Die gesamte Kette der Zertifikate wird selektiert und als .SST exportiert.

Wenn die Zertifikate nicht im Zertspeicher sind, dann werden die darüber ausgestellten (S/Mime)-Zertifikate bei Nutzung oft nicht als vertrauenswürdig angesehen.

Es hilft hier diese Zertifikate manuell zu importieren/ installieren und dann als .SST zu exportieren.

Unterschiedliche CA’s

Im Prinzip kann man jedes Austellerzertifikat als .SST exportieren. Hat man eine Mischung aus mehreren Anbietern, dann markiert man alle benötigten Stammzertifikate und exportiert diese als Bundle in eine .SST.

Certum

[Root]

Certum Trusted Network CA

S/N 0444c0

22.10.2008 – 31.12.2029

[Zwischenhändler]

Austeller: Certum Trusted Network CA

Certum Digital Identification CA SHA2

S/N 66daef03db8461916b25ba83fb174e13

21.04.2015 – 09.06.2027

[User]

Austeller: Certum Digital Identification CA SHA2

[UserMail-Adresse] (S/Mime-Class2)

S/N 5732e6eaaf1468660cc0d3bd04e29b05

01.02.2022 – 24.01.2025

Import .SST in O365

Mit Exchange verbinden (Powershell)

$sst = Get-Content -path „c:\temp\firmenca.sst“ -Encoding Byte

Set-SmimeConfig -SMIMECertificateIssuingCA $sst

 

    1. Im AD die öffentlichen Zertifikate hinterlegen

Da wir AD-Connect nutzen, sollte bei jedem User das öffentliche Zertifikat (.cer) hinterlegt werden.

Im Attribut-Editor sollte dann auch unter userCertificate ein Eintrag pro hinterlegten Zertifikat stehen.

    1. In O365 die öffentlichen Zertifikate dem User hinterlegen

Mit Exchange verbinden (Powershell)

$cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(„D:\_tmp\cert.cer“)

$certArray = New-Object System.Collections.ArrayList

$certArray.Insert(0,$cert.GetRawCertData())

Set-Mailbox -Identity <Mail-Adresse des Users> -UserCertificate $certArray -UserSMimeCertificate $certArray

 

Apple-Sicherheit

Auch die Apple-ID und deren verbundene Geräte müssen besser geschützt werde.

Auch hier gilt „mehr Bequemlichkeit = höhere Angriffsfläche“ hierzu ein Link von Heise -> Diebe räumen Bankkonten nur mit Apple-ID und Passcode ab

Eine Empfehlung

Richtet Euch über die Bildschirmzeit wichtige Apps mit einer Nutzungsdauer von 1 Min ein und vergebt einen Bildschirm-Freigabe-Code, der nicht dem Handy-Entsperrcode/ Passcode entspricht.

Ebenso darf das Ändern von Einstellungen/ Accounts etc. nur mit dem Bildschirmcode erlaubt werden.

Letztlich nutzte ich die Bildschirmzeit ehr für die Kinder, aber clever eingesetzt, kann diese Funktion die Sicherheit der eigenen Geräte erheblich steigern.