Receive Connector Zertifikate

Wie greifen bei einem Exchange Receive Connector die verschiedenen Einstellungen zu Bindungen, Zertifikaten und Authentifizierungen zusammen, damit auch Exchange Hybrid funktioniert.

Kurzfassung

Seit Exchange 2007 gibt es eine Hubtransport-Rolle, die für den Empfang und Versand von Nachrichten per SMTP zuständig ist. SMTP wird nicht nur genutzt, um Mails ins Internet zu senden und vom Internet zu empfangen, sondern auch Clients (Drucker, Anwender etc.) senden ggfls. Mails per SMTP an Exchange. Der aus meiner Sicht wichtigste Nutzer ist aber Exchange selbst, da in einer Umgebung mit mehreren Servern auch die Server untereinander per SMTP intensiv kommunizieren. Wenn Sie daher an der Konfiguration der Connectoren etwas verändern, dann sollten Sie speziell bei den "Default Connectoren" sehr vorsichtig sein.

Don’t modify the FQDN value on the default Receive connector named “Default ” that is automatically created on Hub Transport servers. If you have multiple Hub Transport servers in your Exchange organization and you change the FQDN value on the “Default ” Receive connector, internal mail flow between Hub Transport servers will fail.
https://docs.microsoft.com/en-us/previous-versions/office/exchange-server-2007/aa996395(v=exchg.80)#local-network-settings

Die meisten Einstellungen und Optionen habe ich auf der Seite Exchange 2007/2010 Receiveconnector beschrieben. Das Hauptaugenmerk dieser Seite ist der Empfang in einer Exchange Hybrid Umgebung.

Connectorwahl

Das Exchange Setup alleine richtet schon fünf ReceiveConnectoren ein, die für die unterschiedlichsten Einsatzfällte genutzt werden.

[PS] C:\>Get-ReceiveConnector -Server ex01 | fl identity,bindings,remoteipranges


Identity       : EX01\Default EX01
Bindings       : {0.0.0.0:2525, [::]:2525}
RemoteIPRanges : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}

Identity       : EX01\Client Proxy EX01
Bindings       : {[::]:465, 0.0.0.0:465}
RemoteIPRanges : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}

Identity       : EX01\Default Frontend EX01
Bindings       : {[::]:25, 0.0.0.0:25}
RemoteIPRanges : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}

Identity       : EX01\Outbound Proxy Frontend EX01
Bindings       : {[::]:717, 0.0.0.0:717}
RemoteIPRanges : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}

Identity       : EX01\Client Frontend EX01
Bindings       : {[::]:587, 0.0.0.0:587}
RemoteIPRanges : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}

Damit wird direkt offensichtlich, wie Exchange bei eingehenden Verbindungen den richtigen Connector auswählt. Es ist die eindeutige Übereinstimmung anhand der folgenden drei Informationen:

  • LocalIP
    Die IP-Adresse, des Exchange Servers, die angesprochen wird. Sie können einem Exchange Server durchaus mehrere IP-Adressen geben um weitere eindeutige Connectoren zu konfigurieren.
  • LocalPort
    SMTP kommt per Port 25 an aber Clients verbinden sich auch auf 465 oder 587. Die Ports 2525 und 717 nutzen Exchange intern und sollten nicht angesprochen werden. Das sichert aber Exchange schon durch reduzierte Berechtigungen auf "Exchange Server" ab.
  • RemoteIPRange
    Damit können Sie die einliefernde IP-Adresse als drittes Kriterium in die Connector-Auswahl einbeziehen.

Dabei gilt immer ein "Nearest Match Wins"-Prinzip, d.h. die Kombination aus "LocalIP:LocalPort" muss eh eindeutig sein und dann gewinnt der engste "RemoteIPRange"-Bereich. Exchange verhindert schon bei der Konfiguration, das sie dabei überlappende Bereiche definieren.

Kleiner Tipp: Sie können beim Connector mit dem Parameter "-Banner" einen abweichenden Text hinterlegen, der von Exchange dem Client angezeigt wird. Wenn sie viele Connectoren haben, können Sie hier den Namen anpassen und per TELNET einfach sehen, ob ihre Konfiguration passt.

