Exchange Edge Zertifikattausch

Ein Exchange Edge Server kommuniziert per SMTP mit anderen Servern und beim Einsatz von Zertifikaten können Sie Mails mittels STARTTLS zumindest auf dem Transport verschlüsseln. Das geht zwar auch mit "eigenen Zertifikaten", was dann als "Opportunistic STARTTLS" bezeichnet wird aber immer mehr kommen auf dem Edge Server entsprechende offizielle Zertifikate zum Einsatz, um z.B. die Verbindung zu Partnern oder zum eigenen Office 365 Tenant abzusichern. Das Zertifikat wird aber auch für die interne Kommunikation genutzt, so dass ein Zertifikatswechsel auf dem Edge Server auch eine Aktualisierung der Konfiguration erforderlich macht. Bei öffentlichen Zertifikaten einer PKI ist dies mittlerweile jedes Jahr erforderlich.

Zertifikat auf Edge

Der Exchange Edge Server nutzt Zertifikate nicht nur für die Übertragung von Mails per SMTP und STARTTLS sondern auch für die Verbindung der internen Exchange Server zum ADAM/LDAP-Server auf dem Edge. welcher über Port 50636 erreichbar ist. Der interne Exchange Server prüft also genau das Zertifikat, welches bei der Einrichtung der Edge-Subscription verwendet wurde.

The ESBRA credentials are retrieved from AD LDS and written to the Edge Subscription file. The public key for the Edge Transport server's self-signed certificate is also exported to the Edge Subscription file. The credentials written to the Edge Subscription file are specific to the server that exported the file.
https://docs.microsoft.com/en-us/exchange/architecture/edge-transport-servers/edge-subscriptions?view=exchserver-2019#create-and-export-an-edge-subscription-file-on-the-edge-transport-server

Standardmäßig nutzt der Exchange Server ein "Self signed"-Zertifikat, welches 5 Jahre gültig ist. Wenn Sie damit Edge einrichten, dann haben Sie die ersten 5 Jahre quasi keine Probleme aber Sie können natürlich über SMTP dann eine Zertifikatsprüfung erzwingen. All meine Kunden haben daher das SelfSigned-Zertifikat auf dem Edge Server ersetzt.

Ablauf erkennen

Entsprechend passiert es, dass diese Zertifikate irgendwann ablaufen. Es gibt mehrere Stellen und Optionen, wie Sie das verwendete Zertifikat überprüfen können.

  • PKI-Meldung
    Einige Zertifizierungsstellen sind so freundlich und senden ihnen eine Mail zu, wenn ein Zertifikat bald abläuft. Netter Service, der aber natürlich nicht uneigennützig ist. Das neue Zertifikat kostet ja wieder Geld. So eine Meldung können Sie natürlich auch von ihrer internen PKI generieren lassen.
  • Exchange PowerShell auf dem Server
    Ein "Get-ExchangeCertificate" zeigt schnell die Zertifikate und deren Ablaufdatum und Usages. So sollten Sie früh genug erkennen können, wann ein Zertifikat abläuft, z.B. per Inventory-Software oder Monitoring.
  • TCP-Connection
    Es gibt mehrere Tools, mit denen Sie eine Verbindung zu einem Service aufbauen und das angebotene Zertifikat prüfen können. z.B. Get-TCPCert für den Zugriff auf den ADAM per LDAPs 50636 und auch mit OpenSSL können Sie eine SMTP-Verbindung mit STARTTLS machen. Allerdings muss ihr Monitoring dazu natürlich die Edge-Server auf diesen Ports erreichen können, was nicht immer einfach in einer DMZ ist
  • Exchange 2013 Managed Availability
    Exchange überwacht sich ja mittlerweile selbst und Probleme bei der TLS-Verbindung zu einem Server werden hier erkennt und gemeldet. Sie können die Daten per PowerShell abfragen.
  • Eventlog
    Auch im Windows Eventlog finden Sie Meldungen, wenn das Zertifikat nicht mehr funktioniert.
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       

Allerdings kann man das "Degraded" schon mal übersehen und die Meldung wird erst sichtbar, wen es schon zu spät ist.

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

Checkliste Zertifikatwechsel

Wenn Sie erkannt haben, dass ein Zertifikat bald abläuft, dann können Sie natürlich rechtzeitig dafür sorgen, dass das bestehende Zertifikat verlängert oder ein neues Zertifikat neu ausgestellt wird.

