Über die Konfiguration von Zertifikaten auf Exchange Servern habe ich ja schon mehrfach geschrieben, meistens habe ich da allerdings die Front End Zertifikate behandelt. Exchange Server verfügen aber auch über ein Back End welches mit einem selbst signierten Zertifikat konfiguriert ist. Das Back End Zertifikat muss nicht gegen ein öffentlich gültiges Zertifikat oder durch ein Zertifikat einer eigenen PKI ersetzt werden. Das selbst signierte Zertifikat reicht für das Back End völlig aus. Wichtig ist allerdings, dass das Back End Zertifikat mit dem Anzeigenamen „Microsoft Exchange“ gültig und vorhanden ist, andernfalls starten beispielweise die Webservices wie OWA und ECP nicht:
Das Zertifikat „Microsoft Exchange“ ist im IIS-Manager an die Webseite „Exchange Back End“ gebunden:
In der Ereignisanzeige weisen Exchange Server auf ablaufende Zertifikate hin, eine Meldung über ein ablaufendes Zertifikat sieht beispielsweise wie folgt aus:
Hier einmal der Text der Meldung:
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.
Das Zertifikat „Microsoft Exchange“ ist 5 Jahre lang gültig und sollte rechtzeitig verlängert werden. Falls der Zertifikat versehentlich gelöscht wurde oder aus anderem Grund nicht mehr verfügbar ist, dann bitte hier weiterlesen:
Falls die Erneuerung des Zertifikats ansteht, lässt sich ein neues Zertifikat mit einem kleinen Script recht schnell ausstellen und für das Exchange Back End konfigurieren, Das Script habe ich auf GitHub veröffentlicht:
Das Script muss nur auf den jeweiligen Exchange Server kopiert und ausgeführt werden. Das Script stellt ein neues selbst signiertes Zertifikat auf Basis des Zertifikats „Microsoft Exchange“ aus, kopiert es in den Speicher für Vertrauenswürdige Stammzertifizierungsstellen und weißt es zum Schluss der Webseite „Exchange Back End“ im IIS zu.
Nachdem das Script ausgeführt wurde, wird es bereits durch Exchange verwendet. Es bietet sich an bei Gelegenheit den IIS mittels „iisreset“ neu zu starten. Wenn es keine Probleme gibt, kann das alte Zertifikat gelöscht werden. Das Script löscht das alte Zertifikat nicht automatisch. Falls es Probleme mit dem Erneuern des Zertifikats gibt, dann schickt die Fehlermeldungen gerne per Kontaktformular oder direkt auf 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
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.