Via the configuration of Certificates on Exchange Servers I have already written about this several times, but I have mostly dealt with the front end certificates. However, Exchange servers also have a back end which is configured with a self-signed certificate. The back end certificate does not need to be replaced by a publicly valid certificate or by a certificate from your own PKI. The self-signed certificate is completely sufficient for the back end. However, it is important that the back end certificate with the display name "Microsoft Exchange" is valid and available, otherwise web services such as OWA and ECP will not start:
The "Microsoft Exchange" certificate is bound to the "Exchange Back End" website in the IIS Manager:
Exchange servers indicate expiring certificates in the event display; a message about an expiring certificate looks like this, for example:
Here is the text of the message:
Log Name: Application
Event ID: 12018
Source: MSExchangeTransport
The STARTTLS certificate will expire soon: subject: FQDN, thumbprint: THUMBPRINT, expires: 08.03.2023 11:49:08. Run the New-ExchangeCertificate cmdlet to create a new certificate.
The "Microsoft Exchange" certificate is valid for 5 years and should be renewed in good time. If the certificate has been accidentally deleted or is no longer available for any other reason, please continue reading here:
If the certificate is due for renewal, a new certificate can be issued quite quickly with a small script and configured for the Exchange back end, I have published the script on GitHub:
The script only needs to be copied to the respective Exchange server and executed. The script issues a new self-signed certificate based on the "Microsoft Exchange" certificate, copies it to the Trusted Root Certification Authorities store and finally assigns it to the "Exchange Back End" web page in the IIS.
After the script has been executed, it is already being used by Exchange. It is a good idea to restart the IIS using "iisreset". If there are no problems, the old certificate can be deleted. The script does not automatically delete the old certificate. If there are problems with renewing the certificate, please send the error messages via the contact form or directly to GitHub.
Hallo,
vielen Dank für das Skript, hab es erfolgreich auf zwei Exchange 2016 Servern ausgeführt.
2 Dinge sind mir aufgefallen:
1. bekomme ich eine Warnung:
WARNUNG: Dieses Zertifikat wird nicht für externe TLS-Verbindungen mit einem FQDN von ‚mein_exchangeserver‘
verwendet, weil das von einer CA signierte Zertifikat mit dem Fingerabdruck ‚…‘
den Vorrang übernimmt. Die folgenden Connectors stimmen mit dem betreffenden FQDN überein: Default mein_exchangeserver,
usw.
Heisst das, das Back End Zertifikat muss vorhanden und gültig sein, benutzt wird aber das Zertifikat unserer CA?
2. ist das neue Zertifikat hier auch an die Default Web Site gebunden worden, das musste ich per Hand zurücksetzen
Viele Grüße!
Hallo,
nachdem ich das Script ausgeführt habe kam folgende Meldung:
Copy new certificate to Trusted Root Certification Authorities…
Ausnahme beim Aufrufen von „Add“ mit 1 Argument(en): „Der Wert darf nicht NULL sein.
Parametername: certificate“
In C:\scripts\New-ExchangeBackEndCertificate.ps1:26 Zeichen:1
+ $DestStore.Add($cert)
+ ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : ArgumentNullException
Change Exchange Server BackEnd certificate to new certificate…
Eine angegebene Anmeldesitzung ist nicht vorhanden. Sie wurde gegebenenfalls bereits beendet. (Ausnahme von HRESULT:
0x80070520)
In C:\scripts\New-ExchangeBackEndCertificate.ps1:35 Zeichen:1
+ $binding.AddSslCertificate($Thumbprint, „my“)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [], COMException
+ FullyQualifiedErrorId : System.Runtime.InteropServices.COMException
Und nun geht nix mehr, ECP nicht verfügbar, Kunde meldete sich bereits, dass Outlook nicht läuft, und die Exchange Management Shell kann sich nicht mehr zum Exchange verbinden. Server 2019 mit Exchange 2019 CU 12.
Meldung der Management Console:
New-PSSession : [srv-exc.domain.de] Beim Verbinden mit dem Remoteserver „srv-exc.domain.de“ ist
folgender Fehler aufgetreten: 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 : -2144108477,PSSessionOpenFailed
Hallo,
bitte mal Prüfen ob im IIS-Manager unter „Sites -> Exchange Back End“ das Back End Zertifikat noch an https gebunden ist. Falls nein muss das Zertifikat einfach wieder zugewiesen werden und dann sollte es wieder funktionieren.
Hallo,
das liegt vermutlich daran, dass das cmdlet Get-ExchangeCertificate eine leere Antwort liefert. Das kann auftreten, wenn „Certificate signing of PowerShell serialization payload enabled“ ist, was mit den Security Updates NOV23 aktiviert wurde. Dazu gibt es auch Anleitungen. Evtl. ist das Exchange Server Auth Zertifikat auch ungültig.
Hallo Stefan,
habe das gleiche Problem, wie hast du es gelöst?
Hallo
Bei unserem Exchange 2013 kommt die Meldung zum Script:
Die Datei „D:\inst\New-ExchangeBackEndCertificate.ps1 kann nicht geladen werden. Die Datei ist nicht digital signiert. Sie können dieses Script im aktuellen System nicht ausführen…
Hat das auch jemand gehabt, wie löse ich das?
Vielen Dank
Hallo,
Kurze Fragen, Scripft hat problemlos funktioniert nur taucht jetzt Ständig im Outlook die Zertifikatsabfrage auf die man mit ja beantworten muss. Wie bekomme ich das weg?
So unlogisch es auch klingen mag: Einmal sagen, das man nicht fortsetzen möchte. Dann prüft Outlook alles noch einmal und sollte anschliessend erledigt sein und keine neuen Abfragen mehr kommen.
Hi, ich mach dies zu ersten mal, in der fast letzten Zeile muss dann der alte Thumbprint vom alten MS Cert rein, oder?
$binding.AddSslCertificate($Thumbprint, „my“)
Hallo Franky,
bei mir bringt er beim Script die Fehlermeldung das das & einem anderen Operator zugewiesen ist und durch „&“ ersetzt werden soll.
Bringt aber leider auch nichts.
Entweder bin ich zu doof oder irgendwas ist faul.
Server 2019 mit Exchange 2016
Exchange 2016 ist auf dem Server 2019 nicht supported:
https://learn.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2016
Kann eventuell daran liegen.
Hallo ich habe beim EX2016 dieses Problem bekommen:
Copy new certificate to Trusted Root Certification Authorities…
Ausnahme beim Aufrufen von „Add“ mit 1 Argument(en): „Der Wert darf nicht NULL sein.
Parametername: certificate“
In C:\scripts\New-ExchangeBackEndCertificate.ps1:26 Zeichen:1
+ $DestStore.Add($cert)
+ ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : ArgumentNullException
Change Exchange Server BackEnd certificate to new certificate…
Eine angegebene Anmeldesitzung ist nicht vorhanden. Sie wurde gegebenenfalls bereits beendet. (Ausnahme von HRESULT:
0x80070520)
In C:\scripts\New-ExchangeBackEndCertificate.ps1:35 Zeichen:1
+ $binding.AddSslCertificate($Thumbprint, „my“)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [], COMException
+ FullyQualifiedErrorId : System.Runtime.InteropServices.COMException
Done!
hallo detlef, hast du dazu hilfe bekommen, ich hab das gleiche problem? :-). danke schonmal!
Lieber Franky
Was würden wir ohne Dich machen!
Vielen Dank für die Super Anleitung und das Script!
Ich habe auch noch ein selbstsigniertes Federation Zertifikat, das abläuft. Hast Du dafür auch so eine elegante Lösung?
Danke Erich
Bei unseren Exchange Servern gibt es auch ein Zertifikat mit Name „Microsoft Exchange Server Auth Certificate“, welches etwa 5 Wochen vor dem hier genannten Backend-Zertifikat abläuft. Muss man sich hierum auch kümmern oder erneuert der Exchange dieses „Server Auth Certificate“ von selbst?
Das wurde von Franky schon vor einiger Zeit beschrieben und es gibt auch ein Script dafür.
https://www.frankysweb.de/exchange-server-owa-und-eac-starten-nicht-nach-installation-der-juli-updates/
Oder mit diesem Script
https://microsoft.github.io/CSS-Exchange/Admin/MonitorExchangeAuthCertificate/
Eine Frage: Ist der Signaturalgorithmus vom neuen Zertifikat sha1 oder sha256?
Unser aktuelles Backend Zertifikat nutzt noch sha1 und ich würde dies gerne aktualisieren und gegen ein sha256 Zertifikat austauschen.
Kommt auf die Vorlage drauf an.
Die sollte aber auf sha256 umgestellt werden, falls noch die noch sha1 ist.
sha1 ist nicht sicher und sollte nicht mehr verwendet werden.
Mit den aktuellen Exchange 2016 / 2019 CUs werden mit New-ExchangeCertificate SHA256 Zertifikate ausgestellt, da braucht man sonst nichts machen.
Danke!!!
Geht wohl nur bei Neuinstallationen KB5006983:
https://support.microsoft.com/en-gb/topic/exchange-server-2019-and-2016-certificates-created-during-setup-use-sha-1-hash-kb5006983-83282c37-1cbf-4a9d-b6a6-8390fac42eeb
Nachtrag:
Läuft das Script auch auf Exchange 2016?
Hallo
Ein gutes neues Jahr und vielen Dank für deinen unermüdlichen Einsatz für uns!
1. was passiert, wenn man es einfach nicht macht?
2. Muss das auch bei einem Server gemacht werden, bei dem „Alles“ (DC und kompletter Exchange) läuft und mit WinACME ein öffentliches Let’s-Encrypt -Zertifikat genutzt wird.
Herzlichen Gruss
Beat
Zu 1: Wenn du es nicht machst und das Zertifikat abgelaufen ist, bekommst du Probleme mit dem Exchange ECP und OWA funktionieren nicht mehr, etc.).
Zu 2: Ja, das muß auch auf solchen Servern gemacht werden.
Wobei ein DC mit Exchange drauf von Microsoft nicht empfohlen wird, ja es wird sogar davon abgeraten.
Das ist keine unterstützt Konfiguration und der BPA im Servermanager wirft eine Warnung.
Früher gabs so etwas mal von Microsoft selbst in Form des Small Business Servers, aber da war die letzte Version 2011 (Server 2008R2 mit Exchange 2010, Sharepoint 2010, SQL Server, etc.). Aber da hat man gesehen, das diese Geschichte nicht vernünftig funktioniert (z.B. hunderte Fehlermeldungen in der Ereignisanzeige, die lt. Microsoft alle ignoriert werden sollten, etc.). Deshalb gabs davon auch keinen Nachfolger mehr.
Best Practice ist: Pro Dienst einen Server!
Was machst du z.B., wenn du den DC wegen einer Wartung neu starten musst?
Dann ist für die Zeit auch der Exchange weg.
Willst du das wirklich?
Deshalb macht man pro Dienst einen Server.
Doch es ist unterstützt, nur eben nicht empfohlen.