S/MIME für Exchange Online — ADCS-Templates und Rollout

Wie du Mail-Verschlüsselung sauber aus der eigenen PKI in die Cloud bringst — ohne dir die erste Datenverlust-Falle selbst zu bauen.

Kurzfassung vorab

S/MIME für Exchange Online ist kein Cloud-Feature, das du irgendwo anklickst — es ist ein Vertrauenspfad, der in deiner internen ADCS-CA beginnt und erst in Outlook endet. Die entscheidende Wahrheit vorweg: Verschlüsseln scheitert fast nie an der CA, sondern am userCertificate-Attribut und am Sync. Wer das nicht von Anfang an mitdenkt, baut eine PKI, die wunderbar Zertifikate ausstellt, mit denen Outlook trotzdem nichts verschlüsseln kann. Und ganz wichtig: Key-Archival für die Verschlüsselungs-Zertifikate ist keine Kür, sondern die Versicherung gegen den Tag, an dem ein Postfach migriert wird und drei Jahre verschlüsselte Mails plötzlich unlesbar sind.

Abb. 1: Der vollständige S/MIME-Vertrauenspfad — von der Offline Root bis zum Signieren in Outlook und OWA.

1. Warum S/MIME aus ADCS und nicht aus der Cloud

Microsoft bietet für reine Cloud-Geräte mit Microsoft Cloud PKI inzwischen einen eigenen Weg an — aber für S/MIME bleibt ADCS in den allermeisten Mittelstandsumgebungen die richtige Quelle. Der Grund ist banal und entscheidend zugleich: Du kontrollierst die Templates, die Schlüssellängen, die Gültigkeitsdauer und vor allem das Key-Archival. Bei einer öffentlichen S/MIME-CA zahlst du pro Zertifikat und gibst die Schlüsselverwaltung aus der Hand. Bei ADCS stellst du unbegrenzt aus, kostenlos, und behältst die Hoheit über die archivierten privaten Schlüssel.

Der Klassiker, den ich im Consulting immer wieder sehe: Eine Firma hat S/MIME irgendwann mit gekauften Zertifikaten von Hand verteilt, dann ist der Mitarbeiter gegangen, der das gemacht hat, und niemand weiß mehr, wo die privaten Schlüssel liegen. Mit einer sauberen ADCS-Lösung samt Auto-Enrollment und Key-Archival passiert das nicht — die CA-Datenbank ist deine Single Source of Truth.

Wo Cloud PKI wirklich passt

Microsoft Cloud PKI als Teil der Intune Suite ist stark für Geräte-Zertifikate auf reinen Cloud-Clients. Für S/MIME, das nutzergebunden ist und ins Verzeichnis veröffentlicht werden muss, ist es heute keine vollwertige Alternative zu ADCS. Wer also überlegt, mit Cloud PKI gleich S/MIME mitzuerschlagen, sollte das Thema getrennt betrachten — die beiden Anforderungen haben unterschiedliche Lebenszyklen.

2. Signieren und Verschlüsseln sind zwei Baustellen

Das ist der wichtigste konzeptionelle Punkt des ganzen Themas, und er wird ständig übersehen: Signieren und Verschlüsseln stellen völlig unterschiedliche Anforderungen an deine PKI. Signieren brauchst du nur deinen eigenen privaten Schlüssel — geht ein Schlüssel verloren, stellst du einfach neu aus, kein Drama. Verschlüsseln dagegen braucht den öffentlichen Schlüssel des Empfängers, und der muss im Verzeichnis auffindbar sein. Und der eigene private Schlüssel zum Entschlüsseln muss archiviert sein, sonst sind verschlüsselte Altmails beim Schlüsselverlust unwiederbringlich weg.

Abb. 2: Signieren und Verschlüsseln im direkten Vergleich — die roten Felder sind die Stellen, an denen es teuer wird.

Die Konsequenz fürs Template-Design

Ich empfehle in den meisten Projekten getrennte Templates: eines für Signatur, eines für Verschlüsselung mit aktiviertem Key-Archival. Das klingt nach mehr Arbeit, ist aber sauberer — du kannst die Gültigkeitsdauern unterschiedlich setzen, das Archival gezielt nur dort aktivieren, wo es nötig ist, und der Audit-Nachweis wird deutlich einfacher. Wer beides in ein Template kippt, muss Key-Archival für alle aktivieren und sammelt private Signaturschlüssel in der CA-Datenbank an, die da nichts verloren haben.