TLS-Auswahl STARTTLS

Nachdem für eine eingehende Verbindung der passende Connector eindeutig bestimmt wurde, kommt die Frage des Zertifikats, welches für die Verschlüsselung per STARTTLS verwendet wird. Hier wird es dann wieder etwas knifflig, denn sie können an einen Connector nicht ein Zertifikat explizit binden. Der Prozess zur Einrichtung eines Zertifikats auf Exchange besteht aus mehreren Schritten:

  1. Zertifikat-Request erstellen und X.509v3-Zertifikat im Computerstore installieren
    Damit sollten im Zertifikatsspeicher des Computers das Zertifikat samt privatem Schlüssel liegen.
  2. Intermediate und Root einrichten
    Stellen Sie sicher, dass zum Zertifikat auch die Zwischenzertifikate und das Stammzertifikat in den richtigen Zertifikatspeichern liegen. Gerade beim Import einer PFX-Datei mit allen Zertifikaten landen diese gerne mal im "Personal"-Store und führen zu komischen Effekten.
  3. Enabled-ExchangeCertificate
    Nun müssen Sie das Zertifikat auch noch Exchange "bekannt" machen. Über den Thumbprint können Sie Zertifikat "aktivieren". Dabei werden Sie auch gefragt, ob es zum "Default Certificate" werden soll. Hier sollten sie "NEIN" sagen, wenn sie intern die Selfsigned-Zertifikate von Exchange weiter nutzen wollen.
  4. Optional: Parameter "TlsCertificateName" setzen
    Wobei ich hier nicht sicher bin, ob dieser Einstellungen eine Wirkung hat, wenn das Zertifikat nicht matched

Weitere Einstellungen oder eine explizite Bindung eines Zertifikats wie früher an einem  virtuellen SMTP-Server (Exchange 2000/2003) sind nicht möglich. Leider ist die Exchange-Dokumentation zur Auswahl des Zertifikats seit Exchange 2010 nicht mehr aktualisiert worden. Mit Exchange 2016 und neuer wurde der Ablauf erweitert. Darauf gehe ich im nächsten Abschnitt ein.

Der Ablauf startet nur für den Receive Connector, der anhand der LocalIP:LocalPort+RemoteIP-Auswahl als zutreffend bestimmt wurde.


Quelle
https://docs.microsoft.com/en-us/previous-versions/office/exchange-server-2010/bb430748(v=exchg.141)

Nur wenn auf dem Receive Connector überhaupt TLS aktiviert ist, dann sucht Exchange nach einem Hostname (Feld FQDN im Connector bzw. der Server FQDN). Mit dem Namen sucht er alle möglichen Zertifikate (Subject oder SAN). Die Ergebnisliste werden alle entfernt, die ungültig (nicht X509v3+, kein Private Key. nicht Exchange enabled) sind. Dann wird nach "ValidFrom" sortiert, um das aktuellste Zertifikat zu bevorzugen. Zuletzt werden PKI-Zertifikate einer vertrauenswürdigen PKI den "Selfsigned" Zertifikaten vorgezogen. Und dann kommt noch die Frage nach dem ValidTo-Feld. Anscheinend gibt es keinen CRL-Check hier und wenn das verbliebene Zertifikat abgelaufen ist, wird es dennoch verwendet. (OpportunisticTLS).

Hinweis: Mit SAN-Zertifikaten kann Exchange nur den ermittelten FQDN des Connectors suchen. Exchange sieht nicht, welchen Namen die Clients bei der Verbindung erwarten. Bei HTTPS gibt es ein SNI-Feld, was hier nicht hilft, denn die Connectorauswahl geht nur über LocalIP:LocalPort + RemoteIP. Achten Sie daher darauf, dass Sie bei SAN-Zertifikaten den Hostnamen auf einen der Namen des gewünschten Zertifikats setzen.

TLSCertname

