Exchange Edge Zertifikattausch

Alle Jahre wieder müssen Sie mittlerweile Zertifikate auf Webservern aber auch Exchange Servern tauschen, da offizielle PKIs keine längere Gültigkeitsdauer mehr ausstellen. Nicht viele Kunden nutzen einen Exchange Edge Server und mit dem Exchange Hybrid Mode aber auch EdgeSync kommen die Zertifikate gleich an mehreren Stellen vor. Ich berichte hier von einem geplanten Zertifikattausch, der dennoch zu einer Störung geführt hat, weil Exchange so gar nicht alles alleine macht, wenn mehrere Probleme zusammen kommen.

Wir haben eine Exchange 2016 Umgebung mit zwei Edge-Servern, die sowohl Richtung Internet als auch zu einem Office 365 Tenant ihre Mails übertragen und Empfangen. Es gibt hier mehrere Zertifikate bzw. Stellen, an denen Zertifikate eine Rolle spielen. Beide Server sind mit ihrem eigenen Namen als auch einem gemeinsamen Namen erreichbar und es gibt ein SAN-Zertifikat mit den Namen, welches jedes Jahr abläuft. Es sollte nicht vergessen werden, dass dieses Zertifikat nicht nur den SMTP-Datenstrom absichert, sondern auch die LDAP-Verbindung des EdgeSync.

In geplanter Manier hat das Monitoring rechtzeitig vor dem ablaufenden Zertifikat gewarnt. Es wurde aber nicht verlängert, sondern von einer neuen PKI neu ausgestellt und eingespielt. Es waren keine Störungen aufgetreten, bis das bisherige Zertifikat abgelaufen ist. Das hat Exchange 2013 Managed Availability dann auch gemeldet:

Log Name:      Microsoft-Exchange-ManagedAvailability/Monitoring
Source:        Microsoft-Exchange-ManagedAvailability
Date:          10/25/2020 1:16:58 PM
Event ID:      4
Task Category: Monitoring
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      edge1.msxfaq.de
Description:
Connector: 'Outbound to Office 365'
 Error: 'Exchange was unable to load certificate <I>CN=DigiCert Global CA G2, O=DigiCert Inc, 
C=US<S>CN=hybrid.msxfaq.de, OU=IT, O=msxfaq, L=hoevelhof, S=North Rhine-Westphalia, C=DE.

 More information below:
 IsFrontEndProxyEnabled: false.
 Original backend Server: hybrid.msxfaq.de.
 Send Connector Name from the original request: Outbound to Office 365'
Probe Exception: ''
Failure Context: ''
Execution Context: ''
Probe Result Name: 'Transport/CannotLoadSTARTTLSCertificateFromStore'
Probe Result Type: 'Failed'
Monitor Total Value: '0'
Monitor Total Sample Count: '1'
Monitor Total Failed Count: '1'
Monitor Poisoned Count: '0'
Monitor First Alert Observed Time: '10/25/2020 12:16:41 PM'


-------------------------------------------------------------------------------

States of all monitors within the health set:
Note: Data may be stale. To get current data, run: Get-ServerHealth -Identity 'COMGTEXEDGE01' -HealthSet 'EdgeTransport'

State    Name                                    TargetResource   HealthSet                  AlertValue     ServerComponent
-----    ----                                    --------------   ---------                  ----------     --------------- 
Online   EdgeTransport.ServiceInconsistentSta... EdgeTransport    EdgeTransport   Healthy    EdgeTransport       
Online   TransportMaxLocalLoopCountMonitor                        EdgeTransport   Healthy    EdgeTransport       
Online   MessagesDeferredDuringCategorization...                  EdgeTransport   Healthy    EdgeTransport       
Online   TransportLogSearchLogPathInvalidMonitor EdgeTransport    EdgeTransport   Healthy    EdgeTransport       
Online   UnreachableQueueMonitor                                  EdgeTransport   Healthy    EdgeTransport       
Online   Transport.LowDiskSpace.Monitor          EdgeTransport    EdgeTransport   Healthy    EdgeTransport       
Online   Transport.ServerCertMismatch.Monitor    EdgeTransport    EdgeTransport   Degraded   EdgeTransport       
Online   EdgeTransportServiceRunningMonitor                       EdgeTransport   Healthy    EdgeTransport       
Online   EdgeAvailabilityMonitor                                  EdgeTransport   Healthy    EdgeTransport       
Online   TransportLogSearchRunningMonitor        EdgeTransport    EdgeTransport   Healthy    EdgeTransport       

Allerding kann man das "Degraded" schon mal übersehen.

Allerdings ist die Meldung erst

Das Problem ist eigentlich nur aufgetreten, weil die alten Zertifikate nicht verlängert wurden, sich die ausstellende PKI sich geändert hat und Exchange an der Stelle nicht selbst die "neueren" und besseren Zertifikate nutzt

