Anyone using Exchange 2016 in conjunction with a wildcard certificate should also configure the receive and send connectors accordingly. This may also be necessary for SAN certificates.
If the SAN certificate contains the domain name as the "Common Name (issued for)" and not the corresponding server name of the Exchange server, problems occur, for example, when encrypting the SMTP connection using STARTTLS. Here is an example of the Thunderbird mail client that wants to establish an SMTP connection to an Exchange server via STARTTLS:
In this case, a SAN certificate was used which entered the domain name (e.g. frankysweb.de) as the common name and not the host name (e.g. mail.frankysweb.de). The additional host names were specified as SAN attributes as usual.
The situation is similar for wildcard certificates, where the corresponding wildcard entry is normally set as the common name and SAN attribute (e.g. *.frankysweb.de).
To solve the problem, however, it is not necessary to replace the certificate; it is sufficient to configure the send and receive connectors accordingly.
Configuring the receive and send connector
First, the thumbprint of the certificate must be determined using the following command:
Get-ExchangeCertificate | where {$_.services -match "IIS"}
In this case, the certificate with the thumbprint "2B7B52B5BB8A3F53E048F4D875A41DCDC71C3910" is used. The thumbprint is used to form the TLS certificate name. This is done using the following commands:
$Cert = Get-ExchangeCertificate -Thumbprint 2B7B52B5BB8A3F53E048F4D875A41DCDC71C3910 $TLSCertificateName = "$($Cert.Issuer)$($Cert.Subject)" $TLSCertificateName
Now the certificate can be assigned to the corresponding SMTP frontend connectors. To do this, the names of the connectors must first be determined:
Get-ReceiveConnector
Connectors containing port 25 and 587 are selected. In this case, "Exchange\Default Frontend Exchange" and "Exchange\Client Frontend Exchange". The certificate can now be bound to these two connectors:
Set-ReceiveConnector "EXCHANGE\Default Frontend EXCHANGE" -TlsCertificateName $TLSCertificateName set-ReceiveConnector "EXCHANGE\Client Frontend EXCHANGE" -TlsCertificateName $TLSCertificateName
To ensure that the certificate is also used for outgoing SMTP connections, it can also be bound to the send connector in the same way:
Get-SendConnector Get-SendConnector | Set-SendConnector -TlsCertificateName $TLSCertificateName
You can test whether STARTTLS works using the following website:
The result is then displayed accordingly:
You can also check whether TLS was used in the e-mail header, here is an example of a 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
Du hast mich mal wieder gerettet!
Wer kann schon ahnen, dass Exchange für den Receive Connector nicht die komplette Zertifikatskette mitschickt, sondern nur das Zertifikat.
Danke, danke, danke! Kleine Aufmerksamkeit per PayPal ist raus!
Viele Grüße,
Carsten
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
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
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
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
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.
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.
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
Danke, das hat bei mir auch so geklappt.
Hallo Christian,
kannst du das bitte etwas näher erläutern?
Stehe da etwas auf dem Schlauch…*sorry*
Gruß
Oliver
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.
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“.
Ich habe dafür heute mal einen Fall bei MS aufgemacht. gleiches Problem
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.
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
Besten Dank! Hat mir meine Probleme gelöst.
Besten Dank, hat einwandfrei funktioniert. Hoffe der Hybrid-Wizard läuft dann nächstes Mal durch ;-).
cheers!
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
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
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
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!
Hallo Frank,
hat Super funktioniert. Mein Sonntag hat es gerettet!!
Danke Dir
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?
Moin,
ist es korrekt, dass nach erfolgreichem Zuweisen nach dieser Anleitung über den Befehl Get-ExchangeCertificate unter Services SMTP nicht auftaucht?
Besten Gruß
Gerrit
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
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
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
Hallo zusammen
Das funktioniert auch für Exchange 2013 wie beschrieben. Nur EX2010 kennt den Parameter -TlsCertificateName nicht.