Benutzer mit den meisten Antworten
Exchange 2016 Zertifikat lässt sich nicht an korrekt an SMTP binden

Frage
-
Hi,
wir befinden uns aktuell in der Migration von Exchange 2013 CU20 auf 2016 CU9 und ich habe das Phänomen das sich das Zertifikat des Exchange 2013, nach dem Ex- und Import, nicht "sauber" an den SMTP Dienst des Exchange 2016 binden lässt.
Vorab:
- Server wird mit dem DNS-Alias internal-mail.DOMAIN.NET aufgerufen und heißt intern EXCH2016
- Das Zertifikat enthält sowohl den DNS-Alias als auch die jeweiligen Exchange-Server und auch die restlichen Exchange-Einträge (AutoDiscover.....)
Thumbprint Services Subject
---------- -------- -------
68EB1974549707F46211Bxxxxxxxxxxxxxxxxxxxx ...W... CN=EXCH2016
3C0ABB6217C6060F27601xxxxxxxxxxxxxxxxxxxx IP.W... CN=internal-mail.DOMAIN.NET, OU=IT Services, O=COMPANY
9D21F47116CE84B390940xxxxxxxxxxxxxxxxxxxx ....... CN=WMSvc-SHA2-EXCH2016
68486648CCB1CBF40DE8Bxxxxxxxxxxxxxxxxxxxx ....SF. CN=Federation
67398C33A7F3DC95C4414xxxxxxxxxxxxxxxxxxxx ....S.. CN=Microsoft Exchange Server Auth CertificateWenn ich jedoch am Transport-Service schaue welches Zertifikat hinterlegt ist, wird das Zertifikat 3C0ABB... angezeigt.
InternalTransportCertificateThumbprint : 3C0ABB6217C6060F27601xxxxxxxxxxxxxxxxxxxx
Mein Test mit Telnet auf den Port ergab folgendes:
250-EXCH2016.DOMAIN.NET Hello [10.0.12.238]
250-SIZE 104857600
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 XRDST
Sobald ich ein SELF-Signed Certificate erstelle kann dieses ohne Probleme an SMTP gebunden werden und fragt artig nach ob er das Zertifikat 3C0ABB6217C6060F27601xxxxxxxxxxxxxxxxxxxx ersetzen soll.
Was mache ich falsch?
Warum funktioniert das identische Zertifikat auf dem Exchange 2013 und scheinbar nicht auf dem Exchange 2016?Gruß
Para
Antworten
-
Die Anzeige der Bindungen bei SMTP war schon immer etwas "gewöhnungsbedürftig", weil nur das "Standard-Zertifikat" festgelegt wird und Exchange sowieso immer alle Zertifikate nutzt, die gültig sind und wo der FQDN zum Zertifikat passt.
Der Transportdienst wirft sogar Event-Log Einträge für Zertifikate, die in Exchange gar keine Bindung haben, aber die abgelaufen sind. Sie würden halt trotzdem benutzt werden, wenn es einen Connector mit dem FQDN gibt.
Ob Bug oder gewollt habe ich da nie geklärt, denn normalerweise funktioniert es wie gewünscht.
Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)
- Als Antwort markiert Para el Mundo Donnerstag, 17. Mai 2018 13:17
Alle Antworten
-
Moin,
ist denn der Name "EXCHANGE2016.DOMAIN.NET" im Zertifikat enthalten?
Wenn nein, wird es auch nicht für diese Verbindung verwendet. Exchange sucht automatisch ein zum FQDN des Connectors passendes Zertifikat aus seinem Speicher.
Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)
-
Hi,
das Zertifikat ist wie folgt aufgebaut:
CN=internal-mail.DOMAIN.NET
DNS-Name=internal-mailDNS-Name=EXCHANGE2016
DNS-Name=EXCHANGE2016.DOMAIN.NET
DNS-Name=EXCHANGE2013
DNS-Name=EXCHANGE2013.DOMAIN.NET
DNS-Name=mail.external.de
DNS-Name=eas.external.de
DNS-Name=legacy.external.de
DNS-Name=legacy.DOMAIN.NET
DNS-Name=autodiscover.external.de
DNS-Name=autodiscover.DOMAIN.NET
DNS-Name=outlook.external.de
DNS-Name=outlook.DOMAIN.NET
DNS-Name=external.de
DNS-Name=www.external.deIch habe nochmals auf Typos überprüft und nichts gefunden. Der Private Key ist auch enthalten.
Das Zertifikat wurde ja auch an den Transport Service gebunden, wenn ich dies mit Powershell abfrage.
Gruß
Para
- Bearbeitet Para el Mundo Donnerstag, 17. Mai 2018 07:10
-
Wow, das ist ja viel. Sinnvoll wäre eine andere Aufteilung, für die Funktion spielt es aber keine echte Rolle.
Was bringt Dich denn dazu, dass es nicht funktioniert? Was steht im SMTP-Log, wenn eine komplette Mail inkl. STARTTLS eingeliefert wird. Dort wird normalerweise das Zertifikat auch angegeben.
Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)
-
Hallo Robert,
das Log zeigt die Verwendung des korrekten Zertifikates.
Was mich zu dem Post bewogen hat:
Sowohl Get-ExchangeCertificate als auch die ECP zeigt mir an das das Zertifikat nicht für den Service SMTP verwendet wird.
3C0ABB6217C6060F27601xxxxxxxxxxxxxxxxxxxx IP.W... CN=internal-mail.DOMAIN.NET, OU=IT
Hier fehlt müsste es eigentlich IP.WS.. heißen.
Bevor ich den Server jetzt in entgültig in Betrieb nehme würde ich gerne klären ob dies ein Anzeigefehler ist, oder wo mein Problem liegt
-
Die Anzeige der Bindungen bei SMTP war schon immer etwas "gewöhnungsbedürftig", weil nur das "Standard-Zertifikat" festgelegt wird und Exchange sowieso immer alle Zertifikate nutzt, die gültig sind und wo der FQDN zum Zertifikat passt.
Der Transportdienst wirft sogar Event-Log Einträge für Zertifikate, die in Exchange gar keine Bindung haben, aber die abgelaufen sind. Sie würden halt trotzdem benutzt werden, wenn es einen Connector mit dem FQDN gibt.
Ob Bug oder gewollt habe ich da nie geklärt, denn normalerweise funktioniert es wie gewünscht.
Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)
- Als Antwort markiert Para el Mundo Donnerstag, 17. Mai 2018 13:17