Dennoch helfen die Schritte der Analyse und Lösung beim Verständnis der Exchange Edge Funktion und ihnen vielleicht weiter.

  • Startpunkt: Die Warteschlangen auf dem Edge Server Richtung Office 365 laufen hoch
    Exchange kann also keine Mails mehr zu Office 365 senden. Das Eventlog sagt deutlich, dass das Zertifikat mit dem Thumbprint nicht mehr gültig ist. Auch wenn es ein neues gültiges Zertifikat mit dem gleichen CN gibt, nutzt Exchange es nicht.
  • Kontrolle Send-Connector
    Auf dem Edge Server sehen wir mit "Get-SendConnector", dass dort der Name der PKI und der CN des Zertifikats hinterlegt ist. Diese Eintragungen hat der Hybrid Configuration Wizard gemacht und ich bin sicher, dass viele Administratoren das so noch gar nicht gewusst haben.
  • Ursache: Die ausstellende PKI hat sich geändert
    Mit dem Zertifikatswechsel hat sich auch die PKI geändert. Damit war der CN zwar noch gleich aber der Aussteller nicht mehr. Also konnte Exchange gar nicht dieses Zertifikat switchen.
  • Set-Sendconnector geht nicht auf dem Edge
    Eine Änderung mit „Set-SendConnector“ ist aber nicht auf dem Edge möglich, da der Edge „ReadOnly“ ist und ich das auf dem Frontend machen muss.
    Die Konfiguration des Send-Connectors kommt ja per EdgeSync zu den Edge-Servern.
  • Set-SendConnector auf FE geht nicht
    Auf dem Frontend kann ich mit „Set-SendConnector“ nur Zertifikate auswählen, die auf dem FE auch installiert sind. technisch bedeutet das, dass das Zertifkat des Edge-Servers auf mindestens einem Frondend-Server importieren werden muss.
  • Zertifikat exportieren
    Zum Import muss man aber erst mal eine PFX-Datei haben. Schade, dass die Edge Zertifikate „nicht exportierbar“ waren, denn der Server steht ja "draussen" und bei der Anforderung wurde die Checkbox nicht aktiviert. Es könnte ein Plan sein, zukünftig die Edge-Zertifikate direkt auf einem Frontend im LAN exportierbar anzufordern und dann erst in die Edge-Server zu importieren. Dann hätte man zumindest intern ein "Backup" des Zertifikats für Desaster-Fälle und auf dem Edge müsste es ja nicht exportierbar sein.
  • Also „neues Zertifikat“ angefordert
    Wohl oder übel haben wir das dann nachgeholt und nun ein exportierbares Zertifikat erneut angefordert. Die nicht mehr "brauchbaren" Zertifikate können bei der PKI später zurückgezogen werden. Die meisten PKIs sind hier tolerant und schreiben dies gut für die nächsten Zertifikate. Ich habe auch darauf verzichtet mit Hackertools ein "nicht exportierbares Zertifikat" doch zu exportieren. Ich weiß wohl, dass und wie das geht.
  • Das neue Zertifikat bricht EdgeSync.
    Das war aber auch erwartet worden und ist an mehreren Stellen dokumentiert, dass man nach dem Zertifikatswechsel den EdgeSync neu einrichten muss.
  • EdgeSync funktioniert immer noch nicht
    Der Export und Import der XML-Datei war schnell erfolgt aber dennoch haben die Frontend-Server einen Fehler "„LDAP Server nicht erreichbar“ geliefert. Das ist etwas irreführend, denn der Server war sehr wohl erreichbar aber das Zertifikat beim AD LDS auf dem Edge war noch alt. Der Dienste brauchte einen Neustart, damit er das neue Zertifikat nutzt.
  • EdgeSync funktioniert nach ADLDS Neustart
    Nun hat der Edge wieder Daten von den Frontend Servern bekommen aber das Mailrouting war noch nicht gelöst, das das Zertifikat auf dem Send-Connector ja noch nicht geändert war.
  • Send-Connector anpassen
    Auf dem Frontend Server, auf dem das neue Zertifikat angefordert und installiert ist haben wir mit "Set-SendConnector" nun endlich den richtigen String für die PKI und CN eingetragen.
  • EdgeSync abgewartet
    Nach kurzer Zeit (meist <30 Sekunden) wurde diese Änderung auch zum Edge Server übertragen. Das konnten wir mit "Test-EdgeSynchronization" prüfen und mit Get-SendConector auf dem Edge-Server auslesen.
  • Edge Dienste noch mal durchgestartet
    Allerdings hat die Transportrolle das neue Zertifikat nicht sofort aktiviert. Hier hat dann ein Neustart des Exchange Transport Service die gewünschte Beschleunigung gebracht.
  • Und das ganze noch mal mit dem zweiten Edge Server
    Auch dort wurde das neue Zertifikat installiert, ADLDS neu gestartet, die Edge-Subscription neu eingerichtet

DAs ist ein schönes Beispiel, dass selbst zwei Edge Server in einer HA-Konfiguration nicht vor Unterbrechungen gefeit sind. Im ersten Moment frage man sich schon "Muss das denn so kompliziert sein?". Wenn ich mich an den Tausch der Zertifikate auf einem Frontend Server erinnere, dann sucht sich der Transport-Service alleine nach einem Entscheidungsbaum das beste Zertifikat. Aber beim Edge Server will er es eben genau wissen.

Auf der anderen Seite zeigt mir das wieder, dass es nicht sehr viele Edge-Installationen im Feld gibt, denn die ein oder andere Fehlermeldung war zwar selbsterklärend aber trotzdem nicht im Internet zu finden. Ich muss auch gestehen, dass das bei einer der wenigen Edge-Installationen passierte, bei denen ich ausgeholfen habe. Alle anderen kommen ohne diese Relaystationen aus. Was vielleicht auch besser ist.

Weitere Links