Nun könnte es sein, dass nach der ganzen Auswertung noch mehrere Zertifikate zur Auswahl stehen und das von der Transportrolle ausgewählte Zertifikat nicht das gewünschte Zertifikat ist. Exchange behandelt ja alle Zertifikate gleich und mit vielen Connectoren könnten Sie ja schon gezielt ein Zertifikat pro Connector vorsehen. Das ist mit Exchange 2016+ erweitert worden:

The TlsCertificateName parameter allows you to specify the certificate issuer and the certificate subject. This helps minimize the risk of fraudulent certificates.
Receive connector changes in Exchange Server https://docs.microsoft.com/en-us/exchange/mail-flow/connectors/receive-connectors?view=exchserver-2019#receive-connector-changes-in-exchange-server

Damit erlaubt mir Exchange ein Zertifikat für einen Connector vorzugeben. Microsoft hat dabei allerdings eine gewöhnungsbedürftige Parametrisierung gewählt. Sie müssen das Subject und den Aussteller in einem String kombinieren.

$TLSCert = Get-ExchangeCertificate -Thumbprint <Thumbprint>
$TLSCertName = "<I>$($TLSCert.Issuer)<S>$($TLSCert.Subject)"

Set-ReceiveConnector `
   -Identity "EX16\Client Frontend EX16" `
   -TlsCertificateName $tlscertName

An anderen Stellen kommt häufiger der Thumbprint zum Einsatz, der sich aber bei jedem Zertifikat ändert, selbst wenn Subject und Aussteller gleich bleiben. Daher ist es in Hinsicht auf das Zertifikatmanagement und Erneuerung durchaus besser, sich auf den Namen zu beziehen. Sollte das angegebene Zertifikat aber nicht nutzbar sein, dann bleibt die bisherige Auswahl aktiv und notfalls fällt Exchange auf das "Default Certificate" zurück.

Default Certificate

In dem Konstrukt der Zertifikate gibt es noch ein "Default Certificate", welches auf den Server gebunden. Wenn Sie ein neues Zertifikat per ECP oder Enable-ExchangeCertificate aktivieren, werden Sie auch immer gefragt, ob sie auch das "Default Certificate" ändern wollen.

Das aktuelle Zertifikat können Sie leider nicht per Exchange Commandlet direkt auslesen. Aber eine Suche im AD liefert es im Feld "msExchServerInternalTLSCert" des Exchange Serverobjekts und mit etwas PowerShell erhalten wir auch den Subject, Issuer und Thumbprint

$serverdn = (Get-Exchangeserver $env:computername).distinguishedname
$servercert = (Get-ADObject -Identity $serverdn -Properties msExchServerInternalTLSCert).msExchServerInternalTLSCert
$certinfo = New-Object system.security.cryptography.x509certificates.x509certificate2 -ArgumentList @(,$servercert)

$certinfo | fl

Subject : CN=EX01
Issuer : CN=EX01
Thumbprint : DEA2524BB9F986B77B8DDEB8A40A633D2ECE4EE6
FriendlyName : Microsoft Exchange
NotBefore : 01.01.2022 12:09:35
NotAfter : 01.01.2027 12:09:35
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
System.Security.Cryptography.Oid}

Interessanter ist nun aber, wozu das Zertifikat genutzt wird. Ich habe bislang die Information, dass Exchange Server untereinander bei der internen Kommunikation natürlich alles per TLS verschlüsseln und dabei nicht nur das Zielsystem ein Zertifikat anbieten muss, sondern auch der initiierende Server seinerseits seine Identität per Zertifikat nachweist. Exchange nutzt MTLS, damit beide Partner einer Kommunikation sich gegenseitig identifizieren können.

Das gilt insbesondere beim Einsatz von Exchange Edge Servern, die ebenfalls mit dem internen Zertifikat arbeiten. Per Default sind die internen Zertifikate "SelfSigned" und 5 Jahre gültig. Wer seinen Server länger betreibt kann aber muss es nicht tauschen. Kritischer ist die Installation weiterer Zertifikate.

