Der Ausgangspunkt: Ein erzwungener Zertifikatstausch
Am 4. April 2026 veröffentlichte das BSI eine Warnung: Die D-Trust GmbH musste kurzfristig alle TLS-Zertifikate tauschen, die zwischen dem 15. März 2025 und dem 2. April 2026 ausgestellt worden waren. Bereits am 6. April 2026 um 17:00 Uhr verloren diese Zertifikate ihre Gültigkeit. Wer eines dieser Zertifikate in seiner Infrastruktur betrieb, stand unter erheblichem Zeitdruck.
Der eigentliche Auslöser: EV-Zertifikat statt Standard-Serverzertifikat
Bevor wir in die Exchange-spezifischen Probleme einsteigen, lohnt ein kurzer Blick auf den grundlegenden Auslöser, denn der liegt eine Ebene darunter.
Aktuelle Standard-Serverzertifikate werden in der Regel nur noch mit der Schlüsselnutzung „Server Authentication“ ausgestellt. Für reine Webserver-Anwendungen ist das völlig in Ordnung. Für die TLS-Authentifizierung im Kontext von SMTP ist das jedoch eine echte Herausforderung, aber das ist ein Thema für einen eigenen Artikel.
Die Kombination aus Client- und Server-Authentication wird derzeit häufig noch für sogenannte EV-Zertifikate (Extended Validation) angeboten. Genau ein solches EV-Zertifikat wurde für die hybride SMTP-Kommunikation ausgestellt, und damit trat das eigentliche Problem auf.
EV-Zertifikate enthalten im Subject-Feld deutlich mehr Informationen als gewöhnliche Serverzertifikate. Ein typisches Beispiel sieht so aus:
CN=smtpo.varunagroup.de, O=Varunagroup AG, STREET=Musterstr. 47,
PostalCode=12345, L=Musterstadt, S=NRW, C=DE,
SERIALNUMBER=HRB 4711 B, OID.2.5.4.15=Private Organization,
OID.1.3.6.1.4.1.311.60.2.1.1=Musterstadt,
OID.1.3.6.1.4.1.311.60.2.1.2=NRW,
OID.1.3.6.1.4.1.311.60.2.1.3=DE
Die OID-Felder am Ende sind dabei keine Besonderheit des Ausstellers, sondern ein fester Bestandteil der EV-Spezifikation des CA/Browser-Forums. Sie kodieren die rechtliche Jurisdiktion der Organisation, also den Ort, das Bundesland und das Land der Firmengründung. Zusammen mit dem Issuer des Zertifikats, der beim TLSCertificateName-Attribut des Sendekonnektors ebenfalls in den String einfließt, kommt man schnell auf eine Gesamtlänge von 341 Zeichen. Bei der Konfiguration des Sendekonnektors selbst fiel das noch nicht auf. Die Probleme zeigten sich erst später.
Die Ausgangslage: Das Zertifikat trug mehrere Hüte
Die betroffenen Edge-Transport-Server (ET) nutzten das offizielle D-Trust-Zertifikat nicht nur für die hybride SMTP-Kommunikation mit Exchange Online. Es war zusätzlich als Standard-Transportzertifikat in Exchange konfiguriert.
Diese Konfiguration hat eine wichtige Konsequenz: Die lokale AD LDS-Instanz des ET-Servers verwendet dieses Zertifikat, um sensible Daten zu verschlüsseln. Konkret betrifft das:
- das Kennwort des ESRA-Kontos (EdgeSync Replication Account),
- die Kennwörter der internen Postfachserver.
Das Zertifikat war also tief in die EdgeSync-Infrastruktur verwoben.
Das ET-Abonnement erneuern
Da nach dem Zertifikatstausch die AD LDS-Instanz ein neues Zertifikat verwendete, waren die zuvor verschlüsselten Kennwörter nicht mehr entschlüsselbar. Das Edge-Abonnement für die interne Active-Directory-Site musste daher für jeden ET-Server erneuert werden. Dieser Schritt war klar und dokumentiert.
Nach der Erneuerung schien alles in Ordnung. Doch beim Test der hybriden Mailflow-Konfiguration zeigte sich das eigentliche Problem: Der hybride Sendekonnektor in Richtung Exchange Online wurde über EdgeSync nicht mehr auf die ET-Server übertragen.
Die Fehleranalyse: Eine DirectoryOperationException als Fingerzeig
Ein Blick in die EdgeSync-Protokolldateien eines Postfachservers brachte Licht ins Dunkel:
A value in the request is invalid. [ExDirectoryException];
Inner Exception: A value in the request is invalid. [DirectoryOperationException]
Failed to synchronize entry CN=Outbound to Office 365, CN=Connections, ...
Der betroffene Eintrag war eindeutig der hybride Sendekonnektor in Richtung Office 365.
Dieser Fehler ist in einem Microsoft-Supportartikel dokumentiert, der eigentlich mit einem anderen Symptom befasst ist. Nachrichten, die in Exchange Online fälschlicherweise als externe Nachrichten behandelt werden. Das zugrunde liegende technische Problem ist jedoch identisch.
Die eigentliche Ursache: Ein zu kurzes Attribut im AD LDS-Schema
Das ADLDS-Schema auf Exchange-Edge-Transport-Servern speichert den Wert des konfigurierten SMTP-TLS-Zertifikats im Attribut ms-Exch-Smtp-TLS-Certificate. Dieses Attribut ist im Schema auf eine maximale Länge von 256 Zeichen begrenzt.
Das Subject des alten D-Trust-Zertifikats lag noch innerhalb dieses Limits. Das Subject des neuen EV-Zertifikats mit seinen OID-Feldern und dem Issuer kam auf 341 Zeichen und überschritt damit die Grenze deutlich. EdgeSync versuchte, diesen Wert in das AD LDS-Attribut zu schreiben, aber es scheiterte und es kam zu einer DirectoryOperationException. Der hybride Sendekonnektor wurde nicht per EdgeSync übertragen.
Die Lösung: Das Zeichenlimit auf 1024 erhöhen
Der Microsoft-Supportartikel beschreibt mehrere Lösungsansätze. Wir haben uns für Lösung 1 entschieden: die maximale Zeichenlänge des ms-Exch-Smtp-TLS-Certificate-Attributs im AD LDS-Schema von 256 auf 1024 Zeichen zu erhöhen.
Der grüne Pfeil verweist auf die Zeichenlänge des zu konfigurierenden TLSCertificateName-Strings.
- Standardgröße des Attributes ms‑Exch‑Smtp‑TLS‑Certificate vor der Änderung
- Größe des Attributes ms‑Exch‑Smtp‑TLS‑Certificate nach der Änderung
Nach dieser Änderung konnte EdgeSync den Wert des neuen Zertifikats problemlos schreiben. Der hybride Sendekonnektor wurde korrekt auf die ET-Server übertragen und ging unmittelbar in Betrieb.
Warum nicht einfach Lösung 2?
Lösung 2 klingt auf den ersten Blick verlockend: Verzichte auf das TLSCertificateName-Attribut und verwende stattdessen einfach den FQDN des Zertifikats. Problem gelöst, ohne Schemaänderung.
Der Haken: Der Hybrid Configuration Wizard (HCW) kennt diese Empfehlung nicht. Bei jeder erneuten Ausführung des HCW würde dieser das TLSCertificateName-Attribut wieder befüllen, und das Problem wäre wieder da.
Und noch eine kleine Anekdote am Rande: Der im Microsoft-Artikel verlinkte Referenzartikel zu Lösung 2 beschreibt die Zertifikatsauswahl für Exchange Server 2010. Das ist kein Tippfehler. Es ist tatsächlich ein Artikel aus dem Jahr 2010, der auf Exchange 2010 verweist. Man kann sich lebhaft vorstellen, wie aufmerksam dieser von Exchange-Admins gelesen wird.
Ein Tipp für die Zukunft: Zertifikate sauber trennen
Dieser Vorfall zeigt deutlich, was passiert, wenn ein offizielles Zertifikat zu viele Rollen auf einmal übernimmt. Daher eine klare Empfehlung:
Verwendet als Standard-Transportzertifikat auf Edge-Transport-Servern, und damit auch für die AD LDS-Verschlüsselung und EdgeSync, kein offizielles Zertifikat. Nutzt stattdessen das selbstsignierte Exchange-Zertifikat des ET-Servers. Es hat eine Laufzeit von fünf Jahren und ist für diesen internen Zweck vollkommen ausreichend.
Das offizielle Zertifikat, ob EV oder anderer Art, ist ausschliesslich an den hybriden SMTP-Sendekonnektor nach Exchange Online gebunden.
Die Laufzeiten öffentlicher Zertifikate werden in den kommenden Jahren weiter verkürzt. Die Arbeit durch häufigere Zertifikatswechsel wird zunehmen. Wer dann auch noch jedes Mal um die AD LDS-Instanz kümmern muss, hat sich unnötig viel Aufwand eingehandelt. Haltet das sauber getrennt.