3. Der Veröffentlichungsfluss — wo es wirklich klemmt

Jetzt zum Kern, an dem die meisten Erstversuche scheitern. Das Zertifikat im lokalen Zertifikatsspeicher des Anwenders reicht nicht, damit andere ihm verschlüsselte Mail schicken können. Der öffentliche Teil muss ins userCertificate-Attribut des Verzeichnisobjekts, und dieses Attribut muss bis nach Exchange Online durchsynchronisiert werden. Erst dann findet Outlook beim Empfänger-Lookup einen Schlüssel.

Abb. 3: Der Ablauf von der Ausstellung bis zur aktiven SMIME-Policy — Schritt 3 und 4 sind die typischen Bruchstellen.

In einer Hybrid-Umgebung mit Entra Connect ist der Weg vergleichsweise komfortabel: Du sorgst dafür, dass das userCertificate-Attribut on-prem befüllt wird (Auto-Enrollment kann das per Template-Einstellung automatisch tun), und Entra Connect nimmt es mit. In einer Cloud-only- oder gemischten Umgebung musst du den öffentlichen Schlüssel aktiv über die Graph API oder per PowerShell ins Cloud-Verzeichnis schieben. Das ist kein Hexenwerk, aber es ist eben ein zusätzlicher, oft vergessener Schritt.

Abb. 4: Entscheidungsbaum — welcher Veröffentlichungsweg zu deiner Umgebung passt.

4. Template aufsetzen und Veröffentlichung prüfen

Für das Verschlüsselungs-Template nimmst du mindestens eine v3-Vorlage (besser v4 auf Windows Server 2022/2025), aktivierst die EKU „Secure Email“ plus „Key Encipherment“, setzt das Recht „Autoenroll“ für die passende Gruppe und hakst beim Key-Archival „Archive subject's encryption private key“ an. Damit das userCertificate-Attribut automatisch befüllt wird, gehört in den Reiter „Subject Name“ die Option, das Zertifikat im Active Directory zu veröffentlichen.

Mit PowerShell kannst du den Zustand schnell prüfen — sowohl die ausgestellten Zertifikate als auch ob das Verzeichnisattribut tatsächlich gefüllt ist:

Der Punkt, der in keiner Microsoft-Doku so deutlich steht: Das letzte Kommando in Exchange Online sagt dir nur, ob die Mailbox grundsätzlich erreichbar ist. Ob S/MIME im Client funktioniert, hängt zusätzlich an der SMIME-Konfiguration der Organisation (Set-SmimeConfig) und am Vertrauen auf das Stammzertifikat. Letzteres ist der Grund, warum du die Root-CA als vertrauenswürdig in die richtigen Stores bringen musst — sonst meckert Outlook bei jeder signierten Mail.

5. Betrieb, Erneuerung und der Tag der Wahrheit

S/MIME-Zertifikate laufen ab, und anders als bei einem TLS-Zertifikat auf dem Webserver merkt es der Anwender erst, wenn das Signieren plötzlich nicht mehr klappt. Auto-Enrollment erneuert automatisch, aber nur, wenn die GPO greift und der Client regelmäßig Kontakt zur Domäne hat. Genau hier wird es bei mobilen und Cloud-affinen Belegschaften unangenehm: Ein Notebook, das wochenlang nur im Homeoffice am Cloud-Tenant hängt, bekommt vielleicht keine Erneuerung mehr.

Mein Rat: Setz die Gültigkeitsdauer nicht zu kurz (zwei bis drei Jahre sind für S/MIME üblich) und überwache aktiv, welche Nutzer auf ablaufende Zertifikate zulaufen. Und denk an die Archivierung — wenn ein Verschlüsselungs-Zertifikat erneuert wird, muss der alte private Schlüssel weiter verfügbar bleiben, sonst sind die mit dem alten Schlüssel verschlüsselten Mails verloren.

Praxis-Beispiel: Musterwerk GmbH

Die Musterwerk GmbH, ein Industrie-Mittelständler mit rund 1.200 Mitarbeitern, hatte S/MIME über Jahre mit gekauften Einzelzertifikaten betrieben — verteilt von Hand, dokumentiert nirgends. Als die Geschäftsführung verschlüsselte Kommunikation mit einem Großkunden zur Vertragsbedingung machte, flog auf, dass von 40 Schlüsselinhabern bei der Hälfte niemand mehr wusste, wo die privaten Schlüssel lagen.

