Benutzer mit den meisten Antworten
Exc 2010: Das STARTTLS-Zertifikat läuft in Kürze ab

Frage
-
Hi Community,
ich bekomme seit einiger Zeit die Fehlermeldung 12018 in unserem Exchange 2010 angezeigt:
Protokollname: Application Quelle: MSExchangeTransport Datum: 10.03.2014 13:23:38 Ereignis-ID: 12018 Aufgabenkategorie: TransportService Ebene: Fehler Schlüsselwörter: Klassisch Benutzer: Nicht zutreffend Computer: EXC.DOMAIN.local Beschreibung: Das STARTTLS-Zertifikat läuft in Kürze ab. Betreff: mail.domain.de, Fingerabdruck: 3AA13AE50E62EF9B345F60FF06D7D31235872853, verbleibende Stunden: 239. Führen Sie das Cmdlet 'New-ExchangeCertificate' aus, um ein neues Zertifikat zu erstellen.
Die einschlägigen HowTos zu diesem Fehler sagen aus, dass man einfach in der Powershell ein neues erstellt (New-ExchangeCertificate) und dieses dann den Services zuweist (Enable-ExchangeCertificate -Thumbprint $THUMBPRINT -Service IIS SMTP)
Jetzt hat mich aber schon das New-ExchangeCertificate Kommando darauf hingewiesen dass dieses Zertifikat am Ende gar nicht verwendet wird, weil das Zertifikat welches da ausläuft von einer Root CA ausgestellt wurde:
[PS] C:\Windows\system32>New-ExchangeCertificate WARNUNG: Dieses Zertifikat wird nicht für externe TLS-Verbindungen mit einem FQDN von 'SERVERNAME.DOMAIN.local' verwendet, weil das von einer CA signierte Zertifikat mit dem Fingerabdruck '3AA13AE50E62EF9BA73F60F111D7D33485872853' den Vorrang übernimmt. Die folgenden Connectors stimmen mit dem betreffenden FQDN überein: Client SERVERNAME.
So jetzt sind mir hier zwei Dinge aufgefallen. Zum einen habe ich zwei Zertifikate, welche beide auf den selben FQDN ausgestellt sind, nämlich die ersten beiden:
Thumbprint : 7588292EB5EFA3A5595384CB58B4C6EFB8B6610E Services : None Status : Valid NotAfter : 19.03.2023 15:39:41 NotBefore : 21.03.2013 15:39:41 Thumbprint : 3AA13AE50E62EF9B345F60FF06D7D31235872853 Services : IIS, SMTP Status : Valid NotAfter : 20.03.2014 11:24:57 NotBefore : 20.03.2013 11:14:57 Thumbprint : 68A72AB383573117589036CBCA606DD2ABE973A9 Services : None Status : Valid NotAfter : 20.03.2018 00:59:59 NotBefore : 20.03.2013 01:00:00 Thumbprint : E2E4060619F072704AFA4FC7DD145CD6EDEE499CE Services : IMAP, POP, SMTP Status : Valid NotAfter : 19.03.2018 11:37:51 NotBefore : 19.03.2013 11:37:51
Das zweite ist das Zertifikat welches jetzt dann bald abläuft, das erste ist eines von einer öffentlichen CA ausgestellte Zertifikat, beide ausgestellt für den öffentlichen Servernamen. Das erste wäre noch ein paar Jahre gültig, ich denke das ich das Problem lösen könnte, wenn ich das erste Zertifikat den Services IIS und SMTP zuweise. Sehe ich das richtig?
Was mich dann noch aufhorchen lässt war die Warnung dass dieses Zertifikat nicht für den internen FQDN verwendet werden kann (WARNUNG: Dieses Zertifikat wird nicht für externe TLS-Verbindungen mit einem FQDN von 'SERVERNAME.DOMAIN.local' verwendet). DAs sollte er auch gar nicht, keines der beiden Zertifikate wäre für den internen FQDN erstellt.
Wie sollte ich da jetzt am besten vorgehen?
Thx & Bye Tom
Antworten
-
Servus,
> bist Du vielleicht weitergekommen?
Im Prinzip ja. Erwähnenswert wäre noch, dass ich das gekaufte Zertifikat nicht verwenden konnte, weil es am TMG schon benutzt wurde. Da hatten die externen erst mal einen Nachmittag lang keine E-Mails bis wir das Problem lokalisiert hatten.
Eigentlich kannst du den Thread schließen.
Thx & Bye Tom
- Als Antwort markiert Alex Pitulice Mittwoch, 26. März 2014 12:03
Alle Antworten
-
Moin,
mich wundert, dass Deine Webservices gar nicht am gekauften Cert hängen. Das teure Ding ist im Augenblick für die Tonne.
Damit die Meldung verschwindet, brauchst Du ein Zertifikat, dass noch ausreichend Gültigkeit hat, und auf den gleichen Namen wie die Empfangsconnectoren hört.
Entweder änderst Du den FQDN der Empfangsconnectoren oder Du baust ein Self-Signed mit dem/den FQDN der Empfangsconnectoren.
Gruesse aus Berlin schickt Robert - MVP Exchange Server
-
Servus Robert,
> mich wundert, dass Deine Webservices gar nicht am gekauften Cert hängen. Das teure Ding ist im Augenblick für die Tonne.
Wundert mich auch aber das kann man ja jetzt im Zuge dieser Fehlerbeseitigung auch korrigieren.
> Entweder änderst Du den FQDN der Empfangsconnectoren oder Du baust ein Self-Signed mit dem/den FQDN der Empfangsconnectoren.
Ich habe da jetzt zwei Empfangskonnektoren. Einer ist mit dem internen FQDN (hostname.domain.local) konfiguriert, der andere mit dem externen FQDN des MX Records (mail.domain.de). Für keinen von beiden ist explizit ein Zertifikat ausgestellt, es gibt lediglich eines für den Hostnamen des internen FQDN, also ohne dem domain.local. Das ist das Zertifikat, welches der Exchange sich selbst ausgestellt hat. Gebunden sind daran die Services IMAP, POP, SMTP, wobei IMAP und POP nicht verwendet werden (Fingerprint oben E2E406...)
Sowohl das gekaufte, wie auch das jetzt ablaufende Zertifikat wurde ausgestellt auf den FQDN, welcher in der OWA URL verwendet wird (outlook.domain.de). Mal abgesehen vom gekauften Zertifikat, welches ja erst mal keinem Service zugewiesen wurde (None in 7588292...), ist das von unserer RootCA, welches jetzt zur Disposition steht (Fingerprint 3AA13...) den Diensten IIS und ebenfalls SMTP zugewiesen.
Was die zwei Empfangskonnektoren betrifft bin ich jetzt überfragt warum wir die beiden haben, vielleicht ist das noch eine Altlast aus Zeiten der Migration wo hier übergangsweise zwei Exchanger im Netz waren und warum für die kein Zertifikat ausgestellt wurde weiß ich jetzt auch nicht.. Warum ich jetzt das SMTP Protokoll an zwei Zertifikate gebunden habe kann ich auch nicht erklären.
Wie soll ich jetzt weitermachen? Kannst du den Knoten da lösen?
Thx & Bye Tom
-
Hallo Tom,
um TLS wirklich betreiben zu können muß das Zertifikat den Namen haben mit dem sich auch der Konnektor meldet. Wenn es was externes ist also zum Beispiel mail.externedomäne.de, wenn der Server nur intern schickt exchange.addomäne.int .
Ich vermute mal das auf dem Zertifikat der Name des Konnektors nicht mit drauf ist (SAN-Zertifikat notwendig). Bitte beim Neuausstellen darauf achten und mit enable-exchangecertificate neu zuweisen.
hth
Viele Grüße Walter Steinsdorfer MVP Exchange Server http://msmvps.com/blogs/wstein/
-
Servus Walter,
> um TLS wirklich betreiben zu können muß das Zertifikat den Namen haben mit dem sich auch der Konnektor meldet. Wenn es was externes ist also zum Beispiel mail.externedomäne.de, wenn der Server nur intern schickt exchange.addomäne.int .
Okay, wenn ich das Feld wo man das in den Konnektor eingibt richtig interpretiere gehts dabei um das HELO und EHLO und das wäre dann extern mail.domain.de und intern hostname.domain.local. Der Konnektor mit dem internen FQDN wird bestimmt noch aus der Zeit der Koexistenz mit dem alten Exchange 2003 sein und könnte heute noch Verwendung finden bei den ganzen Druckern die den Users E-Mails mit Scans schicken können. Wobei dort afaik die interne IP konfiguriert ist.
Aber jetzt mal was ganz anderes. Mir ist nicht bewusst, dass wir hier SMTP verschlüsseln und das EHLO bzw HELO ist ja ein SMPT Kommando. Verschlüsselt Exchange jetzt schon SMTP default? Das kann ich eigentlich nicht so recht glauben. Kann es nicht sein, dass es nur um die Geschichte mit dem IIS geht? Dann wäre der FQDN im Zertifikat schon richtigerweise outlook.domain.de...
Thx & Bye Tom
-
Moin,
natürlich macht Exchange TLS-Verschlüsselung bei SMTP - wenn das Gegenüber mitspielt. Aber nicht verpflichtend.
Man kann in einem Forum kein Pauschallösung geben, weil man dazu mehr interne Informationen braucht.
Das von Walter angesprochene SAN-Zertifikat ist immer sinnvoll, scheitert aber in diesem Fall meist an den internen Domänennamen, die da nicht mehr erlaubt sind.
Wenn gar keine Verschlüsselung notwendig ist (z.B. weil die Mails intern direkt von einem Spam-Filter kommen), dann kann man den Fehler auch ignorieren, bzw. TLS auf dem Connector abschalten.
Gruesse aus Berlin schickt Robert - MVP Exchange Server
-
Servus,
> natürlich macht Exchange TLS-Verschlüsselung bei SMTP - wenn das Gegenüber mitspielt. Aber nicht verpflichtend.
Hört hört, dass wusste ich nicht. Aber gut wenn es ein 'kann mal' Feature ist ist mir das egal, wenn es mal ein 'muss sein' Feature wird, sollten wir noch mal drüber sprechen.
> Man kann in einem Forum kein Pauschallösung geben, weil man dazu mehr interne Informationen braucht.
Natürlich. Das ist jetzt aber so das Problem, wenn man einen Dienstleister die Migration machen lässt. Man ist initial mal auf der sicheren Seite, später jedoch fehlt dann der Überblick. Unseren ersten Exchange hier haben wir komplett alleine hochgezogen, nur mit Hilfe der User der damals existierenden Newsgroup vor allem dem Daniel Melanchton als er noch nicht bei Microsoft war. Danach kannten wir natürlich jede Checkbox mit Vornamen... ;-)
> Das von Walter angesprochene SAN-Zertifikat ist immer sinnvoll, scheitert aber in diesem Fall meist an den internen Domänennamen, die da nicht mehr erlaubt sind.
Hm, was wird nicht mehr erlaubt? Das DNS Suffix der Domäne, in unserem Fall dann das domain.local? Das würde erklären, warum das Zertifikat welches sich der Exchange selbst ausgestellt hat nur den Hostnamen eingestellt hat, oder?
> Wenn gar keine Verschlüsselung notwendig ist (z.B. weil die Mails intern direkt von einem Spam-Filter kommen), dann kann man den Fehler auch ignorieren, bzw. TLS auf dem Connector abschalten.
Ganz so einfach wirds nicht sein, weil ja auch der IIS das jetzt dann ablaufenden Zertifikat zugewiesen bekommen hat und der funktioniert bei uns ganz sicher mit SSL, ich glaube sogar ab Exchange 2010 ging das gar nicht mehr anders, bei 2003 wars noch ein 'kann, muss aber nicht' Feature. Also um das Erneuern des Zertifikats komme ich nicht rum, denke ich.
Was mir aber so vorschwebt, wäre den IIS einfach an das gekaufte Zertifikat zu binden, denn dieses wird derzeit ja eh nicht verwendet und ist für den gleichen FQDN ausgestellt wie das Zertifikat, welches abläuft. SMTP wird wohl eh nicht funktioniert haben, weil das Zertifikat dafür den falschen FQDN verwendet.
Nur was mich noch stutzig macht, ist warum dann die ganzen OWA und Active Sync User keine Zertifikatswarnung bekommen, kommt das derzeit verwendete Zertifikat doch von unserer eigenen CA und die kennt das draußen im Internet kein Mensch, geschweige denn vertraut dieser.
Thx & Bye Tom
-
> Hört hört, dass wusste ich nicht. Aber gut wenn es ein 'kann mal' Feature ist ist mir das egal, wenn es mal ein 'muss sein' Feature wird, sollten wir noch mal drüber sprechen.
Da ist nicht viel zu sprechen. Bis das im Server-Verkehr Pflicht wird, reden wir nicht mehr über Ex 2010 und dann ist vermutlicha auch IPv6 überholt. Soll heißen: Es gibt eine nicht gerade geringe Anzahl von Servern, die kein TLS können. Die würde man alle aussperren.
> Unseren ersten Exchange hier haben wir komplett alleine hochgezogen, nur mit Hilfe der User der damals existierenden Newsgroup vor allem dem Daniel Melanchton als er noch nicht bei Microsoft war. Danach kannten wir natürlich jede Checkbox mit Vornamen... ;-)
Na das mus ja dann schon ein paar Jahre her sein und die Technik ist nicht unbedingt einfacher geworden.
Falls es Dich beruhig: Was Zertifikate angeht, befindest Du Dich in bester Gesellschaft mit den meisten anderen Exchange Admins. Vor Ex 2007 braucht man das quasi nicht. Und wer sich nie mit etwas beschäftigen musste, weiß natürlich auch nichts darüber.
> Hm, was wird nicht mehr erlaubt? Das DNS Suffix der Domäne, in unserem Fall dann das domain.local? Das würde erklären, warum das Zertifikat welches sich der Exchange selbst ausgestellt hat nur den Hostnamen eingestellt hat, oder?
In intern signierten oder self-signed kannst Du reinschreiben, was Du willst. In externen CA werden interne Domänennamen nicht mehr signiert, weil sie nicht überprüft werden können.
> Ganz so einfach wirds nicht sein, weil ja auch der IIS das jetzt dann ablaufenden Zertifikat zugewiesen bekommen hat und der funktioniert bei uns ganz sicher mit SSL,
Wir reden hier aber über SMTP, das ist ein anderes Protokoll. Für den IIS hast Du ja ein gültiges Zertifikat mit dem richtigen Namen. Das nutzt Du auch für den IIS.
Und wenn das nicht zu SMTP passt, machst Du entweder SMTP passend und verzichtest auf TLS bei SMTP. Das meinte ich.
> ich glaube sogar ab Exchange 2010 ging das gar nicht mehr anders, bei 2003 wars noch ein 'kann, muss aber nicht' Feature. Also um das Erneuern des Zertifikats komme ich nicht rum, denke ich.
Wieso? Du hast doch eines, dass noch fast 10 Jahre gültig ist. Nur kannst Du das ohne Änderung nicht für SMTP nutzen. Musst Du vielleicht aber auch gar nicht, kann ich nur nicht bewerten.
> Was mir aber so vorschwebt, wäre den IIS einfach an das gekaufte Zertifikat zu binden, denn dieses wird derzeit ja eh nicht verwendet und ist für den gleichen FQDN ausgestellt wie das Zertifikat, welches abläuft. SMTP wird wohl eh nicht funktioniert haben, weil das Zertifikat dafür den falschen FQDN verwendet.
Genau so. Nichts anderes war gemeint.
> Nur was mich noch stutzig macht, ist warum dann die ganzen OWA und Active Sync User keine Zertifikatswarnung bekommen, kommt das derzeit verwendete Zertifikat doch von unserer eigenen CA und die kennt das draußen im Internet kein Mensch, geschweige denn vertraut dieser.
Habt ihr eventuell einen Proxy, über den alles läuft und der richtige Zert hat?Gruesse aus Berlin schickt Robert - MVP Exchange Server
-
Hallo Thomas,
bist Du vielleicht weitergekommen?
Gruss,
Alex
Alex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können. -
Servus,
> bist Du vielleicht weitergekommen?
Im Prinzip ja. Erwähnenswert wäre noch, dass ich das gekaufte Zertifikat nicht verwenden konnte, weil es am TMG schon benutzt wurde. Da hatten die externen erst mal einen Nachmittag lang keine E-Mails bis wir das Problem lokalisiert hatten.
Eigentlich kannst du den Thread schließen.
Thx & Bye Tom
- Als Antwort markiert Alex Pitulice Mittwoch, 26. März 2014 12:03
-
Hallo Thomas,
vielen Dank für die Erklärung.Gruss,
Alex
Alex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.