Nach der Installation der Juli Sicherheitsupdates kann es passieren, dass das Exchange Administrative Center (EAC) und OWA nicht mehr geöffnet werden können. Die Ursache ist ein abgelaufenes Zertifikat für die Exchange Server OAuth Authentifizierung. Auch Microsoft weißt auf dieses Problem in den Release Notes der Updates hin. Leider überliest man die Hinweise zu den Updates ja manchmal, oder installiert die Updates beispielsweise mit WSUS, sodass die bekannten Probleme der Updates meist nicht mit bekommt. Daher an dieser Stelle mal ein kleiner Artikel wie das Problem behoben werden kann.
Ursache des Fehlers ist das abgelaufene Zertifikat mit dem Namen „Microsoft Exchange Server Auth Certificate“:
In der Ereignisanzeige des Exchange Servers wird der folgende Fehler protokolliert:
- Ereignis-ID: 1003
- Quelle: MSExchange Front End HTTPS Proxy
- Meldung:
[Owa] An internal server error occurred. The unhandled exception was: Microsoft.Exchange.Diagnostics.ExAssertException: ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1 bei Microsoft.Exchange.Diagnostics.ExAssert.AssertInternal(String formatString, Object[] parameters) bei Microsoft.Exchange.Diagnostics.ExAssert.RetailAssert[T1,T2](Boolean condition, String formatString, T1 parameter1, T2 parameter2) bei Microsoft.Exchange.Clients.Common.HmacProvider.GetCertificates() bei Microsoft.Exchange.Clients.Common.HmacProvider.GetHmacProvider() bei Microsoft.Exchange.Clients.Common.HmacProvider.ComputeHmac(Byte[][] messageArrays) bei Microsoft.Exchange.HttpProxy.FbaModule.SetCadataCookies(HttpApplication httpApplication) bei Microsoft.Exchange.HttpProxy.FbaFormPostProxyRequestHandler.HandleFbaFormPost(BackEndServer backEndServer) bei Microsoft.Exchange.HttpProxy.FbaFormPostProxyRequestHandler.ShouldContinueProxy() bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.BeginProxyRequestOrRecalculate() bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalOnCalculateTargetBackEndCompleted(TargetCalculationCallbackBeacon beacon) bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass280_0.b__0()
bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func2 filterDelegate, Action1 catchDelegate)
Mit dem folgenden Script lässt sich das Problem beheben:
Das Script muss in einer Exchange Shell mit administrativen Rechten (Elevated) ausgeführt werden. Das Script startet die IIS AppPools neu, dies sorgt zwar für keine Unterbrechung der Outlook Verbindung, es kann allerdings bis zu einer Stunde dauern, bis OWA und EAC wieder funktionieren. Hier muss man also Geduld aufbringen.
Hinweis: In einer Exchange Hybrid Umgebung muss nach dem Wechsel des Zertifikats der Hybrid Configuration Wizard erneut ausgeführt werden, damit die Änderungen auch im Azure AD übernommen werden.
Hallo,
ich habe einen Exchange 2019 mit aktuellsten Patch. Wenn ich das noch aktuelle Zertifikat mit WinACME ersteze, dann ist der OWA und der ECP nicht mehr erreichbar.
hat jemand eine Idee?
Grüße Rainer Schenkel
Beim EPC bekomme ich folgendes:
Serverfehler in der Anwendung /ecp.
https://localhost/owa/auth/errorFE.aspx?CafeError=SSLCertificateProblem
Beschreibung: Unbehandelte Ausnahme beim Ausführen der aktuellen Webanforderung. Überprüfen Sie die Stapelüberwachung, um weitere Informationen über diesen Fehler anzuzeigen und festzustellen, wo der Fehler im Code verursacht wurde.
Ausnahmedetails: System.Web.HttpException: https://localhost/owa/auth/errorFE.aspx?CafeError=SSLCertificateProblem
Quellfehler:
Beim Ausführen der aktuellen Webanforderung wurde einen unbehandelte Ausnahme generiert. Informationen über den Ursprung und die Position der Ausnahme können mit der Ausnahmestapelüberwachung angezeigt werden.
Stapelüberwachung:
[HttpException (0x80004005): https://localhost/owa/auth/errorFE.aspx?CafeError=SSLCertificateProblem%5D
Microsoft.Exchange.HttpProxy.FbaModule.OnBeginRequestInternal(HttpApplication httpApplication) +441
Microsoft.Exchange.HttpProxy.c__DisplayClass20_0.b__0() +1679
Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate) +35
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +142
System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +75
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +93
Versionsinformationen: Microsoft .NET Framework-Version:4.0.30319; ASP.NET-Version:4.8.4494.0
Hey zusammen,
die Zertifikate werden in UTC ausgestellt. Sprich Server auf UTC umstellen, Zertifikat ausstellen, Server wieder in die eigentliche Zeitzone setzen. Damit spart Ihr euch das warten / den Ausfall von OWA etc.
Grüße
Hallo Frank, leider funktioniert es hier nicht. Denn das Zertifikat wird zwar erstellt, jedoch nur mit einer Gültigkeit von 2 Minuten.
Hallo,verstehe ich das richtig, das das Zertifikat 1x erneuert und veröffentlicht wird ? Reicht es also das Script auf einem von 4 Servern auszuführen und bei den anderen 3 nur die App Pools neu zu starten ?
„Exchange 2016 Setup erstellt ein selbstsigniertes Zertifikat mit dem Anzeigenamen „Microsoft Exchange Server Auth Certificate“ und repliziert es auf alle Front-End-Server in der Exchange-Organisation.“
also wirklich, hier finde ich immer das Richtige….
Vielen Dank und frohe Festtage
Hatte genau diesen Fehler heute (06.12.2021) nach dem Security Update CU23 KB5007409 (Server 2012, Exchange 2013).
Vielen Dank für die Hilfestellung!
Hat geklappt. Nach dem Einspielen des PS-Scriptes hat es 2-3 Std. gedauert, dann hat der Zugriff auf ECP und OWA wieder funktioniert.
Hallo Zusammen,
ich habe mehrere Exchange Server, bei denen nur bei 2 neu installierten 2019ern die Zertifikate fehlen.
Muss ich dann das Skript nur auf den beiden Neuen ausführen oder?
Das Zertifikat auf den funktionierenden Servern wird davon nicht geändert oder?
Danke!
Gruß
Daniel
Guten Abend,
Ich habe es geschafft mein Exchange läuft wieder zu 100%.
Jetzt meine frage CU21 ist ja schon Installiert.
Soll/muss ich jetzt das Exchange2016-KB5004779-x64-de.msp Installieren und danach wie oben beschrieben alles ausführen ?
Oder soll ich das Exchange2016-KB5004779-x64-de.mps weglassen ?
Danke
Dadurch bei mir nix mehr Funktionierte.
Habe ich das Exchange2016-KB5004779-x64-de De-Installiert und Neugestartet.
Danach im IIS die Bindungen überprüft und das Zert angegeben.
Seitdem habe ich via Managment Shell wieder zugriff.
Wenigstens eines Funktioniert wieder.
Aber Outlook kann sich noch immer nicht Verbinden.
ECP und OWA Funktionieren ebenfalls noch immer nicht.
Zugriff auf die Exchange Management Shell kommt das :
New-PSSession : [MAILservername] Beim Verbinden mit dem Remoteserver „MAILservername“ ist folgender Fehler
aufgetreten: Die Anforderung kann von WinRM nicht verarbeitet werden. Bei Verwendung der Kerberos-Authentifizierung
ist der folgende Fehler mit Fehlercode 0x8009030e aufgetreten: Eine angegebene Anmeldesitzung ist nicht vorhanden.
Sie wurde gegebenenfalls bereits beendet.
. Mögliche Ursachen:
– Der angegebene Benutzername oder das angegebene Kennwort ist ungültig.
– Kerberos wird verwendet, wenn keine Authentifizierungsmethode und kein Benutzername angegeben werden.
– Kerberos akzeptiert Domänenbenutzernamen, aber keine lokale Benutzernamen.
– Der Dienstprinzipalname (Service Principal Name, SPN) für den Remotecomputernamen und -port ist nicht vorhanden.
– Der Clientcomputer und der Remotecomputer befinden sich in unterschiedlichen Domänen, zwischen denen keine
Vertrauensbeziehung besteht.
Wenn Sie die oben genannten Ursachen überprüft haben, probieren Sie folgende Aktionen aus:
– Suchen Sie in der Ereignisanzeige nach Ereignissen im Zusammenhang mit der Authentifizierung.
– Ändern Sie die Authentifizierungsmethode; fügen Sie den Zielcomputer der Konfigurationseinstellung „TrustedHosts“
für WinRM hinzu, oder verwenden Sie den HTTPS-Transport.
Beachten Sie, dass Computer in der TrustedHosts-Liste möglicherweise nicht authentifiziert sind.
– Führen Sie den folgenden Befehl aus, um weitere Informationen zur WinRM-Konfiguration zu erhalten: „winrm help
config“. Weitere Informationen finden Sie im Hilfethema „about_Remote_Troubleshooting“.
Andere mögliche Ursache:
Der Domänen- oder Computername war in den angegebenen Anmeldeinformationen nicht enthalten. Beispiel: DOMAIN\UserName
oder COMPUTER\UserName.
In Zeile:1 Zeichen:1
+ New-PSSession -ConnectionURI „$connectionUri“ -ConfigurationName Micr …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : 1312,PSSessionOpenFailed
Hallo,
Ich bekam heute in Outlook das mein Cert abgelaufen ist. Habe ein Neues erstellt. Aber es funktioniert nicht.
Exchange Management Shell funktioniert nicht.
Wie hier beschrieben die Scripte funktionieren auch nicht.
Kann mir bitte jemand Helfen ?
C:\Users\Administrator\Desktop\New-ExchangeOAuthCertificate.ps1 : Die Benennung „Get-AcceptedDomain“ wurde nicht a
Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die
Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
In Zeile:1 Zeichen:1
+ .\New-ExchangeOAuthCertificate.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,New-ExchangeOAuthCertificate.ps1
Hey,
ich hatte das Problem auch auf einem Ex2016 unter W12R2.
Ich konnte es nach der installation von KB5004779 sofort lösen über diese Anleitung (bei mir ohne Wartezeit)
https://www.der-windows-papst.de/2021/03/14/microsoft-exchange-server-auth-certificate-is-missing/
New-ExchangeCertificate -KeySize 4096 -PrivateKeyExportable $true -SubjectName “cn= Microsoft Exchange Server Auth Certificate” -DomainName “*.dwp.local” -FriendlyName “Microsoft Exchange Server Auth Certificate” -Services smtp
$date=get-date
Set-AuthConfig -NewCertificateThumbprint E44267F16D478E1435F44BE320496C964CA1FDB0 –NewCertificateEffectiveDate $date
Set-AuthConfig –PublishCertificate
Set-AuthConfig -ClearPreviousCertificate
IISRESET
Nachdem das Zertifikat erstellt und gebunden wurde, kann es vorkommen, das man 1 Stunde warten muss, bis das Zertifkat seine Anwendung findet. Gerade in Hinblick auf das Thema und der Fehlermeldung “ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1”.
Vielen Dank – das hat mir geholfen heute bei meinem Problem mit „ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1"-Problem ;-)
Vielen Dank für das Script – es dauert tatsächlich mehrere Stunden – Wie bereits die „Vorposter“ erwähnten – Geduld ist angesagt.
Gruß
BS
Servus in die Runde,
vllt. hat jemand einen Lösungsansatz oder steht vor dem gleichen Problem, bei dieser Exchange Cluster Config.
Exc2016 2x Frontend 4xBackend (DAG) – „ja, wird heute nicht mehr so gebaut, hab es von meinem Vorgänger übernommen“. :)
Nach CU21 lief alles noch problemlos, nachdem das SecurityUpdate installiert wurde, funktionierte wie zu erwarten OWA & EAC nicht mehr.
Betroffenes Cert, wäre bei uns erst am 07.12.2021 abgelaufen.
⦿CU21 sowie SecurityUpdate auf allen 6 Servern installiert.
⦿Script von Franky schon auf allen Servern ausgeführt
⦿das Vorgehen von MS schon durchgespielt auf allen Servern
https://docs.microsoft.com/en-us/exchange/troubleshoot/administration/cannot-access-owa-or-ecp-if-oauth-expired
⦿altes Cert erneut gebunden
⦿sowie den Ansatz, dass die Zeitzone vor erstellen eines neuen Certs auf UTC gestellt wird und nachträglich wieder zurück
Durch Dienstleister wurde das Ticket direkt an MS eskaliert, da ich jetzt keine Idee mehr habe
Lösung bei unserem nicht funktionierenden OWA/EAC.
UpdateCas.ps1 auf jedem Server laufen lassen.
beim CU19 wurde das Script automatisch während des Updates ausgeführt, was beim CU21 nicht passiert ist.
Update der Version war von 15.1.2308.8 auf die 15.1.2308.14 – anschließend waren alle Services wieder verfügbar.
Franky hatte dies 2018 schon einmal in einem Beitrag erwähnt.
https://www.frankysweb.de/exchange-2016-serverfehler-in-anwendung-owa-und-oder-ecp/
Mahlzeit,
ich habe – wie üblich – erst *nach* der Installation des Updates an den üblichen Stellen gelesen. Bei unserem Exchange 2013 CU23 ist zunächst auch das Problem des unbekannten Thumbprint für das OAuth Zertifikat aufgetreten. Das lässt sich ja relativ einfach fixen – OWA und ECP laufen. Allerdings lässt sich Outlook nur mit viel Geduld zur Verbindung überreden und scheint immer mal wieder die Verbindung zu verlieren.
Zudem kann man auf dem Server die Management Shell nicht mehr starten mit dem Hinweis: ‚… die angeforderte HTTP-URL nicht verfügbar ist….‘
Im Eventlog finden sich keine Hinweise – was tun?
Die Lösung war dem IIS als IP-Adresse ‚Keine zugewiesen‘ für die Websites Default und Backend erneut zuzuweisen. Warum auch immer, es war nur die primäre IP zugeordnet. Die zweite IP ist für die iSCSI Verbindung.
Ich gehe davon aus, dass es als ungültig angesehen wird.
Als Ursache kann ich mir unsicherer Algorythmus wie SHA1 oder so vorstellen!
Hallo Leute.
Ich hab gestern früh ganz entspannt auf meinem Exchange Server 2016 CU20 das Sicherheitsupdate eingespielt und musste feststellen, ups kein Zugriff mehr auf OWA und ECP.
Deinstallieren kann ich das Update leider auch nicht mehr.
Nun hab ich ein neues Cert erstellt, dieses läuft auf den Services I W S. Auch nach mehrmaligem Neustart und abwarten seit gestern Abend bekomme ich die aufgeführt Fehlermeldung.
Hab auch den Trick mit der „Worldtime“ ausprobiert und den IIS immer resetet. Leider ohne Erfolg. Wo mache ich den Fehler?
Zur Info das neue Cert ist gültig seit gestern bis 2026.
Kann mir einer noch nen Tip geben?
Kurzes Update der Lage.
Ich habe nun das CU21 ohne Probleme installiert. Danach liefen ECP und OWA wieder ohne Probleme.
LG
die letzten CUs waren immer problematisch, aber diesmal hat der Exchange 2019 das echt problemlos durchgemacht.
Hatte schon das Script parat zur Ausführung, aber nach dem Einspielen des CU10 und Neustart hat alles normal funktioniert. Soll man das script trotzdem ausführen? Bis wohin verlängert sich das msexch-Auth Zert dann?
Zertifikat ist bei mir mit „not after“ 26.10.2021terminisiert – spätestens da muss ich dann wohl prüfen bzw. erneuern.
Hallo zusammen,
hallo Frank,
habe 4 Kunden – da laufen Mailserver so mit – sollen sie!
2013, 2016 und 2019 – der 2013 hat jetzt den Fehler. Owa/ecp geht nicht mehr – löscht man den Update geht es wieder. Ergo, kann ja wohl das Zertifikat nicht abgelaufen sein – ist geht auch noch bis 2025. ???
2x 2016 und 1 x 2019 habe ich deswegen erstmal nix gemacht.
Sorry, mich kotzt diese MS-Sch…. langsam aber sicher an. Alle paar Wochen irgendein Mist. Erst gehackt, dann Immer wieder Sicherheitslücken und jetzt auch noch der Update fehlerhaft.
Vielleicht bin ich zu blöd bzw. bei manchen Dingen auch echt nicht so sicher!
Habe Frank geschrieben: benötige jemanden der mir mal hilft – gegen Bezahlung.
Freu mich auf Rückmeldungen.
info@stefankempf.com
Gruss
Stefan
„Gereitzt“
Moin,
Ich kann leider nicht viel helfen, nur den Hinweis geben das bei uns schon vor dem Update das Zertifikat abgelaufen war (und trotzdem alles lief), nach dem Update scheint Exchange das genauer zu prüfen ob das Zertifikat okay ist oder nicht.
Gruß
Philipp
Hallo wer nicht X Stunden warten möchte :-)
kann auch gerne die Zeitzone des Exchagne Server auf „UTC World Time“ ändern, dann den IIS Reset per cmd console starten..
und siehe da es geht wieder… MAGIC…
Quelle:
https://docs.microsoft.com/en-us/exchange/troubleshoot/administration/cannot-access-owa-or-ecp-if-oauth-expired
ChristianZickler-1785 · 5 days ago
I found this solution in another post.
There seems to be a timezone issue with this fix. So to get around the 12 hour waiting, you can just change the timezon in your Windows Exchange Server to UTC World Time.
Afterwards you can login to ecp without having to wait.
I found this solution in another post.
There seems to be a timezone issue with this fix. So to get around the 12 hour waiting, you can just change the timezon in your Windows Exchange Server to UTC World Time.
Afterwards you can login to ecp without having to wait.
Wo genau wird die Zeitzone des Exchange Servers 2019 auf UTC World Time eingestellt?
Danke für Hilfe
Hallo, die Systemzeit (Zeitzone) des Exchange Server, also dann die Zeitzone des Windows Server.
Hallo Guido,
das war der entscheidende Hinweis. Unsere Server laufen auf CET, daher ist das neu erzeugte Zertifikat erst ab „in 1 Stunde“ gültig. Also haben wir gewartet und anschießend per IISRESET die Apps neu gestartet.
Beim nächsten Mal werden wir das Zertifikat erst erzeugen, dann 1h warten und dann die restlichen Schritte ab set-authconfig vornehmen.
Viele Grüße
Uwe
Sollte das neue Zertifikat bei dieser Gelegenheit nicht gleich gegen SHA2 ausgetauscht werden?
Das „New-ExchangeOAuthCertificate.ps1“-Script erzeugt ja wieder ein altes SHA1-Zertifikat, oder?
Moin Franky,
danke für die Infos.
Bei uns war nicht das betroffene Zertifikat abgelaufen, sondern war einfach nach dem Update nicht mehr
zugewiesen bzw. es stand ein komplett anderer Thumbprint drin, welcher überhaupt nicht mehr zu einem existierenden Zertifikat gehörte.
Also dann statt ein neues Zertifikat zu erstellen das vorhandene, gültige neu zuweisen und dann lief das umgehend wieder.
Gruß, Mario
Hallo Mario,
mit welchem PS Befehl hast du sas vorhandene Zertifikat wieder zugewiesen?
Hallo Dirk,
hatte genau das gleiche Phänomen wie Mario, Zert vorhanden und noch gültig aber nicht mehr zugewiesen, und es lief mit diesem vorhandenen Zertifikat danach auch wieder.
1. Thumbprint des vorhandenen gültigen aber aktuell nicht zugewiesenen Zerts mit „Get-ExchangeCertificate“ ermitteln. Ist der wo „CN=Microsoft Exchange Server Auth Certificate“ als Subject steht.
Danach:
Set-AuthConfig -NewCertificateThumbprint -NewCertificateEffectiveDate (Get-Date)
Set-AuthConfig –PublishCertificate
Danach noch den „Microsoft Exchange Service Host Service“ und IIS neu gestartet und schon klappte OWA/ECP wieder
Hoffe das hilft.
Danke.
Hallo Robert,
auch von mir vielen Dank für den Hinweis, hat unter Exchange 2013 wunderbar geklappt.
VG Timm
Danke, das war die Lösung/ Rettung
Ja, das half jetzt auch im November 2021. Danke.
Allerdings, um schlüsselfertig zu machen.
Set-AuthConfig -NewCertificateThumbprint {Thumbprint_Wert} -NewCertificateEffectiveDate (Get-Date)
MfG
Moin
bei uns hat es auch ca. 6 Stunden gedauert bis wieder alles gut war, Geduld ist wichtig.
Gruß
Philipp
Vielen Dank für den Hinweis.
Ergänzend Mircosofts Statement:
https://docs.microsoft.com/en-us/exchange/troubleshoot/administration/cannot-access-owa-or-ecp-if-oauth-expired
Bei uns hat es ca. 12 Stunden gedauert, also Geduld hilft.
Ralph Andreas
2 Stunden bei mir! Vielen Dank.
Klaus