Exchange Zertifikat erneuern - So gelingt der Wechsel!

Ein ablaufendes Exchange-Zertifikat ist selten ein theoretisches Problem. Es betrifft oft OWA, ECP, Autodiscover, SMTP oder eine Hybrid-Anbindung, und genau deshalb lohnt es sich, die Erneuerung sauber zu planen statt erst am letzten Tag zu reagieren. In diesem Artikel zeige ich, wann ein Exchange-Zertifikat einfach erneuert wird, wann ein neues CSR nötig ist, wie der Weg über EAC oder Exchange Management Shell aussieht und welche Nacharbeiten ich in Projekten nie auslasse.

Wann Erneuern reicht und wann du neu ausstellen solltest

Ich trenne dieses Thema immer in zwei Fragen: Ist das Zertifikat nur abgelaufen, oder hat sich auch die technische Situation geändert? Wenn nur die Laufzeit endet und die Namens- oder Servicezuordnung gleich bleibt, ist die Erneuerung meist der richtige Weg. Sobald sich aber SANs, Hostnamen, Serverrollen oder die Mailflow-Architektur ändern, ist ein neues Zertifikat oft sauberer als ein bloßes Renewal.

Gerade bei Exchange lohnt sich diese Unterscheidung, weil ein Zertifikat nicht nur „da sein“ muss, sondern zu den gebundenen Diensten passen muss. Für OWA, ECP, Autodiscover und SMTP ist die Kombination aus Name, Zertifikatstyp und Servicebindung entscheidend. Ein falscher Shortcut spart höchstens ein paar Minuten beim Beantragen, kostet aber später gern eine Stunde Fehlersuche.

Damit ist klar, wann der Weg über Renewing sinnvoll ist. Als Nächstes lohnt sich der Blick auf die drei Zertifikatstypen, die in Exchange in der Praxis immer wieder verwechselt werden.

So erkennst du, ob du ein self-signed, CA- oder Auth-Zertifikat vor dir hast

Das Wort „SSL“ wird im Alltag oft pauschal benutzt, technisch geht es bei Exchange aber fast immer um TLS-Zertifikate. Und genau hier entsteht die erste Verwirrung: Nicht jedes Exchange-Zertifikat erfüllt dieselbe Aufgabe. Ich prüfe deshalb immer zuerst den Typ, bevor ich irgendetwas erneuere oder importiere.

Das standardmäßig installierte self-signed Zertifikat läuft fünf Jahre nach der Installation von Exchange ab. Für viele Umgebungen ist das der einfachste Fall, weil es keinen externen Zertifikatsanbieter braucht. Bei CA-Zertifikaten und beim Auth Certificate sieht die Welt aber deutlich anders aus, und genau dort passieren die meisten Bedienfehler.

Wenn ich ein Zertifikat schnell einordnen will, schaue ich mir im Exchange-Kontext immer drei Dinge an: den Subject bzw. die SANs, die zugewiesenen Services und den Status. Steht dort „Pending request“, ist der Weg über den Import offen. Steht dort „Valid“ und „IsSelfSigned“, dann ist es meist ein klassischer Self-signed-Fall. Und wenn der Zertifikatstyp für Auth gedacht ist, lasse ich die Finger von der normalen Web-Erneuerung.

Mit dieser Einordnung im Kopf wird der eigentliche Ablauf viel klarer, denn Exchange behandelt die Wege je nach Typ bewusst unterschiedlich.

So läuft das Erneuern im Exchange Admin Center oder per PowerShell ab

Nach aktueller Microsoft-Dokumentation ist der Exchange Admin Center der GUI-Weg für neuere Builds ab Exchange Server 2019 CU15. Bei Exchange Server 2016 CU23 sowie Exchange Server 2019 CU12 bis CU14 arbeite ich direkt in der Exchange Management Shell. Für mich ist die Shell oft die bessere Wahl, weil ich dort genauer sehe, was ich tue, und den Vorgang später leichter dokumentieren kann.

Self-signed Zertifikat erneuern

Der Self-signed-Fall ist technisch der simpelste. In der EAC gehe ich zu Servers > Certificates, wähle den Server aus, markiere das gültige Zertifikat und klicke auf Renew. Exchange zeigt mir dann die zugeordneten Services an, und ich bestätige den Vorgang. Wichtig ist dabei, dass ich nicht blind „irgendwas Neues“ erzeuge, sondern bewusst prüfe, welche Dienste an dieses Zertifikat gebunden sind.

Per Shell sieht der Kernschritt so aus:

Get-ExchangeCertificate -Thumbprint  | New-ExchangeCertificate -Force -PrivateKeyExportable $true

Mit -PrivateKeyExportable $true halte ich mir die Option offen, das Zertifikat später auf weitere Exchange-Server zu übertragen. Das ist vor allem in Umgebungen mit mehreren Mailbox-Servern nützlich, weil ich so nicht jeden Server separat neu bauen muss. Wenn du das Zertifikat garantiert nur lokal brauchst, ist dieser Schalter nicht immer zwingend, in der Praxis spart er aber oft Zeit.