Bei der Installation weiterer Zertifikate würde ich die Rückfrage nach dem Tausch des Default Zertifikats immer mit "NEIN" beantworten.

TLS abfragen

Ich habe noch keinen Weg gefunden, wie ich die "Zertifikatauswahl" im Eventlog oder Traces nachvollziehen kann. Aber ich muss gar nicht auf den Server, sondern kann schon mit einfachen Tools ermitteln, was das Ergebnis ist. Wenn es ein Connector ist, der erst einmal "unverschlüsselt" reagiert, dann prüfe ich mit einem einfachen TELNET mit EHLO auf STARTTLS.

Diese erste Verbindung ist noch unterschlüsselt und ich sende ein "EHLO test" um vom Server eine Liste der angebotenen Befehle zu erhalten. Hier muss STARTTLS mit enthalten sein. Wenn STARTTLS fehlt, hat Exchange kein Zertifikat gefunden.

Mit dem STARTTLS Angebot möchte ich nun aber auch wissen, welche Zertifikat genutzt wird. Dazu bediene ich mich OpenSSL, um eine Verbindung zum Server mit Anzeige des Zertifikats:

C:\>openssl.exe s_client -connect mail.netatwork.de:25 -starttls smtp
CONNECTED(00000270)
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
 0 s:/C=DE/ST=Nordrhein-Westfalen/L=HOEVELHOF/O=FCEDV/CN=hybrid.msxfaq.de
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign RSA OV SSL CA 2018
 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign RSA OV SSL CA 2018
   i:/OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGujCCBaKgAwIBAgIMGcv71nL2SKTZIj3CMA0GCSqGSIb3DQEBCwUAMFAxCzAJ
....
2TDEeH71Fp7n1LyzczdKbPcGE7kVxYcUeJT53ephvWbLRsB6xC/XowVXzLljLQ==
-----END CERTIFICATE-----
...
---
250 SIZE
QUIT

Die Ausgabe zeigt hier die "Certificate Chain" mit dem Zertifikat selbst, dem Aussteller (Intermediate) und der Root.

Wenn der Connector direkt mit TLS startet, z.B. auf Port 465 dann kann ich mit die STARTTLS-Prolog sparen und direkt die Verbindung aufbauen.

C:\>openssl.exe s_client -connect mail.msxfaq.de:465
....

Die Ausgabe ist vergleichbar.

Banner

Vielleicht ist ihnen auch der Parameter "-Banner" bei der Konfiguration des ReceiveConnectors per PowerShell aufgefallen. Über diesen Weg können Sie für jeden individuellen Connector den String anpassen, den ein Client als Willkommensmeldung angezeigt bekommt. Sie können das einfach Testen, in dem Sie einen Connector anlegen, der einfach nur einen anderen Port (z.B. 26) nutzt:

New-ReceiveConnector `
   -Name "FrankTest" `
   -Bindings "0.0.0.0:26" `
   -AuthMechanism none `
   -RemoteIPRanges "0.0.0.0/0"

Identity       Bindings     Enabled
--------       --------     -------
EX16\FrankTest {0.0.0.0:26} True

Wenn ich mich dann per TELNET <Exchangeserver>:26 verbinde, sehe ich den neuen Banner-

Das ist übrigens eine sehr einfache Möglichkeit, bei mehreren Connectoren auf einem Server mit der gleichen LocalIP:LocalPort-Kombination den effektiv genutzten Connector zu ermitteln.

Passend dazu habe ich ihnen einen PowerShell Einzeiler bereitgestellt, der den Namen des Receive Connectors mit dem "220 "-Prefix als Banner setzt.