Bei einer Verlängerung bleibt das Schlüsselmaterial (Privat/Public-Key) gleich aber der Thumbprint ändert sich dennoch

Da Exchange die Bindnug aber über den Thumbprint realisiert, reicht es nie einfach nur das neue Zertifikat "daneben" zu legen, sondern Sie müssen es auch auf dem Edge-Server aktivieren:

Enable-ExchangeCertificate -thumbprint xxxxx -services SMTP

Dieses Vorgehen reicht in der Regel für einen Exchange Server, der sich aus den vorhandenen Zertifikaten dann schon das "passende" Zertifikat holt. Auf dem Edge-Server ist dies aber nur ein kleiner Teil. Daher hier meine Checkliste

Aktion OK

Zertifikat einspielen

Sie können dazu mit New-ExchangeCertificate ein neues Zertifikat auf dem Edge-Server rechnen und den Request dann einer PKI zum signieren vorlegen und das Zertifikat installieren. Einige PKIs senden ihnen auch eine fertige PFX-Datei, die sie einfach nur importieren müssen.

Denken Sie auch daran, dass sie die komplette Zertifikatskette einer 3rd-Party-PKI einrichten müssen.

Wichtig: Das Zertifikat auf den Edge-Servern darf nicht mit dem Zertifikat auf den Hub/Transport-Servern identisch sein. Beim Einrichten der Edge-Subscription wird der Thumbprint geprüft und sie bekommen folgenden Fehler:
"The subscription file failed to load for the following reason: The direct trust certificate of the subscribed Edge Transport Server with the thumbprint yyyyyy is a duplicate of th certificate of one of the Hubtransport server. Sharing the same certificate between Edge and Hub Transport servers is not allowed"

"The subscription file failed to load for the following reason: The direct trust certificate of the subscribed Edge Transport server with the thumbprint xxx is a duplicate of the certificate of one of the Hubtransport servers."

Edge-Server "offline" nehmen

Durch den Zertifikatwechsel muss kurz die Subscription entfernt und neu eingerichtet werden. In der Zeit möchten Sie vielleicht nicht, dass der Edge-Server noch Mails beantwortet. Ich mache das dann in der Regel wie folgt:

# Exchange SMTP-Service anhalten. Damit nimmt er keine neuen Verbindungen mehr an aber baut seine Queue ab
Suspend-Service msexchangetransport

# Kontrolle der Queue, dass alle Mails rausgegangen sind
Get-Queue

# SMTP-Service komplett stoppen
Stop-Service msexchangetransport

Wenn ihr Setup aus Loadbalancer, DNS und dem zweiten Edge-Server nun korrekt ist, sollte dieser Server keine Mails mehr bekommen und auch keine mehr senden müssen.

Zertifikat aktivieren

Nun aktiviere ich das neue Zertifikat für den Einsatz mit SMTP und kann im gleichen Zuge das alte Zertifikat deaktivieren

Enable-ExchangeCertificate `
   -Thumbprint xxxxxx -services SMTP

Dadurch sollte dieses Zertifikat auch das neue "Default Certificate" werden.

Edge Subscription Teil 1

Auf dem Edge Server erstelle ich nun wieder eine neue Edge-Subscription

New-EdgeSubscription  `
     -FileName "C:\temp\EdgeSubscriptionInfo.xml"

Ich habe per Default nun 1440 Minuten (24h) Zeit, diese Datei wieder zu importieren. Der Befehl hat ein temporäres Benutzerkonto in der Edge ADAM-Datenbank angelegt, mit dem sich Exchange erstmals verbindet. Diese Datei kopiere ich auf einen der Exchange Hub/Transport-Server.

Edge Subscription

Ich gehe davon aus, dass der Server schon eine Edge-Subscription hat. Leider kann ich diese nicht "updaten" sondern muss sie entfernen und wieder neu einrichten.

Remove-EdgeSubscription <edgeservername>
New-EdgeSubscription ` 
   -FileData ([System.IO.File]::ReadAllBytes('C:\temp\EdgeSubscriptionInfo.xml')) ` 
   -Site <adsitename> ` 
   -CreateInboundSendConnector:$false `
   -CreateInternetSendConnector:$false

