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

5 Replies to “Exchange 2016: SMTP Connector und Wildcard- / SAN-Zertifikate”

  1. Hallo zusammen
    Das funktioniert auch für Exchange 2013 wie beschrieben. Nur EX2010 kennt den Parameter -TlsCertificateName nicht.

  2. 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

  3. 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

  4. 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

  5. Moin,

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

    Besten Gruß
    Gerrit

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.