Öffentliche TLS‑Zertifikate werden bis zum 15. März 2029 schrittweise auf eine maximale Gültigkeitsdauer von 47 Tagen reduziert (200 Tage ab 2026, 100 Tage ab 2027). Das hat das CA/Browser Forum per Ballot SC‑081v3 beschlossen. Apple hat den Vorschlag eingebracht, und alle großen Browser‑Hersteller haben zugestimmt.
Für Exchange Server bedeutet dies, dass die manuelle Verwaltung von Zertifikaten zu Fehlerquellen führt. Eine echte Automatisierung wird insbesondere in isolierten Netzsegmenten erforderlich, was die Implementierung zusätzlich erschwert.
Was wurde offiziell beschlossen?
Mit der CA/B‑Forum‑Abstimmung SC‑081v3 ist nun ein klarer Zeitplan festgelegt, der die maximale Gültigkeitsdauer öffentlicher TLS‑Zertifikate verkürzt, einschließlich der Gültigkeit ihrer Validierungsdaten (DCV, SII). So werden die Sicherheit und Zuverlässigkeit erhöht.
Die Eckdaten:
- Ab 15. März 2026: max. 200 Tage
Domain Control Validation (DCV) wiederverwendbar bis zu 200 Tage - Ab 15. März 2027: max. 100 Tage
DCV bis 100 Tage - Bis 15. März 2029: max. 47 Tage
DCV‑Wiederverwendung nur noch 10 Tage
Mehr als nur das Ändern des IIS-Bindings
Bei klassischen Webservern erfolgt der Zertifikatswechsel in der Regel nur im HTTPS‑Binding. In einer Exchange‑Organisation ist das Ganze jedoch weitaus vielseitiger und komplexer.
- HTTPS‑Endpunkte
OWA, EWS, MAPI/HTTP, AutoDiscover u. a. Alle sind vom Zertifikat, das du in EAC/EMS zuweist, abhängig - SMTP/TLS
Ein Wechsel des Zertifikats beeinflusst die Receive/Send‑Connectoren unmittelbar. - Edge Transport
Wenn Edge-Server beteiligt sind, kann ein Zertifikatstausch die EdgeSync‑Kommunikation (LDAPS 50636) beeinträchtigen und damit die Synchronisierung von Konfigurations- und Empfängerdaten stören.
TLS‑Zertifikate, die auf Edge Transport Servern genutzt werden, sind besonders empfindlich. Das selbstsignierte Exchange-Standard‑Zertifikat wird unter anderem für EdgeSync verwendet. Ein versehentliches Bestätigen der Option „Overwrite default SMTP certificate?“ bei der Aktivierung eines neuen Zertifikats führt zu einer Neuverschlüsselung der ADLDS-Daten und damit zu einem Bruch der EdgeSync-Synchronisierung.
Empfehlung: Für SMTP ein öffentliches Zertifikat verwenden, das das Standard-Self‑Signed‑Zertifikat für EdgeSync nicht überschreibt.
Das Dilemma: keine integrierte, offizielle Lösung in Exchange
ACME ist der Standard für kostenfreie und viele kommerzielle Automationswege. Die Validierung muss regelmäßig wiederholt werden, und ab 2029 sogar innerhalb von 10 Tagen erneut nutzbar sein (DCV).
Microsoft beschreibt die Zertifikatsverfahren (wie das Erstellen von CSRs, das Importieren und das Zuweisen von Diensten) in EAC und in der Exchange Management Shell. Das vollautomatisierte Lifecycle-Management für öffentliche Zertifikate ist jedoch nicht integriert, sodass du diese manuell oder per Skript erstellst und verwaltest, einschließlich der Dienstzuweisung pro Server und Service. Die Grundlagen zu Zertifikaten, Protokollen (standardmäßig TLS 1.2, bevorzugt ECC-Ciphers) und Service-Abhängigkeiten sind gut dokumentiert, aber Automationswege für öffentliche CAs sind es nicht.
Das stimmt mit der Marktentwicklung überein: Die kürzeren Laufzeiten treiben die Automatisierung voran, genau das, was Apple und Google seit Jahren fordern. Im Jahr 2025 wurde der Kurs nun endgültig festgelegt.
Kurz gesagt: Workarounds sind möglich, aber eine „offizielle“ End-to-End-Automatisierung in Exchange gibt es nicht.
Validierung der Domainhoheit
ACME ist der Standard für kostenlose und viele kommerzielle Automatisierungswege. Die Validierung muss regelmäßig erneuert werden, und ab 2029 sogar innerhalb von 10 Tagen erneut durchgeführt werden können (DCV).
ACME unterstützt folgende Challenge-Typen zur Validierung einer Domäne (DCV)
- HTTP‑01
Token über Port 80 unter /.well-known/acme-challenge/….
Einfach, aber es erfordert einen öffentlich zugänglichen Webserver (und Port 80 im eingehenden Datenverkehr).
Keine Wildcards. - DNS‑01
TXT‑Record unter _acme-challenge.<domain>.
Erlaubt die Verwendung von Wildcards und funktioniert ohne einen öffentlich zugänglichen Webserver. Ideal für DMZ-Umgebungen oder Situationen, in denen TCP-Port 80 nicht bereitgestellt wird, erfordert jedoch eine DNS-Automations-API oder manuelle Verwaltung. - TLS‑ALPN‑01
Spezielle Antwort über ALPN auf Port 443. Nischenthema, häufig nicht unterstützt, aber bei bestimmten Topologien interessant.
Was heißt das konkret für Dich als Exchange Admin?
Die bevorstehenden Änderungen bei den Zertifikatlaufzeiten stellen spezielle Herausforderungen dar. Daher ist es wichtig, dass wir frühzeitig mit den Vorbereitungen anfangen.
Architektur neu denken
- Trenne Zuständigkeiten
Für öffentliche TLS-Zertifikate ist ein externer Automationspunkt erforderlich, beispielsweise ein Reverse-Proxy, ein Web-Gateway oder ein separater Zertifikats-Hub, der außerhalb des Exchange-Subnetzes positioniert ist. Dieses System nutzt ACME, um mit der CA zu kommunizieren, und verteilt die Zertifikate intern, wodurch die direkte Verbindung zwischen der CA und dem Exchange-Server vermieden wird.
- Edge Transport Besonderheiten
Plane, dass SMTP-Zertifikate häufiger wechseln. Der Edge benötigt ein öffentliches Zertifikat für SMTP (Partner‑TLS, MTA‑STS/Policy‑Checks), aber das Self‑Signed‑Zertifikat für EdgeSync darfst du nicht einfach überschreiben. Da Edge-Transport-Server im Perimeter-Netzwerk platziert sind, erschwert dies die Kommunikation mit dem TLS-ACME-Endpunkt.
Prozesse für häufige Wechsel etablieren
- Standardisiere Namespaces & SANs
Klar strukturierte, kurze Zertifikats-Subject Alternative Names (wie mail.contoso.tld, autodiscover.contoso.tld) erleichtern die Wiederausstellung von Zertifikaten und entsprechen den Best Practices für Exchange-Namensräume.
- Kaskadierte Verteilung
Zertifikate sollten zentral (ACME‑Client, kommerzielle Tools) erzeugt und erneuert werden, als PFX‑Datei mit starkem Passwort exportiert, automatisch auf alle Exchange‑Server verteilt und aktiviert werden (IIS, SMTP, POP/IMAP).
Prozesse für häufige Wechsel etablieren
- ACME via DNS‑01
Wenn Exchange keine Internet‑Verbindung hat, können wir einen DNS‑Automationspfad (Provider‑API) nutzen, der von einem Management‑Host im Perimeter-Netzwerk gesteuert wird. Dieser Host übernimmt die Herausforderung, bezieht das Zertifikat, exportiert die PFX-Datei und startet Remoting für die Zertifikatsverteilung.
- PowerShell als „Krücke“
Skripte sind nach wie vor sehr nützlich (CSR, Import, Enable), doch ohne Events/Retry/Secrets‑Management können sie etwas fragil sein. Besonders nach 47 Tagen ist der Einsatz einfach zu häufig, was das Risiko erhöht.
Stolpersteine
- EdgeSync bricht nach Zertifikatswechsel
Symptom: EdgeSync-Synchronisierung stoppt, hybrider Mailflow wird gestört.
Ursache: Falsches Zertifikat für LDAPS, da das Default‑Zertifikat überschrieben wurde.
Lösung: Self‑Signed für EdgeSync intakt lassen (Standard‑Zertifikat des Transportdienstes), das öffentliche SMTP‑Zertifikat separat aktivieren und nicht überschreiben. - AutoDiscover/Outlook meldet Zertifikatswarnungen
Ursache: SANs unvollständig, Zertifikat nicht auf alle CAS/Mailbox‑Server verteilt, alter Thumbprint noch aktiv.
Lösung: SAN‑Set vereinheitlichen, zentral verteilen, Enable‑ExchangeCertificate –Services IIS überall sauber ausführen und anschließende Outlook/AutoDiscover‑Tests. - HTTP‑01 nicht möglich
Ursache: Harte Einschränkung für eingehender TCP 80-Verbindungen ins Perimeter-Netzwerk
Lösung: DNS‑01 mit API‑Automatisierung, unter Berücksichtigung von TTL/Propagation-Einstellungen und Retry‑Logik, um den Prozess fehlerunanfällig zu machen. - Wildcards benötigt
Lösung: Nur DNS‑01 erlaubt Wildcards. Prüfe, ob Wildcards wirklich nötig sind. Präzise SANs sind sicherer.
Was die Laufzeitverkürzung praktisch bedeutet
- 2026 ⇒ 200 Tage: Du wechselst Zertifikate mindestens zweimal im Jahr. Manuelle Kalendererinnerungen sind zwar noch ausreichend, aber leicht zu übersehen.
- 2027 ⇒ 100 Tage: 4× pro Jahr. Wenn du auf Automatisierung verzichtest, könnten unerwartete Ausfälle auftreten.
- 2029 ⇒ 47 Tage/10 Tage DCV 8–12× pro Jahr. Eine manuelle Verwaltung ist auf Dauer nicht ideal. Automatisierung wird immer wichtiger.
Wenn wir über Verkürzungen sprechen, wird oft betont, dass kürzere Laufzeiten das Angriffsfenster verkleinern, das Zurückziehen von Zertifikaten (Recovation) weniger kritisch erscheinen lässt und die Crypto‑Agilität, wie den schnellen Wechsel von Algorithmen, erhöhen. Das Sicherheitsplus ist definitiv vorhanden und wirklich spürbar. Wichtig ist jedoch, dass deine Prozesse dort ebenfalls Schritt halten, damit alles optimal funktioniert.
Fazit
Die Entscheidung der CA/B‑Forum‑Mitglieder (inkl. Apple, Google, Microsoft, Mozilla) ist endgültig. Öffentliche TLS‑Zertifikate sind nur noch kurz gültig.
Exchange stellt zwar nützliche manuelle Werkzeuge bereit, bietet jedoch kein integriertes, vollautomatisches Lifecycle-Management mit öffentlicher CA-Anbindung. Das bedeutet, dass weiterhin einige Herausforderungen bestehen. Es sei denn, du nutzt die Automatisierung außerhalb von Exchange, zum Beispiel mit ACME, um eine solide Basis zu schaffen, und integrierst die Verteilung sowie die Aktivierung schrittweise mithilfe von Skripten. Das lässt sich gut planen, erfordert jedoch Disziplin und eine klare Trennung zwischen den Automatisierungsprozessen, die ins Internet führen, und der internen Exchange-Umgebung, insbesondere beim Einsatz von Edge Transport.
