I have now received several emails with questions about the Exchange backend certificate, so here is a short article about it. In most cases, the backend certificate was deleted during cleanup. The following article deals with the function and necessity of the backend certificate and also how to restore it if it has been accidentally deleted.
What is the backend certificate?
The backend certificate is a self-signed certificate that is created when an Exchange Server is installed. The backend certificate contains the NetBIOS name and the FQDN of the Exchange Server and is valid for 5 years.
The certificate is created with the display name "Microsoft Exchange" and bound to the IIS service:
However, the certificate is only used by Exchange for the IIS website "Exchange Back End" and is bound to port 444:
In the certificate MMC, the backend certificate is displayed as a self-signed certificate. Here you can see that NetBIOS and FQDN are included as SANs (Subject Alternate Names):
If this certificate is deleted, an encrypted connection to the "Exchange Back End" website is no longer possible, but this is required by the website:
What is the Exchange backend certificate used for?
The IIS server of an Exchange Server provides two websites for Exchange Server, the "Default Web Site" is basically the frontend, i.e. the website that users also call up when they access OWA, for example. Almost all other services are also made accessible to the user via the front end (Exchange UM is a minor exception). The "Default Web Site" therefore has the certificate that is presented to the user.
The second website is the "Exchange Back End". The user does not call the back end directly, but the front end works in principle like a proxy for the back end. The front end forwards the user connections for the various protocols to the back end. The backend handles the actual processing of the connection. The user therefore does not call the backend directly, but is forwarded to the backend via the frontend, with one exception (Exchange UM).
Back to the backend certificate: The backend certificate is used to encrypt or decrypt the connection between the frontend and backend on port 444. In an environment with only one Exchange Server, the frontend of the Exchange Server communicates with the backend in encrypted form; the backend certificate is required for this. In environments with several Exchange servers, the Exchange servers also communicate with each other via the backend; the backend certificate is also required here. In environments with several Exchange servers, the front ends can also access other Exchange back ends.
The verification of the backend certificate by the Exchange servers is not as strict as the verification from Outlook to the frontend. The backend certificate must therefore only contain the name of the Exchange server and may also be self-signed. The user does not see the backend certificate, so the backend certificate does not have to be replaced by a valid certificate from a public CA.
When replacing the backend certificate with a public certificate, problems can even occur between the communication of several Exchange servers. The cause is usually the missing Exchange server name on the backend certificate.
Therefore: Simply leave the backend certificate as it is, do not delete it, do not replace it, only renew it when it expires.
Backend certificate deleted, how to restore?
For this article I have deleted the backend certificate of the Exchange Server:
Since the certificate was deleted, the "Exchange Back End" website in IIS is now without a certificate, so an https connection on port 444 from front end to back end is no longer possible:
The consequences: The Exchange Management Shell no longer connects, but the error message is not very helpful:
New-PSSession : [ex1.cloud.frankysweb.de] When connecting to the remote server "ex1.cloud.frankysweb.de" the following is displayed
Error occurred: [ClientAccessServer=EX1,BackEndServer=ex1.cloud.frankysweb.de,RequestId=d6f8b99b-0d90-4ca5-b814-375
235837774,TimeStamp=13.03.2018 21:10:45] [FailureCategory=Cafe-SendFailure] Further information can be found in the
Help topic "about_Remote_Troubleshooting".
The login screen for the EAC is still displayed, as it is delivered by the front end:
But after entering the user name and password, only a blank page is displayed:
Exchange services also call for help in the event log. Here you receive an error message that is meaningful and points in the right direction:
Event ID: 12014
Source: 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.
In this case, Outlook can no longer establish a connection, so a new certificate must be created for the backend. A new self-signed certificate can be easily created via the IIS Manager.
To create a new certificate, go to Server certificates in the IIS Manager:
Under "Actions" you will find the menu item "Create self-signed certificate":
The display name does not matter, for the sake of order, "Microsoft Exchange" can be entered here again:
The certificate has been created and is now displayed with the name "Microsoft Exchange":
Now the certificate only needs to be bound to the backend website:
After the new self-created certificate has been assigned, the Exchange Shell also reconnects:
ECA also reconnects immediately, a restart of the server is usually not necessary.
puuh… mir hat dein Artikel auch eben den Arsch gerettet. Das ich nen Zertifikat „zu viel“ geloescht hatte, hab ich mir schon gedacht.
Also: Danke!
Gruss UWe
Vielen Dank! Hätte ich das nur 12 Stunden vorher gelesen….
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!