CA-basiertes Zertifikat erneuern

Bei einem von einer Zertifizierungsstelle ausgestellten Zertifikat ist der Ablauf zweistufig. Zuerst erzeugt Exchange eine neue Anforderung, dann signiert die CA diese Anforderung, und erst danach importiere ich das Ergebnis wieder in Exchange. Dabei kann Exchange eine PKCS#10-Anforderung im Base64- oder DER-Format erzeugen; die Standard-Schlüssellänge ist 2048 Bit, je nach CA sind aber auch andere Varianten möglich.

In der EAC erstelle ich die Erneuerungsanforderung über Servers > Certificates und die Funktion Renew. Die resultierende Request-Datei schicke ich an die CA. Sobald die signierte Datei zurückkommt, schließe ich die ausstehende Anforderung ab. In der Shell nutze ich dafür typischerweise Import-ExchangeCertificate. Wenn du mit der Shell arbeitest, kannst du den Vorgang sauber in Skripten abbilden und auch die Dateipfade kontrolliert setzen.

Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes('C:\Temp\ExchangeRenewal.cer')) -Password (Read-Host "Enter password" -AsSecureString)

Bei der EAC musst du die Zertifikatsdatei über einen UNC-Pfad angeben, in der Shell kann auch ein lokaler Pfad reichen. Danach weise ich das Zertifikat den benötigten Diensten zu, also typischerweise IIS und SMTP, je nach Umgebung auch POP und IMAP. Genau dieser Schritt wird gerne übersehen, obwohl das Zertifikat technisch schon erfolgreich importiert wurde.

Der eigentliche Exchange-Schritt dauert laut Microsoft ungefähr 5 Minuten. In der Realität bestimmt aber oft die CA den Takt, nicht Exchange. Wenn die interne Freigabe, das Signieren oder das Einsammeln der Chain länger dauert, ist das kein Exchange-Problem, sondern ein Prozessproblem. Deshalb plane ich den Zertifikatswechsel nie als Nebentätigkeit zwischen zwei Meetings.

Wenn das Zertifikat aktiv ist, prüfe ich direkt die Bindungen und die Sichtbarkeit in den Diensten, denn genau dort zeigt sich, ob der Wechsel wirklich sauber war.

Was ich nach dem Wechsel sofort prüfe

Nach dem Import oder der Erneuerung verlasse ich mich nicht auf das Bauchgefühl, sondern auf den Status in Exchange. Ein gültiger Eintrag allein reicht nicht, wenn die Dienste noch am alten Zertifikat hängen oder IIS die neue Zuordnung noch nicht sauber übernommen hat.

• Der Status muss auf Valid stehen.
• Das Feld NotAfter muss das neue Ablaufdatum zeigen.
• Die Services müssen korrekt zugewiesen sein, vor allem IIS und SMTP.
• Wenn Outlook on the web oder ECP betroffen sind, prüfe ich die IIS-Bindung oder starte IIS neu.
• In Mehrserver-Umgebungen stelle ich sicher, dass das Zertifikat dort ankommt, wo es gebraucht wird.

Ein schneller Kontrollbefehl in der Shell ist oft genug, um die wichtigsten Felder zu sehen:

Get-ExchangeCertificate | Select FriendlyName,Thumbprint,NotAfter,IsSelfSigned,Services

Wenn ich Layer-4-Load-Balancing im Spiel habe, behandle ich den IIS-Neustart besonders vorsichtig. In solchen Umgebungen kann Exchange sonst für kurze Zeit noch auf alte Bindings oder Cookies reagieren. Das ist kein Drama, aber genau die Art von Detail, die später als „komischer Zertifikatsfehler“ im Ticket landet.

Ist diese Prüfung erledigt, kann ich mich den Fehlern zuwenden, die im Alltag am häufigsten Zeit kosten, obwohl sie vermeidbar wären.

Typische Fehler, die in Exchange-Projekten unnötig Zeit kosten

Die meisten Probleme rund um Zertifikate entstehen nicht, weil Exchange „kompliziert“ wäre, sondern weil ein Schritt übersehen wird. Ich sehe immer wieder dieselben Muster, und sie lassen sich mit einer einfachen Checkliste fast komplett vermeiden.

• Das Zertifikat wird importiert, aber nicht den richtigen Diensten zugewiesen. Dann ist es zwar vorhanden, wird aber nicht genutzt.
• Es wird eine CA-Datei komplett falsch abgelegt, etwa ohne erreichbaren UNC-Pfad. In der EAC endet das schnell in einem unnötigen Abbruch.
• Der private Schlüssel ist nicht exportierbar, obwohl das Zertifikat später auf weitere Server muss. Dann fehlt dir die Flexibilität im Rollout.
• Ein Edge-Transport-Server wird behandelt wie ein normaler Mailbox-Server. Das ist bei einer CA-basierten Erneuerung ein echter Denkfehler.
• Das Auth Certificate wird mit dem HTTPS-Zertifikat verwechselt. Dadurch bleibt ein Outlook-on-the-web- oder ECP-Problem bestehen, obwohl das Webzertifikat schon korrekt ist.
• Die Bindung auf Exchange Back End und Default Web Site wird nicht geprüft. Genau dort können nach einer Änderung noch alte Zuordnungen hängen.

