Ich habe nun schon mehrere Mails mit Fragen zum Exchange Backend Zertifikat bekommen,daher gibt es an dieser Stelle mal einen kleinen Beitrag dazu. In den meisten Fällen wurde das Backend Zertifikat beim Aufräumen gelöscht. Der folgende Artikel behandelt die Funktion und Notwendigkeit des Backend Zertifikats und auch die Wiederherstellung falls es versehentlich gelöscht wurde.
Was ist das Backend Zertifikat?
Bei dem Backend Zertifikat handelt es sich um ein selbst signiertes Zertifikat, welches bei der Installation eines Exchange Servers erstellt wird. Das Backend Zertifikat enthält den NetBIOS Namen und den FQDN des Exchange Servers und ist 5 Jahre gültig.
Das Zertifikat wird mit dem Anzeigenamen “Microsoft Exchange” erstellt und an den IIS Dienst gebunden:
Das Zertifikat wird von Exchange allerdings nur für die IIS Website “Exchange Back End” verwendet und ist an den Port 444 gebunden:
In der Zertifikate MMC stellt sich das Backend Zertifikat als selbstsigniertes Zertifikat dar. Hier ist zu erkennen, dass NetBIOS und FQDN als SANs (Subject Alternate Names) enthalten sind:
Wenn dieses Zertifikat gelöscht wird, ist also keine verschlüsselte Verbindung mit der Website “Exchange Back End” mehr möglich, dies wird jedoch von der Website vorausgesetzt:
Wozu dient das Exchange Backend Zertifikat?
Der IIS Server eines Exchange Servers stellt zwei Webseiten für Exchange Server bereit, die “Default Web Site” ist im Prinzip das Frontend, also die Website die auch Benutzer aufrufen, wenn sie beispielweise auf OWA zugreifen. Auch fast alle anderen Dienste werden über das Frontend dem Benutzer zugänglich gemacht (kleine Ausnahme ist Exchange UM). Die “Default Web Site” verfügt daher über das Zertifikat, welches dem Benutzer präsentiert wird.
Bei der zweiten Website handelt es sich um das “Exchange Back End”. Der Benutzer ruft das Backend nicht direkt auf, sondern das Frontend arbeitet vom Prinzip her wie ein Proxy für das Backend. Das Frontend leitet die Verbindungen der Benutzer für die unterschiedlichen Protokolle an das Backend weiter. Das Backend übernimmt die eigentliche Verarbeitung der Verbindung. Der Benutzer ruft das Backend also nicht direkt auf, sondern wird bis auf eine Ausnahme (Exchange UM) über das Frontend an das Backend weitergeleitet.
Zurück zum Backend Zertifikat: Mit dem Backend Zertifikat wird die Verbindung zwischen Frontend und Backend auf Port 444 ver- bzw. entschlüsselt. In einer Umgebung mit nur einem Exchange Server kommuniziert das Frontend des Exchange Servers also verschlüsselt mit dem Backend, hierzu wird das Backend Zertifikat benötigt. In Umgebungen mit mehreren Exchange Servern kommunizieren die Exchange Server untereinander ebenfalls über das Backend miteinander, auch hier wird das Backend Zertifikat benötigt. Ebenfalls können in Umgebungen mit mehreren Exchange Servern die Frontends auf andere Exchange Backends zugreifen.
Die Prüfung des Backend Zertifikats durch die Exchange Server ist dabei nicht so streng, wie die Prüfung von Outlook zum Frontend. Das Backend Zertifikat muss daher nur den Namen des Exchange Servers enthalten und darf auch selbst signiert sein. Der Benutzer bekommt das Backend Zertifikat nicht zu sehen, daher muss das Backend Zertifikat auch nicht durch ein gültiges Zertifikat einer öffentlichen CA ausgetauscht werden.
Beim Austausch des Backend Zertifikats durch ein öffentliches Zertifikat kann es sogar zu Problemen zwischen der Kommunikation mehrere Exchange Server kommen. Ursache ist dann meist der fehlende Exchange Server Name auf dem Backend Zertifikat.
Daher gilt: Backend Zertifikat einfach so lassen wie es ist, nicht löschen, nicht austauschen, nur erneuern wenn es abläuft.
Backend Zertifikat gelöscht, wie wiederherstellen?
Für diesen Beitrag habe ich das Backend Zertifikat des Exchange Servers gelöscht:
Da dass Zertifikat gelöscht wurde steht die “Exchange Back End” Website im IIS nun ohne Zertifikat dar, eine https Verbidnung auf Port 444 von Front End zu Backend ist folglich nicht mehr möglich:
Die Folgen: Die Exchange Management Shell verbindet sich nicht mehr, die Fehlermeldung ist allerdings wenig hilfreich:
New-PSSession : [ex1.cloud.frankysweb.de] Beim Verbinden mit dem Remoteserver „ex1.cloud.frankysweb.de“ ist folgender
Fehler aufgetreten: [ClientAccessServer=EX1,BackEndServer=ex1.cloud.frankysweb.de,RequestId=d6f8b99b-0d90-4ca5-b814-375
235837774,TimeStamp=13.03.2018 21:10:45] [FailureCategory=Cafe-SendFailure] Weitere Informationen finden Sie im
Hilfethema „about_Remote_Troubleshooting“.
Die Login Maske für das EAC wird zwar noch angezeigt, da sie vom Frontend ausgeliefert wird:
Aber nach der Eingabe von Benutzernamen und Passwort wird nur noch eine leere Seite angezeigt:
Auch im Eventlog rufen Exchange Dienste um Hilfe. Hier erhält man eine Fehlermeldung die aussagekräftig ist und in die entsprechende Richtung weißt:
Event ID: 12014
Quelle: MSExchangeFrontEndTransport
Microsoft Exchange could not find a certificate that contains the domain name EX1.cloud.frankysweb.de in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default Frontend EX1 with a FQDN parameter of EX1.cloud.frankysweb.de. If the connector’s FQDN is not specified, the computer’s FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.
Outlook kann in diesem Fall auch keine Verbindung mehr herstellen, also muss ein neues Zertifikat für das Backend her. Ein neues selbstsigniertes Zertifikat kann einfach über den IIS-Manager erzeugt werden.
Um ein neues Zertifikat zu erstellen, wird im IIS Manager der Punkt Serverzertifikate aufgerufen:
Unter “Aktionen” findet sich der Menüpunkt “Selbstsigniertes Zertifikat erstellen”:
Der Anzeigename spielt keine Rolle, der Ordnung halber kann hier wieder “Microsoft Exchange” eingetragen werden:
Das Zertifikat wurde erstellt und wird nun mit dem Namen “Microsoft Exchange” angezeigt:
Nun muss das Zertifikat nur noch an die Backend Website gebunden werden:
Nachdem das neue selbst erstellte Zertifikat zugewiesen wurde, verbindet sich auch die Exchange Shell wieder:
Auch ECA verbindet sich direkt wieder, ein Neustart des Servers ist in der Regel nicht nötig.
Hallo,
nach der Neuerstellung des Zertifikats funktioniert alles, allerdings taucht das Zertifikat nicht in der Exchange Admin Console auf. Server neu gestartet, muss ich noch etwas machen damit es dort wieder auftaucht?
Hallo
MS schreibt da etwas anderes:
https://learn.microsoft.com/de-de/exchange/troubleshoot/client-connectivity/owa-ecp-ems-cannot-connect-after-self-signed-certificate-removed
Starten Sie die Verwaltungsshell auf dem Postfachserver.
Geben Sie „New-ExchangeCertificate“ ein.
Dann wird auch in der ECP das Backend Zerti. angezeigt
Hallo Frank,
ich habe die Anleitung durchgeführt, 1000x danke dafür.
Das neue Zertifikat wird nun auch im certlm.msc angezeigt mit „Exchange Server“ aber im EAC erscheint das Zertifikat nicht… Die Exchange-Management-Shell funktioniert, OWA und ECP auch, aber wenn ich Get-ExchangeCertificate aufrufe bekomme ich es nicht angezeigt, nur das externe UCC, das Microsoft Exchange Server Auth Certificate und das WMSVC tauchen auf.
IISreset habe ich gemacht.
Hast du einen Tip? seltsamer Weise erhalte ich beim Aufruf get-exchangeserver keine Antwort, so kann ich den Healtchecker.ps1 nicht mehr laufen lassen. Bräuchte eure Hilfe
Hallo Detlef hast du hier eine Lösung herausgefunden?
Guten Abend
der Sonntag konnte durch DIESE Hilfegerettet werden.
Bei mir hatte ein MS-Update das Zertifikat einfach rausgenommen aus dem IIS.
In dem Moment, als das Zertifkat erneuert war, kam in Outlook die Meldung, dass dem Zertifikat nicht vertraut wird. Nach dem Erneuern war das für Backend gedachte Zertifikat bei mir auch an der Default Web Site gebunden, dort musste ich wieder zurück auf unser CA-signiertes Zertifikat stellen. Ich habe das Zertifikat im EAC erneuert.
Guten Abend!
Mal wieder tolle Unterstützung gefunden!
Ist mir etwas saublödes passiert, aber vielleicht hilft es ja jemandem: ich habe nach dem Erneuern des Zertifikates über ECP nach einiger Zeit (~1h) gesehen, dass das Zertifikat dort bereits aktiv war und das alte Zertifikat gelöscht. Dummerweise hatte der IIS das noch nicht mitbekommen und stand nun ohne Zertifikat da. Kein ecp, kein owa, kein Outlook.
Lange gesucht und viele Sachen probiert. Nach dem Anhängen des neuen Zertifikates im IIS-Manager wie oben beschrieben ging es dann sofort wieder.
LG
Moin auch!
Jetzt ist das Backend Zertifikat aber auch an den Diensten pop,smtp,iis und imap gebunden. Muss das auch wieder so seien, wenn man ein neues für das Backend erstellt? Meine Frage basiert auf der Tatsache dass das aktuelle noch mit SHA-1 signiert ist, und das muss ich ändern.
Moin!
Danke für die Anleitung!
Leider taucht das „Microsoft Exchange“ im MMC auf, aber nicht im ECP/EAC.
Im ECP/EAC wird es nicht angezeigt, aber wir bekommen eine Meldung, dass es abgelaufen ist!
Wir haben erst den IIS und dann den ganzen Server neu gestartet und es bleibt beim gleichen Verhalten: Beim MMC ist das „Microsoft Exchange“ zu sehen und gültig, im ECP/EAP taucht es nicht auf und wir erhalten die Meldung, das es abgelaufen ist.
Server: 2012R2 Standard, Exchange 2013
Beste Grüße
Auch von mir ein Servus und vielen Dank für die Anleitung.
Bei mir ist es das gleiche wie bei Dirk, unter IIS und MMC ist das Zertifikat vorhanden, im Exchange Admin Center leider nicht.
Server 2012 Standard / Exchange 2016
VG Ralf
Moin Franky, vielen Dank für deine großartige Doku.
Ich habe in den letzten Tagen nach deiner Anleitung einen EX2016 auf einem Server 2016 in Coexistence zu einem EX2010 auf einem Server 2008 Std. in Betrieb genommen.
Aufgrund deiner ausführlichen Anleitung kam es zu keinen Überraschungen/Fehlern.
Nun habe ich zunächst mit deinem Let´s Encrypt Script und nachdem dieses nicht wollte über WinAcme ein Zertifikat erstellt, was im IIS hinterlegt wurde. Das Zertifikat erschien aber auch nach div. Importversuchen nicht in der Exchange Management „Gui“.
Daher wollte ich die Prozedur wiederholen und habe mich folgenschwer dafür entschieden das Let´s Encrypt Zertifikat im IIS und damit auch im Zertifikat Snap-in (Webhosting) zu löschen.
Nun funktioniert weder die Exchange Shell, noch die Webanwendung. Auch mein Testpostfach kann sich nicht mehr mit dem EX2016 verbinden.Das Zertifikat konnte ich bereits wiederherstellen, es liegt wie zuvor im IIS und unter Webhosting im Zertifikats Snap-in.
Kannst Du mir einen Tip geben, wie ich das Ganze am elegantesten wieder zum laufen bekomme und auch für mich vielleicht nicht erkennbaren Fehlfunktionen ausschließen kann?
Vielen Dank
Die Fehlermeldung beim starten der Exchange Shell lautet:
AUSFÜHRLICH: Verbindung mit Server wird hergestellt.
New-PSSession : [Server] Beim Verbinden mit dem Remoteserver „Server“ ist folgender Fehler
aufgetreten: Der WinRM-Client kann die Anforderung nicht verarbeiten. Der Inhaltstyp der HTTP-Antwort vom Zielcomputer
kann nicht ermittelt werden. Der Inhaltstyp fehlt oder ist ungültig. Weitere Informationen finden Sie im Hilfethema
„about_Remote_Troubleshooting“.
In Zeile:1 Zeichen:1
+ New-PSSession -ConnectionURI „$connectionUri“ -ConfigurationName Micr …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : -2144108297,PSSessionOpenFailed
AUSFÜHRLICH: Verbindung mit Server wird hergestellt.
New-PSSession : [Server] Beim Verbinden mit dem Remoteserver „Server“ ist folgender Fehler
aufgetreten: Der WinRM-Client kann die Anforderung nicht verarbeiten. Der Inhaltstyp der HTTP-Antwort vom Zielcomputer
kann nicht ermittelt werden. Der Inhaltstyp fehlt oder ist ungültig. Weitere Informationen finden Sie im Hilfethema
„about_Remote_Troubleshooting“.
In Zeile:1 Zeichen:1
+ New-PSSession -ConnectionURI „$connectionUri“ -ConfigurationName Micr …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : -2144108297,PSSessionOpenFailed
Ich konnte den Fehler selbst beheben, wie es scheint, lag es wohl daran, dass nach einem Neustart nicht alle erforderlichen Dienste gestartet waren.
Ich habe alle erforderlichen Dienste manuell gestartet und nach erfolgreichem Test einen Neustart gemacht um zu Prüfen, dass die Dienste nun selbstständig starten.
Vielleicht ereilt ja jmd. mal das gleich Schicksal.
Danke Franky! Hat mir gerade geholfen. LG
Wieder mal meinen Ar*** gerettet mit dem blöden Backend Zertifikat.
Danke Franky :-)
Ich kriege auch die leere Seite nach dem Login im Admin Center, aber egal, was ich eintrage für das Back-End, die Seite bleibt leer.
Hallo Martin,
bei mir das Gleiche, das Microsoft Exchange Zertifikat ist eingetragen und trotz allem, ohne bewusste Änderung von einen auf den anderen Moment eine weisse Seite, Konntest Du das Problem schon lösen?
Hallo Zusammen,
bei mir besteht eben dieses Problem bei einem (bereits 2x) frisch aufgesetzten EXC-Server 2019. Die Zertifikate sind „jungfräulich“ unangetastet; die Installation verlief ohne jeglichen (erkennbaren) Fehler; parallel läuft noch ein EXC-Server-2013; dieser lässt auch zu, dass per ecp der „Neue“ verwaltet wird. EXC-Management-Shell funktioniert auch.
Nur kann ich weder auf die OWA noch auf die ECP Seite zugreifen (weißer Bidlschirm nach login).
Da der EXC-2013 durch den 2019er ersetzt werden soll, ist der direkte Zugriff auf ECP und OWA leider wichtig …
Gab es also Lösungen zu dem genannten Problem?
Wäre super, wenn mir jemand diese mitteilen könnte.
Vielen Dank vorab,
Oliver
Vielen Dank für den Beitrag! Das hat mir mal eben den Hintern gerettet. Großartig!
Hi Frank,
das heisst also wenn ich im ECP das offiziele Zertifikat dem IIS zuweise bleibt das Zertifikate vom BackEnd unangetastet.. ich hab gerade leider keine Teststellung um das zu testen ;)
Gruß und Danke dir.
Hi Rene,
genau so sieht es aus.
Gruß, Frank
ich meinte natürlich san zertifikat ;)
Hallo Rene,
das Backend Zertifikat ist immer ein selbstsigniertes Zertifikat und wird nur für die Exchange interne Kommunikation verwendet. Das FrontEnd kommuniziert via SSL mit dem BackEnd, daher ist auch für das BackEnd ein Zertifikat erforderlich. Der Client bekommt immer nur das FrontEnd Zertifikat (Default Web Site) präsentiert.
Gruß, Frank
Hallo,
eine Frage dazu.
Wenn ich ein sav Zertifikat mit autodiscover.domäne.de und z.b mail.domäne.de erstelle und dies dem iss zuweise ( wies es z.b in deinem Zertifikats Tutorial beschrieben ist ), wird dann für die Kommunikation mit dem Backend noch immer das standard selbstsignierte Benutzt ? In dem SAN stehen ja nicht die lokalen Rechnernamen drinne.
Gruß und Danke Rene
Sehr guter Artikel – vielen Dank dafür!
Hintergrundwissen ist im echten Leben unbezahlbar!