Für einen kurzen Moment wird im Exchange der Edge-Server entfernt und dann wieder addiert. Bei einer Neuneinrichtung ist es ok, wenn das Commandlet auch die Connectoren zum Edge einrichtet. Wenn ich diese aber schon "habe", weil ich z.B. mehrere Edge-Server betreibe und diese vielleicht noch angepasst habe, dann ist eine Neuanlage vielleicht kontraproduktiv. Daher unterbinde ich das hier.

Edge im Connector addieren

Allerdings ist der alte und zugleich neue Edge damit erst einmal arbeitslos. Ich muss nun schon in den Send-Connectoren den Edge-Server eintragen. Die meisten meiner Kunden haben aber komplexere Routing-Topologien und damit mehrere Send-Connectoren mit unterschiedlichen Smarthosts für verschiedene Domänen. Da möchte ich schon selbst noch einmal drüber schauen, welcher Connector welchen Edge-Server nutzt.

Edge-Sync kontrollieren

All diese Änderungen sollten durch die Edge-Replikation nun zu dem neu eingerichteten Edge-Server übertragen werden. Da beim EdgeSync nicht nur die Konfiguration sondern auch die Empfänger übertragen werden, kann dass durchaus etwas dauern, bis die lokale ADAM-Datenbank des Edge-Servers wieder alle Daten hat. So lange sollte der Edge Server noch keine Mails annehmen. Der SMTP-Dienst ist ja immer noch gestoppt. Das lokale AD sollte die neue Subscription und Änderungen der Connectoren ja schon innerhalb der Site repliziert haben. Die Edge-Replikation kann ich so aber schnell forcieren:

Start-EdgeSynchronization ` 
   -TargetServer <fqdn des edge servers> `
   -ForceFullSync

Und den Status kann ich dann einfach mit folgendem Befehl abfragen:

Test-EdgeSynchronization ` 
   -TargetServer <edge-Server>

Als letzte Prüfung schaue ich, ob die mit diesem Edge konfigurierten Konnectoren auch tatsächlich auf dem Edg-Server vorhanden sind.

Get-Send-Connector

Edge und Exxchange Hybrid

Wenn Sie Exchange Hybrid mit dem HCW - Hybrid Configuration Wizard über Edge-Server einrichten, dann hat sich durch die Neueinrichtung der Edge-Synchronisierung nichts geändert. Aber der HCW sagt ihnen nach der Einrichtung, dass Sie noch eine manuelle Konfiguration auf dem Edge Server durchführen müssen. Diese Einstellungen sollten wir zumindest prüfen, ob Sie noch da ist.

# Anzeige der Receive Connector Konfiguration

Get-ReceiveConnector | fl identity,TlsDomainCapabilities,fqdn

#ggfls Eintragen der Konfiguration
Set-ReceiveConnector `
   -Identity "<Edge server name>\Default internal receive connector <Edge server name>" `
   -TlsDomainCapabilities mail.protection.outlook.com:AcceptOorgProtocol `
   -Fqdn "subject name on the public cert on Edge"

Nu wenn der Wert von "TlsDomainCapabilities" auf "mail.protection.outlook.com:AcceptOorgProtocol" steht, funktioniert Hybrid sauber. Allerdings dürfte die neue Paarung den Empfangsconnector nicht verändert haben.

Edge SMTP in Betrieb nehmen

Nachdem sichergestellt ist, dass Zertifikate und Konfiguration korrekt sind und die Replikation funktioniert, kann der SMTP-Dienst wieder gestartet werden.

Start-Service msexchangetransport

Prüfen Sie danach, dass die Mails auch über den Server korrekt laufen, indem Sie das Messagtracking und die Queues überwachen. Ich wünsche ihnen, dass diese "Funktionskontrolle" das Monitoring für sie übernimmt, denn es sollte ja eine Dauerüberwachung sein und nicht nicht einmal durch den Admin nach einer Änderung erfolgen.

Wenn Sie nun mehrere Exchange Edge-Server haben, dann können Sie nun den nächsten Server angehen.

Analyse-Schritte

Nicht immer läuft alles reibungslos und im Laufe der Zeit habe ich mir schon einige Tests und Prüfungen überlegt, mit denen ich bei Problemen der Ursache nahekomme. Ich habe ihnen hier einige Prüfungen und deren Bedeutung aufgeschrieben. Sie helfen vielleicht nicht nur bei der Analyse und Lösung von Problemem, sondern fördern auch das Verständnis der Exchange Edge Funktion:

  • 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 Zertifikat 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 "draußen" 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

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