Man kann mit dem Intune Certificate Connector über Intune SCEP Zertifikate an die Geräte ausgeben, um diese anschließend zur Authentifizierung bei WLAN oder VPN zu verwenden. Alle Geräte von Windows bis macOS konnten SCEP Zertifikate empfangen, nur die Android Geräte liefen in einen nicht definierten Error in Intune.

Grundaufbau der SCEP Profile

Nach dem ich Stunden lang gesucht und recherchiert habe, hier eine mögliche Lösung, warum alle Geräte außer aktuelle Android Geräte (ab Version 10) kein Zertifikat bekommen. Dies setzt also eine prinzipiell funktionierende SCEP Ausgabe voraus.

Lösung

Es könnte an der Auswahl des falschen Stammzertifikats liegen.
In meiner Arbeitsumgebung benutzen wir eine Root-CA und eine Sub-CA, welche dann natürlich die Zertifikate für alle Clients und Server ausstellt.

Wenn man nun das SCEP-Zertifikatsprofil in Intune erstellt, muss man auch ein Stammzertifikat hinterlegen.
Bei Windows Geräten reicht normalerweise nur das Stammzertifikat der Sub-CA auf die Geräte zu laden und entsprechend auszuwählen. Ich hatte dann irgendwann das Root-CA-Zertifikat auch nochmal auf die Geräte geschoben, damit die Vertrauenskette komplett ist.
Bei iOS und macOS MUSS ebenfalls das Root-CA-Stammzertifikat hochgeladen werden, damit die Kette voll vertrauenswürdig ist. Im SCEP Profil wird allerdings das Sub-CA-Stammzertifikat ausgewählt.

Bei Android habe ich ebenfalls Root und Sub-CA-Stammzertifikate auf die Geräte geladen, weil warum dann eine Ausnahme machen? Für Android-Geräte MUSS allerdings das Root-CA-Stammzertifikat im Profil hinterlegt werden. Fragt mich nicht warum.

Die Recherche

Zunächst habe ich die FAQs von Microsoft durchgeschaut. Diese sind, wie häufig in letzter Zeit, teilweise für Software welche bereits abgelöst wurde. Hier ist meistens von den Logs des alten Connectors die Rede. Der Aktuelle gibt allerdings alle Meldungen in die Ereignisanzeige unter “Anwendungs- und Dienstprotokolle/Microsoft/Intune/CertificateConnectors” aus. Dort war aber kein Fehler zu erkennen.

Unter "C:\inetpub\logs\LogFiles\W3SVC1" kann man die Logfiles des IIS durchsuchen. Dort sah ich dann auch, dass die Verbindung zum Webserver ohne weitere Fehler aufgebaut wurde.

2024-05-29 04:38:23 192.168.1.55 GET /certsrv/mscep/mscep.dll operation=GetCACaps&message=ca 443 - 192.168.1.185 Dalvik/2.1.0+(Linux;+U;+Android+12;+CT45+Build/312.00.03-G) - 200 0 0 53

2024-05-29 04:38:23 192.168.1.55 GET /certsrv/mscep/mscep.dll operation=GetCACaps&message=ca 443 - 192.168.1.185 Dalvik/2.1.0+(Linux;+U;+Android+12;+CT45+Build/312.00.03-G) - 200 0 0 11

2024-05-29 04:38:23 192.168.1.55 GET /certsrv/mscep/mscep.dll operation=GetCACert&message=ca 443 - 192.168.1.185 Dalvik/2.1.0+(Linux;+U;+Android+12;+CT45+Build/312.00.03-G) - 200 0 0 17

Das hilft nicht unbedingt, das heißt aber auch, dass irgendwas während der Weiterleitung zur Sub-CA oder dem Connector nicht in Ordnung ist. Kann aber auch nicht sein, da die anderen Geräte ihre Zertifikate ausgestellt bekommen. Das Konstrukt funktioniert also prinzipiell. Es muss also was am Android Gerät liegen.

Der nächste Blick ging dann auf die Anfrage vom iOS Gerät. Die sieht leicht anders aus:

2024-05-16 13:14:33 192.168.1.55 GET /certsrv/mscep/mscep.dll operation=GetCACert&message=SCEP%20Authority 443 - 192.168.1.128 profiled/1.0+CFNetwork/1492.0.1+Darwin/23.3.0 - 200 0 0 14

2024-05-16 13:14:33 192.168.1.55 GET /certsrv/mscep/mscep.dll operation=GetCACaps&message=SCEP%20Authority 443 - 192.168.1.128 profiled/1.0+CFNetwork/1492.0.1+Darwin/23.3.0 - 200 0 0 25

2024-05-16 13:14:33 192.168.1.55 POST /certsrv/mscep/mscep.dll operation=PKIOperation 443 - 192.168.1.128 profiled/1.0+CFNetwork/1492.0.1+Darwin/23.3.0 - 200 0 0 555

PKIOperation kam beim Android als Abfrage auch nicht vor.

Also weitergesucht, im SCEP Profil mehrere Male den Antragstellernamen geändert, da das bei Windows mal ein Problem darstellte, und versucht etwas sinnvolles aus den Wirren des Internets zu filtern. Sogar noch einen neuen Server mit NDES und Certificate Connector installiert. Selbes Spiel in grün, Android bekommt kein Zertifikat.

Es hat Stunden gedauert, bis ich einen Hinweis in den Untiefen von Reddit gefunden hatte:
https://www.reddit.com/r/Intune/comments/u2ggow/comment/ihv95hb/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Allerdings nahm ich den noch nicht ganz für voll, weil macht ja eigentlich kein Sinn. Wenn dann müsste das Gerät doch gegen die Sub-CA verifizieren.

Währenddessen hatte ich auch über die Intune App auf dem Android Gerät das ausführliche Logging aktiviert und habe mir die Log-Dateien auf ein USB-Stick gespeichert und nach SCEP Einträgen gesucht. Aufgefallen ist dann folgender Eintrag:

2024-05-28T11:44:15.6360000	WARN	com.microsoft.intune.usercerts.workcomponent.scep.abstraction.ScepStateMachine	30757	 3176	Failed to acquire SCEP cert
	
org.jscep.client.ClientException: CA certificate fingerprint could not be verified.
		at org.jscep.client.Client.verifyCA(:755)
		at org.jscep.client.Client.getCaCertificate(:283)
		at org.jscep.client.Client.getEncoder(:702)
		at org.jscep.client.Client.enrol(:621)
		at 
com.microsoft.intune.usercerts.apicomponent.scep.implementation.JscepScepClient$enrollScepCertificate$1$1.invoke(:136)
		at 
com.microsoft.intune.usercerts.apicomponent.scep.implementation.JscepScepClient$enrollScepCertificate$1$1.invoke(:130)
		at 
usw.

Später stieß ich dann noch auf folgende Lösung im Zusammenhang mit diesem Fehler:
“CA certificate fingerprint could not be verified. ” when trying to initiate the process to enroll SCEP certificate on Android and Intune – Stack Overflow

Nun dachte ich also: “Fuck it, ich setze jetzt im Profil das Stammzertifikat auf die Root-CA.”
Tja was soll ich sagen, am nächsten Morgen ins Büro gekommen und Grün im Intune und VPN läuft. Ich sage nicht, wie sehr ich gerne etwas aus dem Fenster hätte schmeißen wollen…