Exchange 2016: SMTP Connector und Wildcard- / SAN-Zertifikate

Wer Exchange 2016 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-Verbidnung via STARTTLS zu einem Exchange Server aufbauen möchte:

SMTP Connector und Wildcard- / SAN-Zertifikate

In diesem Fall wurde ein SAN-Zertifikat genutzt, welches als Common Name den Domain Namen (Bspw. frankysweb.de) eingetragen hat und nicht den Hostnamen (Bspw. mail.frankysweb.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. *.frankysweb.de)

Um das Problem zu beheben, muss aber nicht das Zertifikat ausgetauscht werden, es genügt Sende- und Empfangsconnectcoren 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"}

SMTP Connector und Wildcard- / SAN-Zertifikate

In diesem Fall wird das Zertifikat mit dem Thumbprint “2B7B52B5BB8A3F53E048F4D875A41DCDC71C3910” verwendet. Der Thumbprint wird verwendet um den TLS Zertifikatsnamen zu bilden. Dies geschieht über die folgenden Befehle:

$Cert = Get-ExchangeCertificate -Thumbprint 2B7B52B5BB8A3F53E048F4D875A41DCDC71C3910
$TLSCertificateName = "<i>$($Cert.Issuer)<s>$($Cert.Subject)"
$TLSCertificateName

SMTP Connector und Wildcard- / SAN-Zertifikate

Jetzt kann das Zertifikat den entsprechenden SMTP Frontend Connectoren zugewiesen werden, dazu müssen zunächst die Namen der Connectoren ermittelt werden:

Get-ReceiveConnector

SMTP Connector und Wildcard- / SAN-Zertifikate

Ausgewählt werden Connectoren, die den Port 25 und 587 enthalten. In diesem Fall also “Exchange\Default Frontend Exchange” und “Exchange\Client Frontend Exchange”. An diese beiden Connectoren kann nun das Zertifikat gebunden werden:

Set-ReceiveConnector "EXCHANGE\Default Frontend EXCHANGE" -TlsCertificateName $TLSCertificateName
set-ReceiveConnector "EXCHANGE\Client Frontend EXCHANGE" -TlsCertificateName $TLSCertificateName

SMTP Connector und Wildcard- / SAN-Zertifikate

Damit auch für ausgehende SMTP Verbindungen das Zertifikat genutzt wird, kann es auf dem gleichen Weg auch an den Sendeconnector gebunden werden:

Get-SendConnector
Get-SendConnector | Set-SendConnector -TlsCertificateName $TLSCertificateName

SMTP Connector und Wildcard- / SAN-Zertifikate

Ob STARTTLS funktioniert, lässt sich mittels der folgenden Webseite testen:

https://www.checktls.com/

Das Ergebnis wird dann entsprechend angezeigt:

SMTP Connector und Wildcard- / SAN-Zertifikate

Auch im E-Mail Header lässt sich prüfen ob TLS genutzt wurde, hier ein Beispiel für einen Received Header (version=TLS1_2)

Received: from EXCHANGE.frankysweb.de () by EXCHANGE.frankysweb.de
() with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1415.2; Sun, 11 Feb
2018 20:49:12 +0100