Get-ReceiveConnector `
   | %{`
        Set-ReceiveConnector `
           -Identity $_.identity  `
           -Banner "220 $($_.identity)"   `
      }

Diese Änderung sollte eine Wiedererkennung des Connectors per TELNET sehr einfach machen und stört nicht den TLS-Handshake oder die Auswahl des Connectors.

Problem: Hostname <> Public

Ein sicher häufiges Problem besteht darin, dass der Exchange Server intern einen DNS-Namen hat, der nicht im Internet genutzt werden kann, z.B. "ex01.msxfaq.local". Wenn Sie den Exchange Server über z.B. Port 25 aus dem Internet erreichbar machen, müssen Sie daher dem gewünschten ReceiveConnector erst einen FQDN-Hostnamen verpassen, damit Exchange das hinterlegte öffentliche Zertifikat nutzt. Das funktioniert aber nicht, wenn der Connector auch von Exchange selbst verwendet wird:

[PS] C:\>Set-ReceiveConnector "EX16\Default Frontend EX16" -Fqdn hybrid.msxfaq.de
If the AuthMechanism attribute on a Receive connector contains the value ExchangeServer, you must set the FQDN
parameter on the Receive connector to one of the following values: the FQDN of the transport server
"EX16.netatwork.de", the NetBIOS name of the transport server "EX16", or $null.

Wenn ihr Exchange Server intern z.B. "EX01.msfaq.local" heißt, dann wird der Connector hier nie ein "öffentliches Zertifikat" nutzen, welches Sie für eine sichere externe Verbindung aber gerne verwenden wollen.

Das ist damit begründet, dass Exchange für das interne Routing zwischen Exchange Servern den FQDN des Servers nutzt und bei der Suche nach dem Ziel eben alle ReceiveConnectoren sieht, bei denen "Exchange Server" und "Exchange LegacyServer" aktiviert sind:

Wenn Sie diese Konfiguration aber anpassen, dann könnte das ihre interne Exchange Kommunikation stören.

Ich würde die Default Connectoren nur in Ausnahmefällen anpassen.

Besser ist es wenn Sie einen neuen Connector für ihre eigenen Zwecke anlegen. Den können Sie z.B. anhand der Remote-IP wirken lassen. Ein 0.0.0.0/0 geht natürlich nicht, da diese Range schon der Default Connector hat, aber sie können so z.B. Client-Netzwerke oder wegen mir auch Office 365 Netzwerke oder generell externe Netzwerke abweichend behandeln lassen.

Sie können natürlich auch einen eigenen Connector für die interne Exchange Kommunikation anlegen. Er wird genau wie der normale Default Connector konfiguriert und bekommt als RemoteIP-Range einfach die IP-Adressen aller Exchange Server. Damit wäre die interne Kommunikation sicher aber sie müssten natürlich immer darauf achten, dass jeder neue Exchange Server in die Liste bei allen anderen Exchange Servern aufgenommen wird. Dann ist der umgekehrte Weg besser, dass Sie eigene Connectoren für bestimmte Anwendungsfälle anlegen.

Externe Receive Connectoren

In einer kleinen Umgebung gibt es nur den "Default Receive Connector", der vom HCW - Hybrid Configuration Wizard auch für Exchange Online konfiguriert wird. Aber vielleicht möchten Sie ja gar nicht den "Default Connector" aus dem Internet oder von Clients erreichbar machen. Mittlerweile nimmt er ja auch standardmäßig anonyme Verbindungen an.

Wenn ihr interner Exchange Server einen FQDN nutzt, der im Internet nicht nutzbar ist oder nicht sichtbar sein soll oder sie dafür kein Zertifikat haben, dann müssen Sie ja für den Einsatz von TLS einen eigenen Connector anlegen, der auch einen passenden FQDN hat und bei dem gerade das Feld "AuthMechanism" kein "Exchange Server" enthält.

[PS] C:\>Get-ReceiveConnector | ft name,authmechanism -AutoSize

Name                                                                           AuthMechanism
----                                                                           -------------
Default EX01                 Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer
Client Proxy EX01            Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer
Default Frontend EX01        Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer
Outbound Proxy Frontend EX01 Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer
Client Frontend EX01                         Tls, Integrated, BasicAuth, BasicAuthRequireTLS

Bei allen Connectoren, bei denen AuthMechanism ein "Exchange Server" enthält, ist der FQDN auf den Servernamen festgelegt und kann nicht verändert werden. Daher macht es natürlich mehr Sinn, einen eigenen ReceiveConnector z.B. für Office 365 anzulegen. Sie habe hier nun natürlich die Wahl, wie die Cloud diesen neuen Connector erreicht. Zwei Einstellungen helfen ihnen dabei:

  • ZieI-IP
    Sie könnten eine eigene öffentliche IP-Adresse über Port 25 erreichbar machen und auf eine zusätzliche IP-Adresse des Exchange Servers per NAT weiterreichen lassen. Wenn ihr NAT-System auch Ports umsetzen kann, könnte der Zugriff aus der Cloud auf z.B. hybrid.<firmendomain> auch auf einen anderen Port des Exchange Servers verweisen, auf dem Sie ihren eigenen Connector anlegen
  • Source-IP
    Wenn beim Exchange Server auch die Quell-IP-Adresse von extern ankommt, dann könnten Sie auch die SourceIP-Adresse von Office 365 verwenden. Voraussetzung ist natürlich, dass der davorstehende Loadbalancer oder NAT-Router auch eindeutig identifizierbare Source-IP-Adressen an Exchange sendet; sei es die private Source-IP des NAT/Loadbalancers oder die öffentliche Adresse der Gegenseite. Allerdings kann es schon mal passieren, dass Microsoft neue Adressen addiert. Ein anderes Problem ist, wenn der MX-Record ihrer Domain dann auf den gleichen Connector verweist und andere Tenants ihnen einen Mail senden. Das ist aber aufgrund des schwachen Spamfilters von Exchange On-Premises eher unwahrscheinlich.

Sie legen also einen neuen Connector an. Ich nutze exemplarisch einen Connector auf dem Port 26:

New-ReceiveConnector `
   -Name "Inbound hybrid" `
   -Fqdn hybrid.msxfaq.de `
   -RequireTLS $true `
   -AuthMechanism tls `
   -Bindings 0.0.0.0:26 `
   -RemoteIPRanges 0.0.0.0/0 `
   -Banner "220 Inbound Hybrid"

