TLS-Zertifikate, Exchange Server und ein ungelöstes Dilemma

Die Verkürzung der Laufzeiten für öffentliche TLS-Zertifikate ist keine reine Theorie mehr. Sie ist beschlossen.

Bis 2029 sollen Zertifikate nur noch sehr kurze Gültigkeitsdauer haben. Ab dem 15. März 2029 wird die maximale Laufzeit auf 47 Tage festgelegt. Dies ist aus IT-Sicherheitsgründen vorteilhaft, weil kürzere Gültigkeiten das Angriffsfenster verkürzen, eine schnellere Reaktion bei kompromittierten Schlüsseln erlauben und technische Altlasten reduzieren.

Für klassische Webserver ist die Nutzung von Zertifikaten mit kürzerer Laufzeit (Let’S Encrypt) mittlerweile Standard. Zertifikate werden automatisch ausgestellt, erneuert und gebunden. ACME-Protokolle, Agents, APIs und entsprechende Prozesse sind etabliert und bewährt.

Für Exchange Server gilt das nicht.

Und genau hier setzt ein strukturelles Problem ein, das nicht länger ignoriert werden kann.

Exchange Server ist kein Webserver

Exchange Server wird oft einfach wie eine normale IIS-Anwendung betrachtet. Schließlich läuft er auf Windows, benutzt IIS und nutzt Zertifikate für HTTPS. Doch diese Sichtweise ist zu kurz gedacht. Ein TLS-Zertifikat in Exchange ist kein austauschbares kleines Detail, sondern ein wichtiger Bestandteil der gesamten Kommunikationsarchitektur.

Ein Zertifikatswechsel betrifft nicht nur OWA oder ECP, sondern unter anderem:

• Clientzugriffe wie MAPI over HTTP, ActiveSync oder OutlookAnywhere
• SMTP-Kommunikation über Empfangs- und Sendekonnektoren
• interne Server-zu-Server-Verbindungen
• hybride Szenarien mit Microsoft 365
• Edge Transport Server und EdgeSync

Ein Fehler in diesem Zusammenhang ist kein bloßes kosmetisches Problem. Er könnte den Nachrichtenfluss unterbrechen, Client-Verbindungen verweigern und so komplette Kommunikationsketten stilllegen.

Manuell seit Jahren – und daran hat sich wenig geändert

Bis heute gibt es in Exchange Server keine integrierte, offiziell unterstützte Lösung für den automatisierten Umgang mit öffentlichen TLS-Zertifikaten. Die Realität ist seit Jahren gleich geblieben:

Zertifikatsanfragen werden manuell erstellt.
Zertifikate werden manuell importiert.
Dienste werden manuell zugewiesen.
Alte Zertifikate werden manuell entfernt oder deaktiviert.

Ja, viele dieser Aufgaben können mit PowerShell-Skripten teilweise automatisiert werden. Viele Administratoren nutzen das auch. Doch seien wir ehrlich: Das sind oft individuelle Lösungen, fragile Konstrukte, die von Umgebung, Version, Topologie und persönlichem Wissen abhängig sind. Sie sind nützlich, bieten aber keine Lösung für ein grundlegendes Problem.

Vor allem skalieren sie nicht mit der Realität verkürzter Zertifikatslaufzeiten ab 2029.

Wenn das Internet bewusst fehlt

Besonders kritisch wird die Situation in IT-Umgebungen, die gezielt ohne direkte Internet-Konnektivität betrieben werden. Dies gilt insbesondere für Behörden, kritische Infrastrukturen oder regulierte Unternehmen, um nur einige Bereiche zu nennen. Sie alle setzen auf abgeschottete Exchange-Installationen, oft aus guten Gründen.

Doch genau diese Trennung ist ein fundamentaler Widerspruch zu modernen Zertifikatsautomatisierungsmodellen. Öffentliche CAs setzen voraus, dass Systeme:

• HTTPS-Verbindungen nach außen aufbauen können
• HTTP- oder DNS-Challenges beantworten
• APIs erreichen oder Agenten betreiben dürfen

Wie soll ein Exchange Server in einem internen Netz eigenständig TLS-Zertifikate erneuern, wenn keine dieser Voraussetzungen gegeben ist?

Die ehrliche Antwort lautet: gar nicht.

Domain-Validierung: ein ungelöstes Kernproblem

Die notwendige Validierung der Eigentümerschaft einer Domäne verschärft das Dilemma zusätzlich. Übliche Verfahren wie HTTP-01-Challenges erfordern öffentlich erreichbare Webserver auf TCP-Port 80. Diese existieren in vielen Exchange-Szenarien bewusst nicht. DNS-Challenges setzen automatisierte Änderungen an produktiven DNS-Zonen voraus, was organisatorisch und sicherheitstechnisch oft ausgeschlossen ist.