27 Gedanken zu „Exchange 2016: SMTP Connector und Wildcard- / SAN-Zertifikate“

  1. Hi Frank,

    das hat soweit gut bei uns funktioniert, allerdings haben wir bei CheckTLS hinterher ein „FAIL“ im Bereich Cert.

    Certificate 1 of 1 in chain: Cert VALIDATION ERROR(S): unable to get local issuer certificate; unable to verify the first certificate
    So email is encrypted but the recipient domain is not verified
    So email is encrypted but the host is not verified

    Wir nutzen ein Wilcard Zertifikat. Ist dieses Verhalten dann einfach normal?
    Als Hilfe wird noch erklärt, was ein Intermediate Zertifikat ist. Das ist soweit klar, aber müsste nicht ein entsprechender Client der Intermediate CA vertrauen, damit unser Wildcard Cert akzeptiert wird? Deshalb leuchtet es mir noch nicht ganz ein, warum das auf unserer Sophos nötig wäre. Und wenn doch? Wie trage ich es ein?

    Viele Grüße,
    Christian

    Antworten
    • Hallo Christian,
      der Server sollte in diesem Fall die komplette Chain ausliefern, sprich auf der UTM muss das Root Zertifikat und die Zwischenzertifikate installiert werden, in deinem Fall wird wahrscheinlich nur das Root Zertifikat der CA und das Wildcard Zertifikat liegen. Das Zwischenzertifikat fehlt ujnd wird daher auch nicht von der UTM an den Client ausgeliefert. Das Zwischenzertifikat kannst du ebenfalls in der Zertifikatsverwaltung importieren (alternativ auch Root-Zertifikat + Zwischenzertifikat als p7b in einer Datei hochladen).
      Gruß,
      Frank

      Antworten
  2. Hallo Frank,
    ersteinmal möchte ich mich für Deine Mühen diese diesen Blog zu unterhalten bedanken.
    Ich habe das Problem, dass ich nur ein Wildcard Zertifikat zur Verfügung stehen habe.
    Im Moment stehe ich da aber etwas auf dem Schlauch. Das Zertifikat ist ja schon da. Also kann ich keine neue Anforderung im Exchangeserver generieren. Es muß als anders eingebunden werden. Hast Du dazu mal eine kurze Anleitung bzw. Beschreibung?

    Es wäre schön, wenn Du mir da helfen könntest.

    Gruß Andreas

    Antworten
  3. Moin,

    ist es korrekt, dass nach erfolgreichem Zuweisen nach dieser Anleitung über den Befehl Get-ExchangeCertificate unter Services SMTP nicht auftaucht?

    Besten Gruß
    Gerrit

    Antworten
  4. Hallo,

    Anleitung würde genau unser Problem lösen, doch leider gibt es den Befehl set-SendConnector nicht.

    Ist ein Exchange 2016, neuester Patchstand.

    Hab als Ersatz den enable-ExchangeCertificate gefunden, klappt aber nicht..

    Wer weiß wie das jetzt funktioniert?

    Antworten
  5. Hallo Frank,

    ich möchte einfach mal Danke sagen für die tollen Infos, die du immer so super aufbereitet für uns zur Verfügung stellst.

    Das hat mir schon öfters schlaflose Nächte erspart!

    Beste Grüße und bleib gesund!

    Antworten
  6. Hi,
    Mich irretiert, dass hier in den Screenshots der Dienst „IIS“ verwendet wird? Ich dachte immer, dass Sende,- und Empfangskonnektor SMTP(S) verwenden? Müsste es dann nicht der Thumbprint für den Dienst „SMPT“ sein?

    Danke

    Antworten
  7. Hallo Frank,
    ich habe bei unserem EX2013 ebenfalls das Hostname Missmatch Problem gehabt. Deine Anleitung hat wunderbar geholfen. Das Problem ist behoben und alle sind glücklich. Vielen Dank dafür

    Antworten
  8. Hallo Frank,
    kann man das automatisieren, damit es nach jeder ACME-Zertifikatserneuerung abläuft?

    Besten Dank für die vielen Infos, die ich seit vielen Jahren bei dir gefunden habe.

    Jens

    Antworten
  9. Hallo Frank,

    vielen Dank für deine Anleitung, super beschrieben.

    in unserer DAG kommt es bei mir zu einem Problem, dass der SMTP Dienst nur beim ersten Exchange Server „sichtlich in der GUI und EMS“ gebunden wird, bei den anderen Servern kommt es bei der Bindung zu keinem Fehler, jedoch wird der SMTP Dienst nicht sichtlich in der GUI und EMS gebunden. Sofern ich nun einen SendConnector mit der Option -TLSCertificatename anpassen möchte, kommt die Fehlermeldung, dass dieses Zertifikat keinem SMTP Dienst zugewiesen ist. Ich habe bisher keine Lösung, evtl. jemand auf die selbe Problematik gestoßen? Über Lösungsansätze wäre ich dankbar.

    Gruß Andy

    Antworten
  10. Auch von mir große Anerkennung für die (regelmäßig genutzen) Problemlösungshilfen. Wie immer: die erste Anlaufadresse.
    Und das Problem meiner Vorgänger möchte ich bestätigen. Ich habe einen nagelneuen EX2016, Patchstand 03.2022, als 2. in der Domäne hinzugefügt.
    Einbindung eines Wildcard-Zertifikats, OK. IIS läuft damit. Nach Aussage Powershell ist aber nur der IIS daran gebunden, kein SMTP. Alle dargestellten Tricks probiert, liefen fehlerfrei durch – aber die Anzeige, dass das Zertifikat für SMTP genutzt wird, ist ums Verrecken nicht zu sehen.
    Der Test mit checktls.com zeigte jedoch, das es für die Kommunikation verwendet wird! Ist zwar nicht schön, aber dennoch funktionell erst mal zu gebrauchen. Gerade der Wechsel des Zertifikats nach Ablauf der Gültigkeit ist damit deutlich aufwändiger, bis man weiß, dass es korrekt war.

    Antworten
  11. Ich kann mich Andy und Thomas anschliessen.
    Exchange 2016 CU 22 und SMTP kann ,man dem Zertifikat hinzufügen aber es erscheint nicht im Zertifikat.
    Ich habe auch 2 Exchange (2013 und 2016) , den altem öchte ich ablösen, da erscheint noch der SMTP-Dienst.
    Ich habe es bereits hier berichtet:
    https://www.frankysweb.de/community/exchange2013/beim-upgrade-von-2013-auf-2016-laesst-sich-der-smtp-dienst-nicht-dem-zertifikat-zuweisen/

    aber auch keine Lösung bekommen.
    Laut Get-ReceiveConnector sind TlsCertificateName beim default- und Client Frontend angebunden.

    Antworten
    • wow, ich stehe heute fast bei demselben Problem.
      Ich konnte das Zertifikat auf alle ReceiveConnectoren, aber auf keinen SendeConnector binden.
      Da bekommeich noch die Meldung:
      Das angegebene Zertifikat ist nicht für das SMTP-Protokoll aktiviert. Nur Zertifikate, die für das
      SMTP-Protokoll aktiviert sind, können für Sendeconnectors festgelegt werden. Um ein Zertifikat für SMTP
      zu aktivieren, verwenden Sie das Cmdlet „Enable-ExchangeCertificate“.

      Antworten
  12. Ich habe die Lösung für mein Problem gefunden.
    Man darf das Zertifikat nicht über die certlm mmc importieren, sondern muss dies über die webgui machen. Danach kann man dem Zertifikat auch über die Webgui den SMTP Dienst zuweisen. Im Anschluß konnte ich dann über die Powershell meinem SendeConnector wie oben im Guide beschrieben das Zertifikat zuweisen.
    Auch beim PS Befehl Get-ExchangeCertificate wird nun WS bei meinem Wildcard angezeigt.

    Gruß
    Christian

    Antworten
  13. Es funktioniert bei mir jetzt auch, man war das eine schwere Geburt.

    Ich beschreibe mal wie ich es gemacht habe:

    Da das Zertifikat neu importiert werden muss, muss es vorher gelöscht werden, das geht aber nicht so
    einfach weil es da eine Abhängigkeit vom Transportserver gibt
    Also erstmal in mmc reingehen und das Zertifikat löschen aber vorher einen Export machen mit
    privatem Schlüssel (pfx Datei) da man ohne den das Zertifikat später nicht importieren kann.
    Jetzt das Zertifikat brutal im mmc löschen (Fehlermeldung akzeptieren).
    Jetzt das Zertifikat von der vorher exportierten Datei im EAC importieren (privaten Schlüssel von oben eingeben).
    Jetzt in der Exchange Admin Shell folgendes ausführen:

    Get-ExchangeCertificate (hier den Thumbprint merken)
    $Cert = Get-ExchangeCertificate -Thumbprint (thumbprint)
    $TLSCertificateName = „$($Cert.Issuer)$($Cert.Subject)“
    $TLSCertificateName (hier sieht man den Aussteller vom Zertifikat)
    Get-SendConnector (zum überprüfen des Sendeconnectors, es sollte noch der alte sein)
    Enable-ExchangeCertificate -Thumbprint (thumbprint) -Services POP,IMAP,SMTP,IIS
    get-exchangecertificate -Thumbprint 07FBA23AB9D5EF74F74CC15063EC6632C17935BD | fl (zum Überprüfen)
    Jetzt sollte folgende Dienste zugewiesen sein: IMAP, POP, IIS, SMTP

    Bitte auch noch die receive- und sendekonnectoren überprüfen, bei mir waren noch alle von vorher drin.

    Antworten
  14. Moin,

    anscheinend hat MS was in der Config im Exchange2019 CU12 geändert.
    Das Zertifikat lässt sich nicht mehr über die ECP-Site einbinden sondern nur noch über die Management-Console. Und hier wird schoooon wieder über das Wildcard-Zertifikat gemeckert und es lässt sich nicht an den SMTP-Dienst binden.

    Hat hier schon jemand Erfahrungen sammeln können? Bzw. weiß jemand wie´s richtig geht?
    Über ein Feedback würde ich mich freuen.
    Danke schon einmal im Voraus für euere Mühe.

    MfG
    Michael

    Antworten
    • Hallo Michael,

      vielen Dank für deinen Input, den habe ich gebraucht um die losen Enden zusammen zu führen.

      Wir haben nach der Installation von EX2019 CU12 das Zertifikat des IIS ausgetauscht. Da der Button in der GUI verschwunden ist, ebenfalls über die MMC. Es ließ sich aber anschließend nicht für SMTP aktivieren (ohne Fehlermeldung). Dadurch ließen sich die Connectoren für die Hybridumgebung O365 aber nicht anpassen (Fehlermeldung Zertifikat ist nicht für SMTP aktiviert). Der Mailfluss CloudOnprem stand dadurch still, bzw. die Warteschlage füllte sich.

      Ich habe das Zertifikat wieder gelöscht (über die MMC) und neu über die ExchangeShell importiert. Und siehe da, es ließ sich SMTP und den Connectoren zuweisen.

      Zum Import über die Shell habe ich folgenden Befehl genutzt:

      Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes(‚\\EX01\C$\Zertifikat.pfx‘)) -Password (ConvertTo-SecureString -String ‚Passwort‘ -AsPlainText -Force)

      MfG
      Julian

      Antworten
      • Super. Danke
        Funktioniert auch beim EX2016 CU23.
        Habe das „alte“ Zertifikat über diesen Weg wieder eingespielt (hatte noch 4 Tage) und die Dienste wieder darauf gemappt.
        Das Neue gelöscht (MMC) und erneut über diesen den Powershell Weg eingespielt.
        Die Dienste konnte ich dann per Powershell auf das Zertifikat umstellen. In der MMC habe ich noch den Anzeigenamen angepasst, damit es besser zu unterscheiden ist.

        Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes(‚\\EX01\C$\Zertifikat.pfx‘)) -Password (ConvertTo-SecureString -String ‚Passwort‘ -AsPlainText -Force)

        Thumbprint wird angezeit. Diesen in der nächsten Zeile austauschen

        Enable-ExchangeCertificate -Thumbprint 9373336B6A52ED1B9DA8E5444DA3DD49C0A94888 -Service SMTP,IIS

        Überprüfen ob es geklappt hat

        get-exchangecertificate -Thumbprint 9373336B6A52ED1B9DA8E5444DA3DD49C0A94888

        Bei Service sollte jetzt SMTP und IIS stehen.

        Ich habe das Admin Center auf einen anderen Port gelegt (Anleitung von Fanky), hier nicht vergessen über den Internetinformationsdienste (IIS)-Manger bei Bindungen auch das Zertifikat zu ändern.

        Antworten
  15. Hallo Frank,

    wie man das gewohnt ist, top Anleitung!
    Ist so befolgt worden und hat alles wunderbar funktioniert.

    Danke für deine Mühe!

    Grüße
    Pascal

    Antworten
  16. Hallo Zusammen,
    ich jetzt nach langem hin und her auch endlich mein neues Wildcard Zertifikat auf meinem EX2016 installiert bekommen.
    Dank der Kommentare hier !! Habs dann letztendlich auch über die Powershell hinbekommen.
    Sieht jetzt auch soweit gut aus.

    Hier noch mal zusammengefasst was ich gemacht habe (PS):

    # Import des neues Zertifikates mit Befehl
    # Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes(‚E:\Script\ExChange2022.pfx‘)) -Password (ConvertTo-SecureString -String ******** -AsPlainText -Force)

    Get-ExchangeCertificate

    $NeuesZertifikat = „1809259D7212234095DE61A53F859D62D1D4A6AA“

    $TLSCert = Get-ExchangeCertificate -Thumbprint $NeuesZertifikat
    $TLSCertName = „$($TLSCert.Issuer)$($TLSCert.Subject)“

    Enable-ExchangeCertificate -Thumbprint $NeuesZertifikat -Service SMTP,IIS

    Set-ReceiveConnector „EXCHANGE2016\Default Frontend EXCHANGE2016“ -TlsCertificateName $TLSCertName
    Set-ReceiveConnector „EXCHANGE2016\Client Frontend EXCHANGE2016“ -TlsCertificateName $TLSCertName

    Set-SendConnector „To Internet“ -TlsCertificateName $TLSCertName

    Jetzt wollte ich das alte Zertifikat im EAC löschen, weil ist ja eh abgelaufen.
    Hier meckert er aber, weil das alte Zertifikat angeblich noch an den SendeConnector gebunden wäre.
    Wie kann ich das überprüfen bzw. wie gewöhne ich es dem Connector ab?

    Gruß Sascha

    Antworten

Schreibe einen Kommentar