Identity                                Bindings                                Enabled
--------                                --------                                -------
EX01\Inbound hybrid                     {0.0.0.0:26}                            True

Ich brauche nun natürlich ein X409v3-Zertifikat auf den Namen "hybrid.msxfaq.de", welches auf dem Exchange Server installiert und mit Enable-ExchangeCertificate für den Service SMTP aktiviert sein muss. Wenn das aber das einzige passende Zertifikat ist dann muss ich nicht extra den "TLSCertname" setzen. Ich kann testweise auch ganz schnell so ein Zertifikat anlegen:

New-ExchangeCertificate `
   -Services smtp `
   -SubjectName "cn=hybrid.msxfaq.de"

Ohne weiteren Neustart sehe ich bei der nächsten Verbindung das Zertifikat:

c:\> openssl.exe s_client -connect localhost:26 -starttls smtp

WARNING: can't open config file: /usr/local/ssl/openssl.cnf
CONNECTED(00000154)
depth=0 CN = hybrid.msxfaq.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = hybrid.msxfaq.de
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/CN=hybrid.msxfaq.de
   i:/CN=hybrid.msxfaq.de
---
Server certificate
-----BEGIN CERTIFICATE-----

Beachten Sie nun aber, dass der testweise angelegte Connector auf Port 26 lauscht. Das bedeutet nun mehrere Dinge für das weitere Setup, da kein Mailserver normalerweise auf Port 26 kommuniziert:

  • Port NAT
    Exchange Online verbindet sich z.B. immer nur mit Port 25, so dass ich auf meiner Firewall nur nur eine IP-Adressumsetzung sondern auch noch eine Port-Translation von 25/tcp -> 26/tcp einsetzen müsste, wenn der Connector von extern erreichbar sein wollte.
  • Berechtigungsgruppen "Anonym" und "Exchange Benutzer" entfernen
    Zudem sollte ich nicht darauf vertrauen, dass nicht doch ein interner Client versucht sich mit dem Connector zu verbinden. Ein Portscan auf die IP-Adresse des Exchange Servers wird diesen Port sehr schnell aufdecken. Das ist aber dann nicht mehr kritisch, wenn Sie den Connector passend konfiguriert haben. Damit ist eine Nutzung auf Exchange Server beschränkt.
  • Exchange Hybrid Konfiguration durchführen
    Damit wird z.B. das Feld "TlsDomainCapabilities" entsprechend gefüllt, dass nur noch die passende Gegenstelle den Vertrauensvorschuss bekommt.

Das gilt natürlich für jeden neuen Connector, über den ihr Exchange Server eingehende Verbindungen annimmt.

Exchange Hybrid Routing

Durch den Exchange Hybrid Configuration Wizard werden in Exchange Online ihres Tenants und im lokalen Exchange Server entsprechende Connectoren angelegt. Allerdings leg der neue HCW nur noch drei Connectoren an aber von Exchange Online zu Exchange On-Premises wird kein separater Receive Connector angelegt. Stattdessen wird der "Default Frontend <servername>" um zwei Einstellungen erweitert

Fqdn                                      : EX01.UCLABOR.DE
lsCertificateName                        : <I>CN=EX01<S>CN=EX01
TlsDomainCapabilities                     : {mail.protection.outlook.com:AcceptCloudServicesMail}
Name                                      : Default Frontend EX01

Damit klappt das Hybrid-Setup natürlich nicht, da er das "Default Certificate" des Server genommen hat. Dies war aber SelfSigned. Aber interessanter ist hier der Parameter "TlsDomainCapabilities", über den Exchange On-Premises angewiesen wird, Mails als "CloudServicesMail" zu behandeln.

Wenn ich aber einen eigenen Connector für den Empfang aus Exchange Online manuell angelegt habe, dann muss ich dies dort auch setzen.

Set-ReceiveConnector `
   -Identity "Inbound hybrid" `
   -TlsDomainCapabilities: {mail.protection.outlook.com:AcceptCloudServicesMail}

Eigentlich wundere ich mich etwas, dass Microsoft diese Einstellung nicht einfach bei allen Connectoren durch den HCW setzt. Dann wäre es unkritisch, bei welchem Connector die eingehende Verbindung letztlich ankommt.

Passend dazu legt HCW auch in Exchange Online einen "Outbound Connector" an, der aber auch per Default "streng" ist und den CN des Exchange Server Zertifikats (EX01) als auch eine "Trusted certificate Authority (CA)" vorgibt:

Das kann ich natürlich abschwächen, indem ich beliebige Zertifikate erlaube oder den Namen anpasse.

Microsoft geht bei Hybrid einfach davon aus, dass die Cloud immer den "Default Frontend <servername>" erreicht und dieser Connector auch ein gültiges Zertifikat hat.

Alle anderen Umgebungen müssen vorsichtig nachkonfigurieren.

Übrigens:
Wenn ich die Mails über einen Edge-Server route, dann wird auf den Frontend-Servern im LAN gar nichts verändert und der ReceiveConnector auf dem Edge Server bekommt die Einstellung "AcceptOorgProtocol". Siehe auch XOORG und Exchange

Zum Thema Hybrid Message Routing gibt es ein sehr sehenswertes Video von Arindam Thoker:

Establishing Exchange Hybrid Mailflow
https://youtu.be/1i_SO6nKe0o?t=751

Zusammenfassung

Ich hoffe, ich habe etwas Licht in die Funktionsweise des Exchange Transport-Service in Verbindung mit Zertifikaten gebracht. Sie können seit Exchange 2016 mittlerweile ein bestimmtes Zertifikat über den Parameter "TLSCertname" zur Bindung vorgeben. Dennoch kann das Thema verwirrend sein, wenn sie mehrere Connectoren betreiben und auch noch Exchange Online einsetzen. Der HCW konfiguriert beim Hybrid Mode seinen "Standard", der aber nicht zwingend passen muss. Mit etwas Wissen um die Zusammenhänge können Sie aber die Konfiguration anpassen.

Vergessen Sie dabei aber nicht, dass Zertifikat auch einmal ablaufen und eine Überwachung daher ratsam ist.

Weitere Links