Was ich daraus gelernt habe: Nicht das Erneuern selbst ist schwer, sondern die saubere Nacharbeit. Sobald du die Bindungen und Dienste kontrollierst, sinkt das Risiko für Ausfälle drastisch. Und genau an dieser Stelle kommen die beiden Sonderfälle ins Spiel, die ich nie in denselben Topf werfe wie ein normales SSL-Zertifikat.

Zwei Sonderfälle, die ich vor dem Wechsel immer separat prüfe

Es gibt zwei Situationen, in denen ich besonders wachsam bin: das Exchange Auth Certificate und ein CA-basiertes Zertifikat auf einem subscribed Edge Transport Server. Beide sind technisch eng mit Exchange verzahnt, aber sie folgen nicht dem gleichen Muster wie ein gewöhnliches Webzertifikat.

Das Auth Certificate ist kein normales Webzertifikat

Wenn das Auth Certificate bald abläuft, gehe ich nicht über den üblichen IIS-Weg. Stattdessen erzeuge ich ein neues Auth-Zertifikat und plane den Übergang bewusst mit Vorlauf. Microsoft empfiehlt dafür, die neue Version mindestens 48 Stunden vor der Aktivierung zu stagen; in der Praxis setze ich den Effektivzeitpunkt deshalb auf 49 Stunden in der Zukunft, um einen kleinen Puffer zu haben.

$newAuthCertificate = New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName @()
Set-AuthConfig -NewCertificateThumbprint $newAuthCertificate.Thumbprint -NewCertificateEffectiveDate (Get-Date).AddHours(49)

Wichtig ist hier noch etwas anderes: Ich überschreibe dabei nicht unbedacht das Default-SMTP-Zertifikat. Dieser Schritt ist bei Exchange absichtlich getrennt, und genau das schützt dich vor einem unnötigen Mailflow-Problem. Wenn das Auth Certificate bereits abgelaufen oder verschwunden ist, muss es sofort ersetzt werden, weil sonst OWA oder ECP Probleme machen können.

Lesen Sie auch: Kostenloses S/MIME-Zertifikat - Lohnt sich das wirklich?

Edge Subscription macht die Erneuerung empfindlicher

Auf einem subscribed Edge Transport Server ist ein erneuertes oder ersetztes CA-Zertifikat nicht einfach nur „neu importiert und fertig“. In diesem Fall muss das alte Zertifikat entfernt werden, und anschließend wird die Edge Subscription gelöscht und neu erstellt. Das ist kein kosmetischer Zusatzschritt, sondern Teil der Vertrauenskette.

Wenn ich diesen Fall betreue, plane ich also mehr als nur das eigentliche Zertifikat ein. Ich plane auch die Re-Subscription, die Zeit für die Replikation und den kurzen Prüflauf danach ein. Genau hier zeigt sich, ob ein Projekt nur Zertifikate verwaltet oder wirklich Exchange-Betrieb im Griff hat.

Wenn diese Sonderfälle klar getrennt sind, bleibt noch ein letzter praktischer Punkt: Was ich vor dem Ablaufdatum schon dokumentiere, damit der Wechsel später in Minuten statt in Stunden erledigt ist.

Was ich vor dem nächsten Ablaufdatum schon vorbereite

Ich halte vor dem Stichtag immer dieselben Daten fest: den aktuellen Thumbprint, das Ablaufdatum, die zugewiesenen Services und die Frage, ob der private Schlüssel exportierbar ist. Das klingt banal, macht aber im Ernstfall den Unterschied zwischen kontrolliertem Wechsel und hektischer Fehlersuche.

Zusätzlich prüfe ich vorab, ob der Zertifikatsanbieter eine bestimmte Dateiform verlangt, ob ich eine CA-Chain mitliefern muss und ob andere Exchange-Server das Zertifikat ebenfalls brauchen. In hybriden Setups oder bei Edge Transport kommt noch ein Zeitpuffer dazu, weil ein Teil der Änderungen nicht sofort aktiv wird. Beim Auth Certificate denke ich sogar in mindestens 48 Stunden Vorlauf, nicht in Minuten.

So bleibt die Erneuerung eines Exchange-Zertifikats eine überschaubare Wartungsaufgabe statt eines Notfalls. Wenn die Typen sauber unterschieden sind, die Services korrekt zugewiesen werden und die Bindungen nach dem Wechsel geprüft sind, ist der Prozess in der Praxis deutlich ruhiger als viele Teams erwarten.