5
Exchange 2007 Fehler mit Zertifikat (12014)
Fehler im Anwendungsprotokoll Quelle MSExchange Transport Kategorie: TransportService Ereigniskennung: 12014
Für Outlook WebAccess (OWA) und Outlook Anywhere musste ich ein Zertifikat erzeugen und auf dem Hub Transportserver einbinden. Ich hatte immer einen Fehler im Anwendungsprotokoll:
"Microsoft Exchange konnte ein Zertifikat nicht finden, das den Domänennamen 'briefkasten.unseredomäne.de' im persönlichen Informationsspeicher auf dem lokalen Computer enthält. Daher kann die STARTTLS-SMTP-Aktionsart für keinen Connector mit einem FQDN-Parameter von briefkasten.unseredomäne.de unterstützt werden. Überprüfen Sie die Connectorkonfiguration sowie die installierten Zertifikate, damit sichergestellt wird, dass ein Zertifikat mit einem Domänennamen für jeden Connector-FQDN vorhanden ist."
Aber eigentlich funktionierte trotzdem alles.
Ich habe herausgefunden das Das Zertifikat nicht richtig mit dem SMTP-Service verbunden war.
Das kann man nachsehen indem man in der Verwaltungsshell den Befehl:Get-Exchangecertificate eingibt. Man bekommt dann eine Liste dert installierten Zertifikate und die zugeordneten (bzw. freigegebenen) Services. Ein "S" steht dort für SMTP
genauere infos bekommt man mit dem Befehl:Get-Exchangecertificate | FL *
Um dem Zertifikat den SMTP-Service zuzuordnen muss man sich den Thumbprint des zertifikats notieren (40stellig) und folgenden Befehl in der Verwaltunshell eingeben:
Enable-ExchangeCertificate -Thumbprint [40 stelliger thumbprint ohne die klammern] -Services "SMTP"
Bei mir ist das Anwendungsprotokoll jetzt clean!!
Für Outlook WebAccess (OWA) und Outlook Anywhere musste ich ein Zertifikat erzeugen und auf dem Hub Transportserver einbinden. Ich hatte immer einen Fehler im Anwendungsprotokoll:
"Microsoft Exchange konnte ein Zertifikat nicht finden, das den Domänennamen 'briefkasten.unseredomäne.de' im persönlichen Informationsspeicher auf dem lokalen Computer enthält. Daher kann die STARTTLS-SMTP-Aktionsart für keinen Connector mit einem FQDN-Parameter von briefkasten.unseredomäne.de unterstützt werden. Überprüfen Sie die Connectorkonfiguration sowie die installierten Zertifikate, damit sichergestellt wird, dass ein Zertifikat mit einem Domänennamen für jeden Connector-FQDN vorhanden ist."
Aber eigentlich funktionierte trotzdem alles.
Ich habe herausgefunden das Das Zertifikat nicht richtig mit dem SMTP-Service verbunden war.
Das kann man nachsehen indem man in der Verwaltungsshell den Befehl:Get-Exchangecertificate eingibt. Man bekommt dann eine Liste dert installierten Zertifikate und die zugeordneten (bzw. freigegebenen) Services. Ein "S" steht dort für SMTP
genauere infos bekommt man mit dem Befehl:Get-Exchangecertificate | FL *
Um dem Zertifikat den SMTP-Service zuzuordnen muss man sich den Thumbprint des zertifikats notieren (40stellig) und folgenden Befehl in der Verwaltunshell eingeben:
Enable-ExchangeCertificate -Thumbprint [40 stelliger thumbprint ohne die klammern] -Services "SMTP"
Bei mir ist das Anwendungsprotokoll jetzt clean!!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 69920
Url: https://administrator.de/forum/exchange-2007-fehler-mit-zertifikat-12014-69920.html
Ausgedruckt am: 23.12.2024 um 13:12 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
schon ein weilchen her, dein beitrag, aber ich hab auf unserem Exchange2007 gerade exakt den gleichen Fehler (code 12014) festgestellt, und er läuft seit über einem Monat permanent im Application Log auf !
Die Abhilfe besteht also allein darin, dass man das Zertifikat dem SMTP-service zuordnet ?
Was für eins verwendet ihr denn, ist es ein SAN-/UUC-Cert, also eins von der teureren Sorte, in denen man sich mehrere FQDNs zertifizieren lassen kann ?
Gruß,
== Newton ==
schon ein weilchen her, dein beitrag, aber ich hab auf unserem Exchange2007 gerade exakt den gleichen Fehler (code 12014) festgestellt, und er läuft seit über einem Monat permanent im Application Log auf !
Die Abhilfe besteht also allein darin, dass man das Zertifikat dem SMTP-service zuordnet ?
Was für eins verwendet ihr denn, ist es ein SAN-/UUC-Cert, also eins von der teureren Sorte, in denen man sich mehrere FQDNs zertifizieren lassen kann ?
Gruß,
== Newton ==
Hi Newton,
Ganz genauso war es bei mir. Nachdem ich das richtige!!! Zertifikat dem SMTP-Dienst zugeordnet habe ist die Meldung weg.
Ich verwende momentan ein selbsterstelltes Zertifikat. Ich hab ne "interne" Zertifizierungstelle auf nem 2003er server eingerichtet. Das ist laut Großmeister Thomas Joos ausreichend.
Mit "echten" gekauften zertifikaten habe ich keine Erfahrung. Das ist sicherlich ne Nummer professioneller.
Melde mal ob es bei dir auch klappt.
Ganz genauso war es bei mir. Nachdem ich das richtige!!! Zertifikat dem SMTP-Dienst zugeordnet habe ist die Meldung weg.
Ich verwende momentan ein selbsterstelltes Zertifikat. Ich hab ne "interne" Zertifizierungstelle auf nem 2003er server eingerichtet. Das ist laut Großmeister Thomas Joos ausreichend.
Mit "echten" gekauften zertifikaten habe ich keine Erfahrung. Das ist sicherlich ne Nummer professioneller.
Melde mal ob es bei dir auch klappt.
Wir haben kurz nach der Einrichtung ein kommerzielles Zertifikat gekauft, 200 US$ jährlich.
Vorher waren wir Kunde bei einem Exchange-Hoster, der uns 300 $ monatlich in Rechnung stellte, daher fiel die Entscheidung, selbst einen Exch-Server zu betreiben.
Als wir dann nach schier endloser Installiererei es endlich am Laufen hatten und daran gingen, ActiveSync einrichten zu wollen, scheiterte dies, mit Fehlermeldungen, die sich auf OWA und die Config im IIS bezogen.
Der schließlich eingeschaltete Microsoft-Support brauchte zwei Wochen (telefonisch Einstellungen in IIS durchchecken, Testen in emulierter Umgebung, Logfiles auswerten, Emails hin und her....), um
mit der Erkenntnis aufzuwarten, dass wir ein Mehr-Domänen-Zertifikat bräuchten.
Auch UUC genannt, bzw. eins mit "Server Alternative Names"-Feld, das dann für mehrere FQDNs gilt.
-
Weiß man da näheres drüber, ob das wirklich unabdingbar ist für Exch.07 ?
Wenn ja, welche Domänen / Hostnamen muss ich da mindestens angeben ?
(autodiscover, owa, activesync ?)
-
Vielleicht ist es dann zweckmäßiger, ne eigene CA auf dem Server aufzusetzen. Nur muss man dann das Cert in die Mobiles implementieren, was wohl nicht so leicht sein soll.
Erfahrungswerte damit ?
Schöne Grüße,
== Newton ==
Vorher waren wir Kunde bei einem Exchange-Hoster, der uns 300 $ monatlich in Rechnung stellte, daher fiel die Entscheidung, selbst einen Exch-Server zu betreiben.
Als wir dann nach schier endloser Installiererei es endlich am Laufen hatten und daran gingen, ActiveSync einrichten zu wollen, scheiterte dies, mit Fehlermeldungen, die sich auf OWA und die Config im IIS bezogen.
Der schließlich eingeschaltete Microsoft-Support brauchte zwei Wochen (telefonisch Einstellungen in IIS durchchecken, Testen in emulierter Umgebung, Logfiles auswerten, Emails hin und her....), um
mit der Erkenntnis aufzuwarten, dass wir ein Mehr-Domänen-Zertifikat bräuchten.
Auch UUC genannt, bzw. eins mit "Server Alternative Names"-Feld, das dann für mehrere FQDNs gilt.
-
Weiß man da näheres drüber, ob das wirklich unabdingbar ist für Exch.07 ?
Wenn ja, welche Domänen / Hostnamen muss ich da mindestens angeben ?
(autodiscover, owa, activesync ?)
-
Vielleicht ist es dann zweckmäßiger, ne eigene CA auf dem Server aufzusetzen. Nur muss man dann das Cert in die Mobiles implementieren, was wohl nicht so leicht sein soll.
Erfahrungswerte damit ?
Schöne Grüße,
== Newton ==
Hi Newton!
Also im Prinzip braucht man kein Mehr-Domänenzertifikat.
Außer.....außer wenn euer owa bzw EAS unter verschiedenen Domönennamen erreichbar sein muß. Meistens Reicht einem doch eine oder? Dahinter steckt das in dem Zertifikat eben ein Full qualified name steht der eben dem Pfad entsprechen muss der damit aufgerufen wird. Is also euer owa unter "Exchange.euredomain.de/owa" erreichbar dann muss im Zertifikat eben "Exchange.euredomain.de" hinterlegt sein. Gibt es dort unstimmigkeiten meckert es beim client das das Zertifikat ungültig sei. (Clientabhängig)
Oft hat oder sogar ziemlich sicher hat man das problem wenn man sich aus dem internen LAN per owa auf den Exchangeserver will, denn der interne Domänenname unterscheidet sich ja (hoffentlich) von dem externen.
Glücklicherweise benötigen wir intern kein owa. (ne andere Geschichte ist das Outlook2007 clients ebenfalls rummeckern)
Ich habe auf unserenDNS-Servern die dns anfragen auf die externe domäne umgeleitet so das es möglich ist von intern einfach die externe Domain aufzurufen womit das zertifikat wieder stimmt. Man kann auf dem Exch2007 den internen und externen Pfad getrennt angeben.
Bau dir doch einfach mal ein eigenes Zertifikat und probiere es aus.
Also im Prinzip braucht man kein Mehr-Domänenzertifikat.
Außer.....außer wenn euer owa bzw EAS unter verschiedenen Domönennamen erreichbar sein muß. Meistens Reicht einem doch eine oder? Dahinter steckt das in dem Zertifikat eben ein Full qualified name steht der eben dem Pfad entsprechen muss der damit aufgerufen wird. Is also euer owa unter "Exchange.euredomain.de/owa" erreichbar dann muss im Zertifikat eben "Exchange.euredomain.de" hinterlegt sein. Gibt es dort unstimmigkeiten meckert es beim client das das Zertifikat ungültig sei. (Clientabhängig)
Oft hat oder sogar ziemlich sicher hat man das problem wenn man sich aus dem internen LAN per owa auf den Exchangeserver will, denn der interne Domänenname unterscheidet sich ja (hoffentlich) von dem externen.
Glücklicherweise benötigen wir intern kein owa. (ne andere Geschichte ist das Outlook2007 clients ebenfalls rummeckern)
Ich habe auf unserenDNS-Servern die dns anfragen auf die externe domäne umgeleitet so das es möglich ist von intern einfach die externe Domain aufzurufen womit das zertifikat wieder stimmt. Man kann auf dem Exch2007 den internen und externen Pfad getrennt angeben.
Bau dir doch einfach mal ein eigenes Zertifikat und probiere es aus.
Ich weiss der letzte Beitrag liegt schon lange zurück allerdings wollte ich denoch meine Lösung des Problems anbieten!
Ich hatte ebenfalls die gleich Fehlermeldung
weg bekommen habe ich sie in dem ich mit Get-Exchangecertificate | FL* überprüft habe auf welche FQDN Zertifikate liegen !
Daran habe ich erkannt das bei mir unter dem Sendeconnector / Allgemein -> der falsche FQDN eingetragen war ( HELO/EHLO als ich dann den richtigen FQDN ( Der FQDN des Exchangeservers ) war der Fehler behoben ! Vieleicht konnte ich ja noch jemanden damit Helfen !
Gruß Thomas
Ich hatte ebenfalls die gleich Fehlermeldung
weg bekommen habe ich sie in dem ich mit Get-Exchangecertificate | FL* überprüft habe auf welche FQDN Zertifikate liegen !
Daran habe ich erkannt das bei mir unter dem Sendeconnector / Allgemein -> der falsche FQDN eingetragen war ( HELO/EHLO als ich dann den richtigen FQDN ( Der FQDN des Exchangeservers ) war der Fehler behoben ! Vieleicht konnte ich ja noch jemanden damit Helfen !
Gruß Thomas
