none
Exchange 2016 Zertifikat lässt sich nicht an korrekt an SMTP binden RRS feed

  • 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 Certificate

    Wenn 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

    Mittwoch, 16. Mai 2018 16:31

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
    Donnerstag, 17. Mai 2018 08:18

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)

    Donnerstag, 17. Mai 2018 06:41
  • Hi,

    das Zertifikat ist wie folgt aufgebaut:

    CN=internal-mail.DOMAIN.NET
    DNS-Name=internal-mail

    DNS-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.de

    Ich 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


    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)

    Donnerstag, 17. Mai 2018 07:30
  • 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

    Donnerstag, 17. Mai 2018 08:05
  • 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
    Donnerstag, 17. Mai 2018 08:18
  • Hab diesen Beitrag mal als Antwort markiert.

    Das Zertifikat wird angezogen und das ist das wichtigste.

    Donnerstag, 17. Mai 2018 13:18