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] Beim Verbinden mit dem Remoteserver „ex1.cloud.frankysweb.de“ ist folgender
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
Hilfethema „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.