Bleiben asynchrone Verfahren, etwa per E-Mail. Doch gerade sie widersprechen dem Ziel, das kurze Zertifikatslaufzeiten eigentlich verfolgen: Verlässlichkeit, Wiederholbarkeit und Automatisierung.

Was auf dem Papier praktikabel klingt, scheitert in der Praxis an den realen Betriebsbedingungen.

Verkürzte Laufzeiten machen das Problem sichtbar

Ein Zertifikat mit ein- oder zweijähriger Laufzeit war leicht zu verwalten. Es waren nur Wartungsfenster, geplante Wechsel und kontrollierte Eingriffe notwendig. Doch bei einer Laufzeit von 90 Tagen oder weniger wird das Zertifikatsmanagement zur Daueraufgabe.

Und genau dafür ist Exchange Server nicht gebaut.

Während ein Webserver bei einem Zertifikatswechsel oft nur ein neues IIS-Binding erhält, erfordern Zertifikatswechsel in Exchange tiefere Eingriffe in Transportlogik, Authentifizierung und Vertrauensbeziehungen. Empfangs- und Sendekonnektoren verwenden Zertifikate explizit, und fehlerhafte Zuweisungen können zu TLS-Abbrüchen, Mailstaus oder abgelehnten Verbindungen führen.

In hybriden Szenarien vervielfacht sich dieses Risiko.

Edge Transport Server: zusätzliche Komplexität

Kommt ein Edge Transport Server zum Einsatz, wird die Situation noch fragiler. Je nach Konfiguration beeinflusst ein Zertifikatswechsel nicht nur die externe Kommunikation, sondern auch die EdgeSync-Synchronisierung.

Hier dienen Zertifikate nicht nur der Verschlüsselung, sondern auch der gegenseitigen Authentifizierung. Ein unkoordinierter oder fehlerhafter Wechsel kann die Verbindung zwischen der internen Organisation und der Edge-Rolle unterbrechen – mit unmittelbaren Auswirkungen auf den gesamten Nachrichtenfluss.

Automatisierung existiert hier höchstens als individuelle Bastellösung.

Stand heute: Workarounds statt Strategie

Damit kommen wir zum Kern des Problems. Momentan gibt es keine offizielle Strategie, wie Exchange Server mit kurzen Laufzeiten bei öffentlichen TLS-Zertifikaten umgehen soll. Es existieren zwar Skripte, Blogbeiträge und Community-Lösungen, doch eine integrierte Lösung, ein klares Architekturkonzept oder eine offizielle Empfehlung fehlen bisher.

Das ist keine Kleinigkeit. Denn die Entscheidung für kürzere Laufzeiten wurde nicht von Exchange Admins getroffen. Sie ist eine sicherheitspolitische Entwicklung, die auf bestehende Systeme wirkt. Ganz unabhängig davon, ob diese darauf vorbereitet sind oder nicht.

2029 ist näher, als es scheint

2029 wirkt auf den ersten Blick weit weg. Doch wer IT-Projekte plant, weiß, dass die Zeit in diesem Kontext schneller vergeht als erwartet. Architekturentscheidungen, Migrationspfade, oder Produktzyklen brauchen Jahre, nicht Monate.

Sich hier neutral zu verhalten, nichts zu unternehmen und abzuwarten, ist daher keine wirklich neutrale Position mehr. Es ist eine bewusste Entscheidung, den KOpf in den Sand zu stecken. Unstätigkeit ist ein Betriebsrisiko.

Eine offene Frage

Wenn Neutralität zur Lüge wird, dann vielleicht genau hier: an dem Punkt, an dem Sicherheitsanforderungen steigen, die dafür notwendigen Werkzeuge aber (noch) fehlen.

Es wird viel über kürzere Zertifikatslaufzeiten diskutiert, doch weniger darüber, wie dies in komplexen, isolierten Exchange-Umgebungen realistisch umgesetzt werden kann, und noch weniger darüber, wer dafür verantwortlich ist.

Die Frage richtet sich daher sowohl an die Community als auch, indirekt, an die Personen, die Exchange seit Jahren strategisch betreuen.

Wie soll ein automatisierter, sicherer und betrieblich tragfähiger Umgang mit öffentlichen TLS-Zertifikaten in Exchange Server aussehen, wenn klassische Automatisierungsmodelle nicht greifen?

Und an dich, der diesen Text liest:

Was erwartest du von einer solchen Lösung?
Welche Funktionen müsste sie haben, damit sie für dich mehr als nur ein weiterer Workaround ist?

Nutze gerne die Kommentarfunktion, um deine Sichtweise mitzuteilen. 2029 mag auf den ersten Blick noch fern erscheinen, aber die Zeit bis dahin wird schneller vergehen, als wir jetzt manchmal denken.