Exchange 2016/2019: SMTP Connector und Wildcard- / SAN-Zertifikate
Wer Exchange 2016 / 2019 in Verbindung mit einem Wildcard Zertifikat benutzt, sollte auch die Empfangs- und Sendeconnectoren entsprechend konfigurieren. Auch bei SAN-Zertifikaten kann dies nötig sein.
Enthält das SAN-Zertifikat als “Common Name (Ausgestellt für)” den Domain Namen und nicht den entsprechenden Servernamen des Exchange Servers, kommt es zum Beispiel bei der Verschlüsslung der SMTP-Verbindung mittels STARTTLS zu Problemen.
Hier einmal ein Beispiel des Mailclients Thunderbird der eine SMTP-Verbindung via STARTTLS zu einem Exchange Server aufbauen möchte:
In diesem Fall wurde ein SAN-Zertifikat genutzt, welches als Common Name den Domain Namen (Bspw. ihredomain.de) eingetragen hat und nicht den Hostnamen (Bspw. mail.ihredomain.de). Die zusätzlichen Hostnamen wurden wie üblich als SAN-Attribute angegeben.
Bei Wildcard Zertifikaten stellt es sich ähnlich dar, hier ist normalerweise als Common Name und SAN-Attribut der entsprechende Wildcard Eintrag gesetzt (Bspw. *.ihredomain.de)
Um das Problem zu beheben, muss aber nicht das Zertifikat ausgetauscht werden, es genügt Sende- und Empfangsconnectoren entsprechend zu konfigurieren.
Empfangs- und Sendeconnector konfigurieren
Zunächst muss der Thumbprint des Zertifikats ermittelt werden, dazu kann der folgende Befehl verwendet werden:
Get-ExchangeCertificate | where {$_.services -match "IIS"}
In diesem Fall wird das Zertifikat mit dem Thumbprint “Ihr Thumbprint” verwendet.
$Cert = Get-ExchangeCertificate -Thumbprint 2B7B52B5BB8A3F53E048F4D875A41DCDC71C3910
$TLSCertificateName = "<\i>$($Cert.Issuer)<\s>$($Cert.Subject)"
$TLSCertificateName
der \ ist im Befehl zu löschen
Der Thumbprint wird verwendet um den TLS Zertifikatsnamen zu bilden. Dies geschieht über die folgenden Befehle:
Get-ReceiveConnector
Zeigt Ihnen die Namen der Default Frontend und Client Frontend Connectoren an. Der Begriff EXCHANGE ist in den folgenden Befehlen durch Ihren Servernamen zu ersetzen
Set-ReceiveConnector "EXCHANGE\Default Frontend EXCHANGE" -TlsCertificateName $TLSCertificateName
Set-ReceiveConnector "EXCHANGE\Client Frontend EXCHANGE" -TlsCertificateName $TLSCertificateName
Für gewöhnlich sieht das Zuweisen eines Zertifikates in der Exchange Management Shell wie folgt aus:
Get-ExchangeCertificate -Thumbprint IhrThumpPrint000023432 | Enable-ExchangeCertificate -Services SMTP, IMAP, POP, IIS
Falls es sich um eine Wildcard Zertifikat handelt, und man dieses CMDLET ausführt, würde man davon ausgehen, dass in diesem Zuge auch gleich das Zertifikat für die Dienste IMAP und POP getauscht wird. Das ist allerdings nicht der Fall. Man bekommt eine Warnung zurück.
Das liegt daran, dass man ein Wildcard Zertifikat nicht dem IMAP/POP Dienst zuweisen kann. Das Zertifikathandling passiert an dieser Stelle über den Parameter „X509CertificateName„. Damit das korrekte Zertifikat ausgeliefert werden kann, müssen folgende zwei Befehle auf allen Exchange Nodes ausgeführt werden:
Set-POPSettings -X509CertificateName exchange.ihredomain.de
Set-IMAPSettings -X509CertificateName exchange.ihredomain.de
Anschließend müssen die Microsoft Exchange POP und IMAP Dienste neugestartet werden:
Restart-service MSExchangeIMAP4
Restart-service MSExchangePOP3
