Monat: Februar 2018

Um die zertifikatsbasierte Authentifizierung des Exchange 2016 zu aktivieren empfehle ich, sich an folgenden Technet-Artikel zu halten. Dieser beschreibt die Konfiguration schritt für schritt.
Der anschließende Test war jedoch wenig erfolgreich und brachte auf den Client Geräten immer den Fehler „Anmeldung fehlgeschlagen“. Die Analyse des IIS Logfiles bestätigte in dem Fall die Fehlermeldung:

2018-01-17 14:14:41 W3SVC1 MSEXCHSRV 10.0.1.212 OPTIONS /Microsoft-Server-ActiveSync/default.eas Cmd=OPTIONS&User=domain%5CUser.Name&DeviceId=SEC15BF1D9F90A8E&DeviceType=SamsungDevice 443 - 10.0.0.213 HTTP/1.1 Android-SAMSUNG-SM-G955F/101.700 - - oma.fqdn.net 403 16 2148204809 184 375 452
2018-02-22 08:24:54 W3SVC3 EXCHANGESRV 10.0.1.212 GET / - 9943 - 10.0.0.5 HTTP/1.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/63.0.3239.132+Safari/537.36 - - exchangesrv.fqdn.info:9943 403 16 2148204809 1423 434 4230

Da der Microsoft Exchange Health Manager (+ Recovery) durchgängig Testaufrufe machen, wird das IIS Logfile schnell unübersichtlich gefüllt. Daher hatte ich einfach eine neue Site im IIS Manager erstellt und dort unter einem anderem Port Binding die Authentifizierung via Client Zertifikate getestet. (Unterer Logeintrag) Man kann aber auch den Health Manager Dienst temporär deaktivieren, dass funktioniert auch.
Zurück zur Fehlermeldung, welche im Detail wie folgt aussieht:

403 16 2148204809

• 403 = HTTP Statuscode (Authentication Failed)
• 16 = Subfehler (Client certificate is untrusted or invalid.)
• 2148204809 = Detaillierter Fehlercode (0x800b0109 CERT_E_UNTRUSTEDROOT)

Sucht man nach der Fehlermeldung findet man folgenden Technet-Artikel, der eigentlich auf den IIS 8 bezogen ist. Windows Server verwendet IIS 10 – aber der Artikel trifft auch darauf zu.
Hintergrund: Seit Windows Server 2012 wurden strengere Überprüfungen für die zertifikatsbasierte Authentifizierung eingeführt. Einer dieser Checks prüft ob sich im Zertifikatsspeicher (Trusted Root Certification Authorities) auch wirklich nur sogenannte Root-Zertifikate befinden. Ein Root Zertifikat muss logischerweise immer selbst-signiert sein. Wenn sich dort ein Zertifikat befindet, was von einer anderen Zertifikatstelle ausgestellt wurde, ist dies eigentlich ein „Zwischenzertifikat / Intermediate“ und gehört an einen anderen Zertifikatsspeicherort.
In meinem Fall befand sich das „StartCom Class 3 OV Server CA“ in den Root-CA’s welches den Fehler produzierte. Um den Fehler zu beheben, müssen alle nicht selbst-signierten Zertifikate aus dem Root-CA entfernt bzw. zu den Zwischenzerifikaten verschoben werden.
Um bei der Vielzahl von Zertifikaten nicht alle händisch zu überprüfen kann man dies per Powershell identifizieren:

Get-Childitem cert:\LocalMachine\root -Recurse |
    Where-Object {$_.Issuer -ne $_.Subject}

Um die Zertifikate anschließend in den Speicher für „Intermediate Certification Authorities“ zu verschieben kann man folgenden Befehl nutzen:

Get-Childitem cert:\LocalMachine\root -Recurse |
    Where-Object {$_.Issuer -ne $_.Subject} |
    Move-Item -Destination Cert:\LocalMachine\CA

Anschließend den kompletten Server neustarten. Eventuell reicht auch nur ein Neustart des IIS (W3SVC). Hatte in meinem Fall jedoch nicht ausgereicht.