Wir haben eine saubere ADCS-Lösung aufgesetzt: zwei getrennte Templates für Signatur und Verschlüsselung, Key-Archival aktiviert, Auto-Enrollment per GPO für die relevante OU, und die Veröffentlichung über das schon vorhandene Entra Connect. Der entscheidende Schritt war die Bereinigung des userCertificate-Attributs — bei knapp 200 Nutzern war es schlicht leer. Nach dem Rollout konnte der Großkunde innerhalb von zwei Tagen verschlüsselt mit allen relevanten Ansprechpartnern kommunizieren. Die alten gekauften Zertifikate liefen kontrolliert aus, statt sie panisch zu ersetzen.

Verwandte Themen

Häufige Fragen (FAQ)

Warum kann ich signieren, aber niemandem verschlüsselt schreiben?

Weil zum Verschlüsseln der öffentliche Schlüssel des Empfängers im Verzeichnis stehen muss. Steht beim Empfänger kein Zertifikat im userCertificate-Attribut, findet Outlook keinen Schlüssel und bietet die Verschlüsselung gar nicht erst an. Signieren dagegen braucht nur deinen eigenen Schlüssel und funktioniert deshalb unabhängig davon.

Brauche ich für S/MIME zwingend ADCS, oder reicht Microsoft Cloud PKI?

Für nutzergebundenes S/MIME mit Verzeichnis-Veröffentlichung und Key-Archival ist ADCS heute die deutlich rundere Lösung. Microsoft Cloud PKI ist stark für Geräte-Zertifikate auf reinen Cloud-Clients, deckt den S/MIME-Lebenszyklus aber nicht vollwertig ab. Behandle die beiden Themen getrennt, statt eines mit dem anderen erschlagen zu wollen.

Was passiert mit verschlüsselten Mails, wenn der private Schlüssel verloren geht?

Ohne Key-Archival sind sie unwiederbringlich verloren — niemand kann sie mehr entschlüsseln. Genau deshalb aktivierst du Key-Archival im Verschlüsselungs-Template vor dem Rollout. Nachträglich gilt es nur für ab dann ausgestellte Zertifikate, rettet also keine bereits verschlüsselten Altmails.

Wie kommt das Zertifikat von ADCS nach Exchange Online?

Über das userCertificate-Attribut des Verzeichnisobjekts. In Hybrid-Umgebungen nimmt Entra Connect das Attribut automatisch mit, sofern es on-prem befüllt ist. In Cloud-only-Szenarien schiebst du den öffentlichen Schlüssel aktiv über die Graph API oder PowerShell ins Cloud-Verzeichnis.

Soll ich Signatur und Verschlüsselung in ein Template packen?

Besser nicht. Getrennte Templates erlauben unterschiedliche Gültigkeitsdauern, gezieltes Key-Archival nur für die Verschlüsselung und einen sauberen Audit-Nachweis. Ein kombiniertes Template zwingt dich, auch Signaturschlüssel zu archivieren, was unnötig und sicherheitstechnisch unschön ist.

Warum erneuern sich die Zertifikate bei mobilen Mitarbeitern nicht?

Auto-Enrollment erneuert nur, wenn die GPO greift und der Client regelmäßig Domänenkontakt hat. Notebooks, die wochenlang nur am Cloud-Tenant hängen, erreichen die Issuing CA nicht und laufen irgendwann ab. Eine nicht zu knappe Gültigkeitsdauer und aktives Monitoring der Ablaufdaten entschärfen das Problem.

Nächste Schritte mit boddenberg.de

S/MIME sauber aus ADCS in Exchange Online zu bringen ist machbar — aber der Teufel steckt im Veröffentlichungsfluss und im Key-Archival. Wenn du das nicht zum dritten Mal halb ausrollen willst, lohnt sich ein klarer Blick von außen:

ADCS-Health-Check · Standortbestimmung deiner bestehenden PKI — Architektur, Härtung, Audit-Readiness, inklusive Prüfung deiner S/MIME-Templates und der Verzeichnis-Veröffentlichung.

Architektur- oder Redesign-Workshop · Vom Ist-Zustand zur Zielarchitektur — hier zum Beispiel fokussiert auf den S/MIME-Rollout mit getrennten Templates und Key-Archival.

Implementierungs- oder Migrationsbegleitung · Beratung und technische Unterstützung beim Umsetzen — von der Template-Definition bis zum geprüften Sync nach Exchange Online.

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund