Exchange Zertifikat Insights

Ohne Zertifikate geht in Exchange nicht viel. Exchange nutzt diese aber nicht zur im IIS zu Absicherung von OWA und ActiveSync sondern auch zur Absicherung von POP3, IMAP4 und insbesondere SMTP, die OAUTH Authentifizierung u.a. Höchste Zeit also, mal zu schauen, wo Exchange die Zertifikate konfiguriert sind.

Exchange Zertifikate

Sobald Sie einen Exchange Server installieren, werden Sie mehrere neue Zertifikate auf dem Server finden. Bei dem ersten Exchange 2016 Server habe ich in meinem Labor folgende Zertifikate gefunden:

  • cn=Microsoft Exchange Server Auth Certificate
    Dieses Zertifikat wird zwischen allen Servern über das Active Directory repliziert und zur internen Authentifizierung. Wenn sie weitere Exchange Server installieren, dann nutzen diese das gleiche Zertifikat.
  • cn=EX01
    Das ist ein "selbst signiertes" Zertifikat des Exchange Servers damit er generell erst einmal Verbindungen per TLS verschlüsseln und signieren kann. Es ist zwar für keinen Client vertrauenswürdig aber sie können dies später ja tauschen. Für den Start kann Exchange damit aber auf jeden Fall schon einmal "Opportunistic TLS" anbieten. Eine Übertragung ist dann immer noch verschlüsselt und ein Lauscher kann erst einmal nichts mehr mitlesen. Es schützt aber nicht gegen "Man in the Middle"-Attacken oder TLS-Downgrades durch Angreifer, was aber mit Aufwand verbunden ist. Jeder Exchange Server stellt hier sein eigenes Zertifikat aus.
  • cn=WMSvc-EX01
    Diese Windows Management SelfSigned Zertifikat dient der internen Kommunikation und Absicherung.

Die Zertifikate liegen ganz normal im Computer Zertifikatsspeicher:

Soweit ist das noch nicht überraschend aber für einen produktiven Betrieb natürlich nicht ausreichend. Keines der drei Zertifikate ist für den Zugriff von Clients wirklich geeignet.

Eigene Zertifikate

Für die Zugriff per HTTPS (OWA, EWS, ECP, ActiveSync), SMTPS, IMAP4S und POP3S verwendet der Exchange Server erst einmal das selbst ausgestellt Zertifikat. Kein Client vertraut natürlich dem Exchange Server und wenn Sie sich als Client mit dem Server per TLS verbinden, dann müssen Sie in der Regel eine Zertifikatswarnung bestätigen. Zwar passt meist der Name und das Gültigkeitsdatum aber der Aussteller ist natürlich nicht vertrauenswürdig.

Hinweis: Wenn Outlook bei Autodiscover per "Service Connection Point" auf einem Exchange Server mit so einem "Self Signed Cert" landet, dann kommt keine Zertifikatswarnung. Daher fällt viele Administrator die Nutzung des selbstsignierten Zertifikats erst auf, wenn Zugriffe von Extern oder nicht Domain-joined-WindowsCients kommen.

Für einen Zugriff aus dem Internet müssen Sie sich nicht nur um einen öffentlichen DNS-Namen, Schutzvorkehrungen (Firewall/Proxy etc.) kümmern, sondern auch mindestens ein Zertifikat kaufen und einrichten. Wer nur kein einen kleinen Exchange Server noch selbst betreibt, könnte einfach ein Single-Name-Zertifikat für z.B. "mail.<firmendomain>" kaufen und unter dem Namen den Zugriff erlauben.

Das funktioniert aber schon dann nicht mehr, wenn sie zwei oder mehr Exchange Server haben, da auch die Server untereinander kommunizieren. Wenn die Server dann "EX01.msxfaq.local" und "EX02.msxfaq.local" heißt und eine Verbindung starten, dann erwarten sie auch den Namen des anderen Servers im Zertifikat. Für die Domain ".local" bekommen Sie aber keine öffentlichen Zertifikate. Damit brauchen Sie mindestens zwei Zertifikate. Auch bei den Bindungen müssen Sie zwischen den "Frontend" und "Backend"-Services unterscheiden.

Besondere Aufmerksamkeit sollten Sie dem Recycling des gleichen Zertifikats, insbesondere bei Wildcard-Zertifikaten widmen. Zertifikate werden z.B. bei SMTP auch ausgehend als Client-Zertifikat verwendet und Exchange Online muss z.B. schon unterscheiden können, ob nun ein lokaler Exchange Server eine Mail an den eigenen Tenant sendet oder ein Spamfilter eine Mail an einen Kunden zustellt, dessen MX-Record ebenfalls bei Exchange Online verweist.

Sobald Sie einen Exchange Edge Server (Exchange Edge Rolle) installieren, bekommen Zertifikat eine weitere Bedeutung. Auf dem Edge Server muss eine "Edge-Subscription" generiert werden, in der das Zertifikat des Edge mit eingeht. Diese Information wird dann auf den internen Servern installiert und die Kommunikation zwischen internen SMTP-Transportrollen und den Edge-Servern ist immer per MTLS abgesichert, bei der auch nie das gleiche Zertifikat genutzt werden darf.

Zuletzt brauchen Sie auch noch Zertifikate auf ihrem Exchange Server, um eine sichere Verbindung zu Exchange Online (Hybrid Mail Routing) zu erreichen. Nur Exchange Online ihren lokalen Server zuverlässig erkennt, bekommen Mails auch das erforderliche Vertrauen als "intern" zu zählen und auch in der Gegenrichtung sollten Sie Exchange Online ihr lokales Zertifikat prüfen lassen.

Enable-ExchangeCertificate

Ich war aber neugierig, wie Exchange die Bindung der verschiedenen Dienste herstellt. Bei "Get-ExchangeCertificate werden ja die "Dienst" angezeigt, für die ein Zertifikat "freigeschaltet ist.

Über den Befehl "Enable-ExchangeCertificate" können Sie ein Zertifikat unter Angabe des Thumbprint und des Service aktivieren:

Die sieben verschiedenen Dienste sind:

  • I = IMAP4
    Dieses Zertifikat ist für die Nutzung durch den IMAP4-Service freigegeben
  • P = POP3
    Dieses Zertifikat ist für die Nutzung durch den POP3 -Service freigegeben
  • F = Federation
    Dieses Zertifikat wird für Federation mit anderen Exchange Servern genutzt. Diese Aktivierung sollten Sie nicht mit "Enable-ExchangeCertificate" konfigurieren, sondern nur mit "New-FederationTrust" und "Set-FederationTrust".
  • W = WebServices
    Damit wird das Zertifikat für den IIS eingerichtet.

Wichtiger Hinweis
Durch "Enable-ExchangeCertificate" wird das angegebene Zertifikat an die Default Webseite des IIS gebunden und ein vorher gebundenes Zertifikat entbunden. Wenn dies nicht gewünscht ist, müssen Sie den Schalter "DoNotRequireSsl" mit angeben.

  • S = SMTP
    Damit aktivieren Sie das Zertifikat für den SMTP-Service. Exchange kommt automatisch mit einem "SelfSigned" Zertifikat, was sie natürlich ersetzen können. Mehrere gleichzeitig aktive Zertifikate sind möglich, da sie auch mehrere "Receive Connectoren" mit unterschiedlichen "Namen" konfigurieren können. Exchange sucht sich dann das "beste" Zertifikat aus.
  • U = UM
    Bis Exchange 2016 können Sie ein Zertifikat für die UM-Rolle aktivieren. Vorher müssen Sie aber den Startup-Mode der UMRolle über "Set-UMService -UMStartupMode <mode>" auf "TLS" oder "Dual" stellen. Ansonsten können Sie das Zertifikat nicht aktivieren .
  • M = UMCallRouter
    Ähnlich gilt es für den UMCallRouter. Auch hier müssen Sie den Startup-Mode erst mit "Set-UMCallRouterService -UMStartupMode <mode>" auf TLS oder Dual setzen, ehe Sie ein Zertifikat hierfür aktivieren können.

msExchServerInternalTLSCert

Wenn Sie die Zertifikate mit "Get-ExchangeCertificate" anzeigen lassen, dann bleibt das interne Zertifikate außen vor. Sie sehen es aber, wenn Sie ein neues Zertifikat mit "Enable-ExchangeCertificate" aktivieren.

Wenn sie diese Meldung sehen, dann hat Exchange das Zertifikat schon generell für SMTP aktiviert, d.h. sie sollten hier "No" auswählen, denn ansonsten wird das Zertifikat zusätzlich auch zum "Default SMTP Certificate".

Mit der Installation von Exchange wird durch das Setup ein "Self Signed Cert" mit 5 Jahre Gültigkeit und dem FQDN des Servers eingerichtet und für die interne Kommunikation zwischen den Transport-Rollen genutzt. Das Zertifikat wird auch im Active Directory veröffentlicht, damit auch alle anderen Server in der Topologie damit eine eingehende Verbindung des Servers erkennen.

Das bedeutet natürlich, dass Sie zumindest diese Zertifikat alle 5 Jahre erneuern und aktivieren müssen.

Sie müssen aber kein öffentliches Zertifikat nutzen, welches sie noch häufiger erneuern müssten und vor allem den FQDN enthalten muss.

Die Information darüber liegt in der "Configuration"-Partition des Active Directory. Dort wird von Enable-ExchangeCertificate das Zertifikat (ohne privatem Key) hochgeladen.

CN=<servername>,
CN=Servers,
CN=Exchange Administrative Group (FYDIBOHF23SPDLT),
CN=Administrative Groups,
CN=First Organization,
CN=Microsoft Exchange,
CN=Services,
CN=Configuration,
DC=<domain>,DC=<tld>

So sieht es in meinem Labor aus.

Die binäre Information ist so natürlich nicht einfach zu lesen. Über folgende PowerShell-Zeilen können Sie aber den Wert auslesen und konvertieren.

ForEach ($exserver in (Get-ExchangeServer | Where-Object {$_.ServerRole -like "mailbox"} )) {
   $ADObject = (Get-ADObject -Identity $ExServer.DistinguishedName -Properties msExchServerInternalTLSCert)
   $Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
   $Cert.Import($ADObject.msExchServerInternalTLSCert)
   [pscustomobject][ordered]@{
      Subject                    = $Cert.Subject
      FriendlyName               = $Cert.FriendlyName
      Thumbprint                 = $Cert.Thumbprint
      NotAfter                   = $Cert.NotAfter
   }
}

Sie können das Skript z.B. nutzen, um auf Servern das Ablaufdatum zu prüfen. Das macht aber auch das PSS-Tool Exchange HealthChecker.

Verlängern und korrigieren ist einfach möglich:

$newInternalTransportCertificateParams = @{
    Server               = $env:COMPUTERNAME
    KeySize              = 2048
    PrivateKeyExportable = $true
    FriendlyName         = $env:COMPUTERNAME
    DomainName           = $env:COMPUTERNAME
    IncludeServerFQDN    = $true
    Services             = "SMTP"
    Force                = $true
    ErrorAction          = "Stop"
}

New-ExchangeCertificate @newInternalTransportCertificateParams

Der Aufruf generiert ein "Selfsigned"-Zertifikat, welches 5 Jahre gültig ist und dank "Force = $true" auch direkt zum DefaultTransportCertificate gesetzt wird.

Wahl des Zertifikats

Bei "Enable-ExchangeCertificate" haben Sie ja gesehen, dass mehrere Zertifikate für die gleichen Dienste "aktiviert" sein können.

Exchange hat daher eine Logik, welches Zertifikat er für einen Service oder Konfiguration nutzt. Wenn ich mehrere Receive Connectoren habe, dann ist der FQDN der Konfiguration natürlich ein wichtiger Punkte. Aber auch beim Versand per SMTP kann Exchange ein Client-Zertifikate bei MTLS mitsenden, so dass die Gegenseite den Server authentifizieren kann. Auch dies kann abweichend konfiguriert werden. POP und IMAP sind einfacher, da weil es hier nur genau einen Services und daher nur ein Zertifikat genutzt werden kann während HTTP-Dienste primäre im IIS konfiguriert werden.

Das gilt so aber nicht für SMTP, denn hier können Sie ja mehrere "Connectoren" anlegen und jeder Connector kann mit einer eigenen IP-Adresse/Port-Kombination arbeiten. Damit stellt sich natürlich die Frage, wie Exchange das richtige Zertifikat aus einer Gruppe von Zertifikaten in dem Fall heranzieht. Exchange geht dabei nach einer Streichliste vor und bewertet. Damit ein Zertifikat überhaupt berücksichtig wird, müssen die Grundlagen passen:

  • Ablageplatz: Computerstore mit privaten Schlüssen
  • Erweiterte Sicherheit darf nicht aktiviert sein
  • Zertifikat darf nicht abgelaufen sein
  • Zertifikat muss von einer "Trusted RootCA" sein.
  • Zertifikat darf nicht zurückgezogen sein. Exchange überprüft die CRL, wenn diese erreichbar ist
  • Prüfe den Namen/SAN-Namen
    Bei einem SMTP-Connector können Sie einen FQDN hinterlegen, mit dem sich der Server meldet. Exchange sucht dann ein Zertifikat mit diesem Namen
  • Bevorzuge CA-Zertifikate gegenüber SelfSigned
    Wenn Exchange die Wahl hat, dann nutzt er lieber die von einer PKI ausgestellten Zertifikate
  • Länger gültig
    Wenn dann noch mehrere Zertifikat übrig sind, dann nutzt er anscheinend das länger gültige Zertifikat

Anders als beim IIS, wo auf einer Webseite genau ein Zertifikat gebunden wird, ist dies bei den anderen Diensten nicht statisch, z.B.: über einen Thumbprint möglich. Die Konfiguration über den FQDN beim Receive Connector vereinfacht natürlich den Tausch des Zertifikats, solange der Name enthalten ist und es für SMTP aktiviert wurde. Beim Send-Connector steht im Feld "TlsCertificateName" der Name und Aussteller.

Kein Disable-ExchangeCertificate?

Vielleicht haben Sie aber schon gemerkt, dass es kein Gegenstück zu "Enable-ExchangeCertificate" gibt. Sie können einem Zertifikat also nicht eine Funktion gezielt wieder wegnehmen sondern nur einem anderen Zertifikat diese Funktion zuweisen. Bei den eindeutigen Diensten wie IIS (Webserver), UMRolle oder UMCallRouter kann nur ein Zertifikat aktiviert sein. Wird ein anderes Zertifikat aktiviert, wird das vorherige entbunden aber bleibt natürlich auf dem Server vorhanden.

Wenn Sie ein Zertifikat für einen bestimmten Dienst nicht mehr verwenden möchten, müssen Sie dem Dienst ein anderes Zertifikat zuweisen, und dann das Zertifikat entfernen, das Sie nicht verwenden möchten.
Quelle: https://docs.microsoft.com/de-de/exchange/architecture/client-access/assign-certificates-to-services?view=exchserver-2019

Das kann natürlich nervig sein. Stellen Sie sich vor, sie haben ein neues Zertifikat auf dem Server eingespielt, welches für irgendeinen anderen Zweck benötigen, z.B. Backup, Remotesteuerung, Monitoring o.ä., und nicht in Exchange verwendet werden soll. Am Anfang ist es ja nicht "aktiviert" und alles funktioniert wie erwartet. Sollte nun aber ein Admin quasi aus versehen ein Enable-ExchangeCertifikate mit dem falschen Thumbprint machen, dann ist das Zertifikat doch für Exchange aktiviert. Ich habe daher etwas experimentiert:

Schritt Aktion Ergebnis

Neues Zertifikat

Zuerst habe ich einfach ein neues SelfSigned Zertifikat angefordert.

New-ExchangeCertificate `
   -SubjectName "CN=EX01C" `
   -PrivateKeyExportable:$true

Exchange hat es ausgestellt und automatisch für SMTP aktiviret.

Wenn ich das ohne Verbindung zum Domain Controller mache, dann funktioniert es nicht.

Allerdings vermute ich, dass Exchange nur das "msExchServerInternalTLSCert" liest um mich dann zu fragen, ob das neue Zertifikat das alte ersetzen soll. Da habe ich natürlich NEIN gesagt.

Zertifikat per MMC exportiert und entfernt

Im nächsten Schritt habe ich das Zertifikat in eine PFX-Datei exportiert und im Zertifikatsspeicher gelöscht. Da das an Exchange vorbei erfolgte, konnte Exchange auch nichts irgendwo aktualisieren.

Auch bei Get-ExchangeCertificate ist es verschwunden.

Zertifikat wieder addiert

Danach habe ich die PFX-Datei direkt wieder importiert. Sie sehen auch beim Get-ExchangeCertificate, dass das Zertifikat mit dem gleichen Thumbprint wieder vorhanden ist. Allerdings ist es diesmal nicht für SMTP aktiviert.

Anscheinend speichert Exchange nicht irgendwo in seinen Daten intern den Thumbprint als Bindung, sondern die Information geht mit dem Löschen des Zertifikats direkt verloren.

Über diesen Weg können Sie also ein irrtümlich für Exchange Dienste aktiviertes Zertifikat mit einem Umweg wieder "deaktivieren". Das funktioniert aber nicht für POP, IMAP und HTTP. Wenn ich ein Zertifikat hier nach der Aktivierung lösche und wieder einbinde, dann wird die Bindung wieder erneuert.

Wo steht die Bindung?

Damit ist die Frage aber noch nicht beantwortet, wo Exchange diese Einstellungen sich letztlich merkt. Auf der einen Seite schreibt Microsoft selbst:

Specifically, Get-ExchangeServer retrieves all Active Directory objects from the follow location:
CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Exchange Organization Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=tld
Quelle: https://dirteam.com/bas/2020/06/24/field-notes-what-is-the-current-default-smtp-certificate-for-your-exchange-server-environment/

Das stimmt aber so meines Wissens nicht, denn wenn ich im lokalen Zertifikatsspeicher ein neues Zertifikat per MMC vorbei an allen Exchange Tools addiere, dann wird es mit "Get-ExchangeCertificate" angezeigt, obwohl es nicht in das AD geschrieben werden konnte. Zumindest erwarte ich nicht, dass es auf jedem Exchange Server einen Hintergrundprozess gibt, der Änderungen an den lokalen Zertifikaten ins AD überträgt.

Ich habe daher die vorherige Testserie so wieder hergestellt, dass ich ein Zertifikate im Zertifikatsspeicher hatte, welches aber nicht für Exchange aktiviert ist und dann wieder aktiviert habe. Dabei habe ich auf dem Server alle Änderungen mit Sysinternals:ProcMon mitgeschnitten und die ca. 151.000 Events gefiltert. bis mir folgendes aufgefallen ist:

Der Prozess "Microsoft.Exchange.ServiceHost.exe" schreibt einen Registrierungsschlüssel in den Bereich der Computerzertifikate.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\MY\Certificates\B0AD1D45A3D6BDD9A53F2017F501149F744F5732

Also habe ich mir die Daten vor und nach dem "Enable-ExchangeCertificate" mit Regedit exportiert und dann mit WinMerge verglichen:

Auch ohne die Zahlen im Details zu lesen erkennen Sie einige Änderungen in der vorderen Hälfte des BLOB, die ich hier nicht erwartet hätte. Wobei das nur die Zertifikate ohne privaten Schlüssen sind.

For the computer account, certificates are indeed stored in the registry, in the keys detailed above. The corresponding private keys are stored encrypted in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys and similarly for the others.
Quelle: https://www.michev.info/blog/post/1435/windows-certificate-stores

Leider konnte ich bislang nicht weiter decodiere, ob hier wirklich die Bindungen enthalten sind. Zuerst erscheint es stimmig aber wenn ich die vorherigen Werte wieder per REGEDIT importiere, dann findet dennoch kein Rollback statt. Auch mit den vorherigen Werten bleiben die Zertifikate für Exchange "enabled". Zudem finde ich es schon etwas seltsam, dass ein Prozess wie "Microsoft.Exchange.ServiceHost.exe" direkt in die Registrierung schreibt.

POP3/IMAP4: msexchpopimapx509certificatename

Zur Analyse habe ich während der ganzen Änderungen das AD mit GET-ADChanges überwacht und auch hier gab es ein paar Änderungen bei IMAP4 und POP3.

Anhand der Textdatei konnte ich auch die LDAP-Pfade und das geänderte Feld erkennen:

datetime,Action,Identity,Field,Value
01/13/2024 22:17:42,Modify,CN=1,CN=POP3,CN=Protocols,CN=EX01,CN=Servers,CN=Exchang.....,msexchpopimapx509certificatename,EX01C
01/13/2024 22:17:42,Modify,CN=1,CN=IMAP4,CN=Protocols,CN=EX01,CN=Servers,CN=Exchan.....,msexchpopimapx509certificatename,EX01C

In dem Feld steht einfach nur der Zertifikatname.

Dabei handelt es sich um den "Subject" des Zertifikats ohne das "CN". Interessant ist auch das Verhalten von Exchange, wenn es mehrere Zertifikate mit dem gleichen Subject gibt. Die PowerShell zeigt dann alle passenden Zertifikate als "enabled" an.

Wenn ich dann ein anderes Zertifikat mit einem anderen Namen aktiviere, dann werden die anderen quasi "deaktiviert".

Damit wissen wir nun auch, dass Exchange die Zuordnung von "Enable-ExchangeCertificate" für POP3 und IMAP4 im Active Directory hinterlegt. Wenn ich das Feld "msexchpopimapx509certificatename" beim entsprechenden LDAP-Objekt leere, dann verschwindet auch der "I" bzw. "P" Eintrag beim Zertifikat. Sinnvoll ist dies aber nicht.

Sie können aber eine LDAP-Auswertung über mehrere Server hinsichtlich des Zertifikatsnamens machen um so zu sehen, ob z.B. wirklich alle Server eines Exchange Server Pools den gleichen oder zumindest passenden Subject verwenden.

Weitere AD-Stellen

Der Thumbprint eines Zertifikats ist ja ziemlich eindeutig. Also habe ich die Domain- und die Konfigurations-Partition mit LDIFDE schnell Textdateien exportiert.

ldifde -f config.txt -d "CN=Configuration,DC=UCLABOR,DC=DE"
ldifde -f domain.txt -d "DC=UCLABOR,DC=DE"

In Textdateien lässt es sich schon einfacher nach "Thumb" "Cert", einem Thumbnail u.a. Begriffe suchen oder auch schnell ein Überblick über ein Computerobjekt o.ä. erhalten. Ich habe drei weitere Stellen gefunden, an denen Exchange Zertifikate hinterlegt

msExchUMCertificateThumbprint

Auf dem Serverobjekt speichert Exchange hier den Thumbprint des UM Server Zertifikats ab

dn: CN=EX01,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,
 CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=UCLABOR,DC=DE
msExchUMCertificateThumbprint: DEA2524BB9F986B77B8DDEB8A40A633D2ECE4EE6

msExchAuthCertificateThumbprint

Das Authentication Zertifikat findet sich ebenfalls in der Active Directory Konfigurationspartition

dn: CN=Auth Configuration,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=UCLABOR,DC=DE
msExchAuthCertificateThumbprint: 0:0C4187214F3141E4FD9A72791B33329B23C045BD

msExchCoexistenceSecureMailCertificateThumbprint

Auch der HCW - Hybrid Configuration Wizard speichert das für die Hybridbereitstellung genutzte Zertifikat in der Konfigurationspartition ab

dn: CN=Hybrid Configuration,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=UCLABOR,DC=DE
msExchCoexistenceSecureMailCertificateThumbprint:: 
 PEk+Q049RVgwMTxTPkNOPUVYMDE=

Weitere direkt und einfach auffindbare Treffer gab es aber nicht.

Exchange Server Objekt

Allerdings ist mir beim Feld "lastModified" noch aufgefallen, dass sich beim Exchange Server Objekt in der Konfiguration-Partition Felder geändert haben:

dn: CN=EX01,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,
 CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=UCLABOR,DC=DE
msExchConfigurationXML:: 
 PFRyYW5zcG9ydFNlcnZlckNvbmZpZ1htbD48UXVldWVMb2cgTUE9IjYwNDgwMDAwMDAwMDAiIE1EUz
 0iMjA5NzE1MjAwIiBNRlM9IjEwNDg1NzYwIiBQQVRIPSJDOlxQcm9ncmFtIEZpbGVzXE1pY3Jvc29m
 dFxFeGNoYW5nZSBTZXJ2ZXJcVjE1XFRyYW5zcG9ydFJvbGVzXExvZ3NcSHViXFF1ZXVlVmlld2VyIi
 BFTkE9InRydWUiIC8+PExhdGVuY3lMb2cgTUE9IjYwNDgwMDAwMDAwMDAiIE1EUz0iMjA5NzE1MjAw
 .....
 xlZD50cnVlPC9EYXRhQ29sbGVjdGlvbkVuYWJsZWQ+PE1pdGlnYXRpb25zQXBwbGllZD48TWl0aWdh
 dGlvbj5QSU5HMTwvTWl0aWdhdGlvbj48L01pdGlnYXRpb25zQXBwbGllZD48TWl0aWdhdGlvbnNBcH
 BsaWVkVGltZT4yMDI0LTAxLTEyVDE4OjExOjI0Ljg5MzU3MzlaPC9NaXRpZ2F0aW9uc0FwcGxpZWRU
 aW1lPjwvVHJhbnNwb3J0U2VydmVyQ29uZmlnWG1sPg==
msExchServerInternalTLSCert:: 
 CwAAAAEAAAAmAAAATQBpAGMAcgBvAHMAbwBmAHQAIABFAHgAYwBoAGEAbgBnAGUAAABcAAAAAQAAAA
 QAAAAACAAADwAAAAEAAAAgAAAAAHTDwB7FHXZmal7eow2F03dLztTfdAM69yuE1WkxuesDAAAAAQAA
 ABQAAADeolJLufmGt3uN3rikCmM9Ls5O5gIAAAABAAAAbAAAABwAAAAAAAAADAAAACAAAAAAAAAAAA
.......
 WPSOSTVepcPMevBZ7Le6uZrq6DyZPzxai+oGCZ5jqHRb/RJJYcZwTVfY9OpQKYVq3/23gmLFgKFRcP
 laO2C1zcVWRsSVBbwaJMcQl0L1Z0eJDwdzNnR8QVB73RWdzDXEQWwNb+dbVGtasMq2oNFHMyMplugf
 Q24Iko5MoiHaXI1ugPagpLeOtPCcROTUz3URb1wesa2Apgu2ADzWzLgPAUQTjGLn2ZL0sCWpLt

Die beiden Felder habe ich mir genauer angeschaut. Beide Felder sind offensichtlich BASE64 codierte Strings, die man einfach zurückverwandeln kann.

msExchConfigurationXML

Das ist eine XML-Struktur, in der Exchange sich überwiegend die organisationsweit gültige Transportkonfiguration speichert. Hier ein Auszug mit zur Lesbarkeit gekürzten Pfaden:

<TransportServerConfigXml>
  <QueueLog MA="6048000000000" MDS="209715200" MFS="10485760" PATH="C:\Pr..." ENA="true"/>
  <LatencyLog MA="6048000000000" MDS="209715200" MFS="10485760" PATH="C:\Pr..." ENA="true"/>
  <GeneralLog MA="6048000000000" MDS="209715200" MFS="10485760" PATH="C:\Pr..." ENA="true"/>
  <WlmLog MA="6048000000000" MDS="262144000" MFS="10485760" PATH="C:\Pro..." ENA="true"/>
  <AgentLog MA="6048000000000" MDS="262144000" MFS="10485760" PATH="C:\Pro..." ENA="true"/>
  <FlowControlLog MA="6048000000000" MDS="209715200" MFS="10485760" ENA="true"/>
  <ResourceLog MA="6048000000000" MDS="209715200" MFS="10485760" ENA="true"/>
  <ProcessingSchedulerLog MA="6048000000000" MDS="209715200" MFS="10485760" ENA="true"/>
  <DnsLog MA="6048000000000" MDS="104857600" MFS="10485760" ENA="false"/>
  <JournalLog MA="6048000000000" MDS="209715200" MFS="10485760" PATH="C:\Pro..." ENA="false"/>
  <MaintenanceLog MA="6048000000000" MDS="209715200" MFS="10485760" ENA="true"/>
  <TransportHttpLog MA="6048000000000" MDS="262144000" MFS="10485760" PATH="C:\Pr..." ENA="true"/>
  <RequestBrokerLog MA="6048000000000" MDS="209715200" MFS="10485760" ENA="true"/>
  <StorageRESTLog MA="6048000000000" MDS="209715200" MFS="10485760" ENA="true"/>
  <MaxPrefActives p2:nil="true" xmlns:p2="http://www.w3.org/2001/XMLSchema-instance"/>
  <MitigationsEnabled p2:nil="true" xmlns:p2="http://www.w3.org/2001/XMLSchema-instance"/>
  <ddBypassFiltering>false</ddBypassFiltering>
  <ddForceRescan>false</ddForceRescan>
  <ddDeferWaitTime>1</ddDeferWaitTime>
  <ddDeferAttempts>0</ddDeferAttempts>
  <ddScanTimeout>1</ddScanTimeout>
  <ddScanErrorAction>Block</ddScanErrorAction>
  <ddMinimumSuccessfulEngineScans>1</ddMinimumSuccessfulEngineScans>
  <MailboxDeliveryConnectorMaxInboundConnection>
    <Value>5000</Value>
  </MailboxDeliveryConnectorMaxInboundConnection>
  <AgentGrayExceptionLog MA="6048000000000" MDS="209715200" MFS="10485760" ENA="true"/>
  <DataCollectionEnabled>true</DataCollectionEnabled>
  <MitigationsApplied>
    <Mitigation>PING1</Mitigation>
  </MitigationsApplied>
  <MitigationsAppliedTime>2024-01-12T18:11:24.8935739Z</MitigationsAppliedTime>
</TransportServerConfigXml>

Hier ist aber kein Hinweis auf Zertifikate zu finden. Später habe ich dann gesehen, dass Exchange dieses Feld immer mal wieder ändert, d.h. auch wenn ich keine Änderungen an den Zertifikaten vorgenommen habe. Es dürfte daher nicht für Zertifikate relevant sein.

msExchServerInternalTLSCert

Diese Feld enthält das "Internal Default Certificate", welches jeder Server bekommt und so allen anderen Server zur Verfügung stellt. Der Text enthält aber nicht das typische "-----BEGIN CERTIFICATE-----" und "-----END CERTIFICATE-----".  Ich habe es dann mittels https://www.base64decode.org/ konvertieren lassen.

Aus der Binärdatei lässt auf ein Zertifikat für meinen Testserver E01.UCLABOR.DE schließen.

Weitere Links