Exchange: OWA funktioniert nicht – Event ID 1003

Ruft man die Outlook im Web oder das Exchange Control Panel auf und erhält die Fehlermeldung „ASSERT: HMACProvider.GetCertificates protectionCertificates.Length<1„, dürfte es wohl ein Problem mit dem internen Auth-Zertifikat geben. Glücklicherweise lässt sich das Problem mit einigen wenigen Powershell Befehlen relativ schnell beheben. Welche Schritte notwendig sind, zeige ich dir in diesem Artikel.

Die Ursache

In den meisten Fällen dürfte das Microsoft Exchange Auth Zertifikat dafür verantwortlich sein. Entweder es ist abgelaufen oder gar nicht mehr vorhanden. Aufgrund der langen Gültigkeitsdauer von standardmäßig 5 Jahren wird gerne darauf vergessen und es fällt erst auf, wenn es zu Komplikationen kommt. So trat das Problem auch vermehrt nach dem Exchange Security Update vom Juli 2021 auf. Viele Administratoren wurden mit dieser Fehlermeldung nach dem Einspielen des Patches konfrontiert (je nach Exchange Version kann sie unterschiedlich aussehen).

Das Anmelden im OWA (Outlook im Web) oder auch im ECP (Exchange Control Panel) ist somit nicht mehr möglich. Postfächer, welche mittels dem Outlook Client angesprochen werden, funktionieren hingegen ohne Probleme. Im EventViewer lassen sich auf Error-Reports mit der ID 1003 finden:

Um zu überprüfen, ob das genannte Zertifikat tatsächlich abgelaufen ist, kann folgender Befehl in der Management Shell ausgeführt werden:

[PS] C:\Windows\system32>Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint | select Subject, NotAfter, NotBefore

Subject                                       NotAfter            NotBefore
-------                                       --------            ---------
CN=Microsoft Exchange Server Auth Certificate 03.08.2021 09:34:18 03.08.2016 09:34:18

Es sollte sofort ersichtlich sein, dass das Zertifikat abgelaufen ist und erneuert werden muss.

Die Lösung

Folgende Schritte sind notwendig, um ein neues Zertifikat auszustellen und zu deployen:

### Generate a new Certificate, replace the DomainName with your Exchange Domain
New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName "exchange.domain.com"

### Set the new generated Exchange Certificate as Authentication Certificate
Set-AuthConfig -NewCertificateThumbprint <ThumbprintFromStep1> -NewCertificateEffectiveDate (Get-Date)
Set-AuthConfig -PublishCertificate
Set-AuthConfig -ClearPreviousCertificate

### Restart the IIS Server (needs Administrator Privileges)
iisreset /restart

Solltet ihr euren Exchange in einer hybriden Umgebung betreiben, müsst ihr anschließend auch noch den Hybrid Configuration Wizard erneut ausführen. Nur so werden die Änderungen auch im Azure AD übernommen.

Zeitzonenverschiebung zu UTC

WICHTIG: Sollte nach dem Setzen des neuen Zertifikats die Fehlermeldung trotzdem auftauchen, dann liegt das höchstwahrscheinlich an eurer Zeitzone. Stellt man ein neues Zertifikat mit den oben angeführten Befehlen aus, so wird als Ausstellungszeit die am Server gesetzte Zeitzone verwendet. In meinem Fall also UTC+2. Der Exchange ignoriert allerdings anscheinend die gesetzt Zeitzone und arbeitet hierbei ausschließlich mit der UTC Zeit. Somit haben wir folgendes Szenario:

• Das Zertifikat gilt ab dem 04.08.2021 – 11:00 Uhr.
• Zeitzone am Server: Mitteleuropäische Zeit (CET, bzw. UTC+2)
• Exchange arbeitet intern mit der UTC Zeitzone, somit ist das ausgestellte Zertifikat noch nicht gültig – sondern erst in 2 Stunden.

Man hat daher zwei Möglichkeiten:

• Variante 1: Man wartet die entsprechende Zeitverschiebung ab (in dem Beispiel 2h) und führt anschließend erneut einen „iisreset /restart“ aus.
• Variante 2: Man stellt temporär die Zeitzone am Exchange auf UTC, stellt das Zertifikat aus und ändert sie wieder auf die passende Zone zurück.

Somit sollte die Funktionalität wiederhergestellt und eure Nutzer glücklich sein.