Häufigen Probleme
Probleme beim Starten von SCEPman
Ich habe SCEPman von GitHub bereitgestellt und es funktionierte, aber jetzt startet die Web App nicht mehr
Wenn der Fehler „503 Kann ZIP nicht herunterladen“ lautet, dann kann die Web App die ZIP mit den Anwendungs-Binärdateien nicht von der in der App-Einstellung WEBSITE_RUN_FROM_PACKAGE konfigurierten URL herunterladen (siehe Anwendungskonfiguration).
Die URL https://github.com/glueckkanja/gk-scepman/raw/master/dist/Artifacts.zip die wir für GitHub-Bereitstellungen in früheren Versionen dieser Dokumentation empfohlen hatten, leitet auf eine andere URL um. Microsoft hat das Verhalten einiger ihrer Web Apps geändert, und nun unterstützen einige Versionen Umleitungen zusammen mit WEBSITE_RUN_FROM_PACKAGE nicht. Daher müssen Sie die URL ändern in https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip.
SCEPman Azure Web App wird nicht ausgeführt
Prüfen Sie, ob die Azure-Ressource läuft und aktiv ist.
Meine App Service verwendet die falsche .NET-Version
In der App-Service-Ressource von SCEPman oder Certificate Master können Sie unter Einstellungen -> Konfiguration -> Allgemeine Einstellungen -> Stack-Einstellungen prüfen, welcher Stack und welche Version für diesen App Service konfiguriert ist. Obwohl der Stack .NET ist, stimmt die .NET-Version möglicherweise nicht mit dem überein, was Sie für Ihre SCEPman-Version erwarten, z. B. .NET 8 für SCEPman 2.8.
Das liegt daran, dass einige gängige .NET-Versionen automatisch auf allen Windows App Services verfügbar sind, unabhängig davon, welche .NET-Version Sie in den Einstellungen auswählen. Wir heben SCEPman nur dann auf eine neue .NET-Version an, wenn diese Version in dieser Menge automatisch installierter .NET-Versionen enthalten ist. Das tun wir, weil unser Aktualisierungsmechanismus über WEBSITE_RUN_FROM_PACKAGE uns keine Kontrolle über die Einstellung der .NET-Version gibt. Daher ist es tatsächlich egal, was als .NET-Version konfiguriert ist.
Mein SCEPman App Service funktionierte am 27.11.2024 nicht und seit dem 16.12.2024 funktioniert er überhaupt nicht mehr, nachdem er viele Jahre lang ohne Probleme funktioniert hatte
Wir schalten das veraltete SCEPman-Artefakt-Repository ab https://github.com/glueckkanja/gk-scepman nachdem Artefakte über drei Jahre lang an den neuen Speicherort verschoben wurden https://github.com/scepman/install. Am Mittwoch, dem 27.11.2024, haben wir den alten Speicherort vorübergehend deaktiviert, um die Benutzer auf die endgültige Abschaltung am Montag, dem 16.12.2024, aufmerksam zu machen.
Wenn Sie betroffen sind, prüfen Sie Ihre WEBSITE_RUN_FROM_PACKAGE-Einstellung und aktualisieren Sie den Wert auf den neuen Paket-Speicherort. Dadurch wird auch Ihre SCEPman-Version von 1.8 auf die neueste Version aktualisiert und viele Verbesserungen mit vollständiger Abwärtskompatibilität bereitgestellt.
Wenn Sie nicht sicher sind, ob Sie das neueste Repository verwenden, besuchen Sie die Startseite von SCEPman. Wenn sie noch auf das alte Repository konfiguriert ist, wird eine Warnung angezeigt (und das bereits seit drei Jahren), die so aussieht:
Probleme beim Ausstellen von Zertifikaten
Vertrauenswürdiges Stammzertifikat ist bereitgestellt, aber mein Gerätezertifikat über das SCEP-Profil führt zu einem Fehler
Das SCEP-Profil führt zu einem Fehler, wenn die Zertifikatsbereitstellung nicht erfolgreich war. Fehler können mehrere Ursachen haben:
SCEP-Zertifikatprofil ist mit einem Fehler konfiguriert
Dies kann passieren, wenn im SCEP-Zertifikatprofil das falsche vertrauenswürdige Stammzertifikat ausgewählt wurde. Dies wird auch im Ereignisprotokoll angezeigt:
Öffnen Sie die Windows-Ereignisanwendung
Klicken Sie auf Anwendungs- und Dienstprotokolle
Klicken Sie als Nächstes auf Microsoft
Dann klicken Sie auf Windows
Scrollen Sie nach unten und suchen Sie nach DeviceManagement-Enterprise-Diagnostics-Provider und klicken Sie darauf.
Im nun erscheinenden Fenster klicken Sie auf Admin
Scrollen Sie durch die Liste und suchen Sie nach Ereignis-ID 32
Es enthält einen kurzen Fehlerbericht
SCEP: Zertifikatregistrierung fehlgeschlagen. Ergebnis (Der Hashwert ist nicht korrekt.).
Wenn Sie eine Zwischen-CA verwenden, beachten Sie, dass Sie das Zwischen-CA-Zertifikat auswählen und nicht das Root-CA-Zertifikat im SCEP-Konfigurationsprofil! Beachten Sie, dass dies spezifisch für die Windows-Plattform ist und beispielsweise Android die Auswahl des Root-CA-Zertifikats im SCEP-Konfigurationsprofil erfordert.
Mein Zertifikat hat nicht den korrekten OCSP-URL-Eintrag
Dies ist nur vor Version 1.2 ein Problem
Wenn das Gerätezertifikat für den OCSP-Eintrag eine localhost-URL wie diese hat:
Dem App Service fehlt eine wichtige Anwendungseinstellung mit dem Namen AppConfig:BaseUrl auf die azurewebsite-URL gesetzt. Um das zu beheben, fügen Sie die Variable hinzu und speichern Sie die App-Service-Konfiguration:
Löschen Sie dieses Zertifikat vom Gerät und führen Sie den MDM-Sync durch. Wenn Sie das getan haben, sehen Sie eine korrekte URL für den OCSP-Eintrag:
Mein SCEP-Konfigurationsprofil zeigt ausstehend an und wird nicht angewendet
Das SCEP-Konfigurationsprofil hängt vom Profil des vertrauenswürdigen Stammzertifikats ab. Weisen Sie beide Profile derselben Azure Active Directory-Benutzer- oder Gerätegruppe zu, um sicherzustellen, dass sich Benutzer oder Gerät überschneiden und beide Profile auf das Gerät ausgerichtet sind. Mischen Sie keine Benutzer- und Gerätegruppen. Wenn der Status der Konfigurationsprofile in Intune über längere Zeit ausstehend ist, ist die Zuweisung wahrscheinlich falsch.
Einige Windows-Computer registrieren oder erneuern Zertifikate nicht
Sie können dies sowohl auf der SCEPman-Seite als auch auf der Client-Seite prüfen. Je nach Problem, das Sie oft vorher nicht kennen, wird die Ursache nur auf einer der beiden Seiten angezeigt.
Prüfen Sie, ob es irgendeinen [ERROR] Eintrag in den SCEPman-Protokollen gibt. Suchen Sie möglicherweise auch nach dem Suchbegriff [WARN, aber das kann einige Fehlalarme liefern.
Oliver Kieselbach und Christoph Hannebauer haben einen Blogartikel über die Analyse von Problemen bei Zertifikatsanforderung oder -erneuerung geschrieben der Ihnen hilft, Registrierungsprobleme auf der Client-Seite aufzuspüren.
Der Windows-SCEP-Client unterstützt TLS nur bis Version 1.2. Das Setzen der minimalen eingehenden TLS-Version auf 1.3 im SCEPman App Service führt zu bestimmten Fehleinträgen im DeviceManagement-Enterprise-Diagnostics-Provider Ereignisprotokoll. Hier ist ein Beispiel von einem Windows-11-Gerät:
Windows-10-Geräte können sich nicht mit AutoPilot registrieren
Derzeit haben einige Windows-10-Geräte während der OOBE-Erfahrung nicht die korrekte Uhrzeit. Das ist nicht leicht zu erkennen, da der Bildschirm keine Uhr anzeigt. Dies führt bei neu ausgestellten Zertifikaten zu einem Problem, da sie noch nicht gültig sind. Windows verwirft diese „ungültigen“ Zertifikate dann und zeigt einen Fehler an. Zertifikate werden standardmäßig 10 Minuten in die Vergangenheit datiert, um kleinere Uhrprobleme auszugleichen, aber wir haben kürzlich Windows-10-Geräte gesehen, die bis zu 9 Stunden nachgehen.
Sie können mit der Registrierung fortfahren und sobald dies abgeschlossen ist, erhält das Gerät erfolgreich ein Zertifikat, da die Uhr dann korrekt ist. Sie können auch die neue Option verwenden AppConfig:ValidityClockSkewMinutes um Zertifikate um mehr als 10 Minuten rückzudatieren. Verwenden Sie 1440 Minuten, um die Zertifikate um einen ganzen Tag rückzudatieren. Dies wird die Standardvorgabe für neue SCEPman-Installationen sein, um dieses Problem zu beheben.
Ich habe heute ein Zertifikat ausgestellt, aber im Ausstellungsdatum steht, es sei gestern ausgestellt worden
Das liegt daran, dass SCEPman Zertifikate um einen Tag rückdatiert, um Probleme mit Geräten mit nachgehender Uhr entgegenzuwirken, siehe Windows-10-Geräte können sich nicht mit AutoPilot registrieren.
Probleme mit der Gültigkeit von Zertifikaten
Lokales Zertifikat prüfen
Windows-Rechner
Zuerst müssen Sie die Gültigkeit des Gerätezertifikats prüfen. Öffnen Sie dazu eine Eingabeaufforderung als Administrator und geben Sie den folgenden Befehl ein:
Sehen Sie sich das Zertifikat mit der Geräte-ID an, das von der SCEPman-Device-Root-CA-V1 ausgestellt wurde, und prüfen Sie, ob das Zertifikat gültig ist (siehe letzte Zeile).
Um zu überprüfen, ob der OCSP-Responder funktioniert, können Sie den OCSP-URL-Cache mit dem folgenden Befehl ansehen:
macOS-Rechner
Um die Gültigkeit eines Zertifikats auf einem macOS-Rechner mithilfe von OCSP zu prüfen, befolgen Sie bitte diese Schritte:
Exportieren Sie das SCEPman-Root-CA-Zertifikat aus Schlüsselbundverwaltung (Systemschlüsselbunde > System-Roots) als *.cer-Datei und legen Sie sie in einem Ordner ab (alternativ können Sie sie von der Website Ihrer SCEPman-Instanz herunterladen).
Exportieren Sie das Client-Authentifizierungszertifikat, das Sie überprüfen möchten, aus Schlüsselbundverwaltung (Systemschlüsselbunde > System > Meine Zertifikate) als *.cer-Datei in denselben Ordner.
Extrahieren Sie die OCSP-Responder-URL aus der Authority Information Access (AIA)-Eigenschaft des Client-Authentifizierungszertifikats:
Öffnen Sie eine Terminal Sitzung und
cdzu dem Ordner, der die exportierten Zertifikate enthält.Führen Sie den folgenden Befehl aus:
Gegen Ende der Antwort wird der Widerrufsstatus angezeigt:\
Zertifikate von anderen Rechnern prüfen
Alternativ können Sie das Gerätezertifikat exportieren und certutil auf einem Windows-Rechner verwenden, um eine kleine certutil-Oberfläche für die OCSP-Prüfung anzuzeigen:
Einen Benutzer widerrufen
Wenn Sie ein Benutzer zertifikat widerrufen möchten, haben Sie zwei Möglichkeiten:
Den Benutzer aus Microsoft Entra ID (Azure AD) löschen oder
Die Anmeldung für den Benutzer blockieren
Wenn Sie ein Geräte zertifikat, haben Sie mehrere Möglichkeiten, je nach AppConfig:IntuneValidation:DeviceDirectory:
Microsoft Entra ID (Azure AD): Das Gerät löschen oder deaktivieren (Microsoft Entra ID (Azure AD) Portal: „Geräte“ - „Alle Geräte“).
Intune: Das Gerät löschen oder eine Remote-Aktion auslösen (mehrere Verwaltungszustände wie „WipePending“ widerrufen Zertifikate automatisch, wie unter AppConfig:IntuneValidation:RevokeCertificatesOnWipe).
Beide Verzeichnisse: Aktionen für Microsoft Entra ID (Azure AD) ausführen und Intune wie beschrieben.
Weitere Informationen zu Geräteverzeichnissen finden Sie im Artikel Geräteverzeichnisse.
Das folgende Beispiel widerruft ein Gerätezertifikat über Microsoft Entra ID (Azure AD):
Navigieren Sie zu Geräte - Alle Geräte in Ihrem Microsoft Entra ID (Azure AD)
Wählen Sie ein Gerät aus
Klicken Sie auf Deaktivieren
Geben Sie dann den folgenden Befehl erneut ein:
Wie Sie in der letzten Zeile sehen können, ist das Zertifikat WIDERRUFEN
Wenn Sie das Gerät in Microsoft Entra ID (Azure AD) erneut aktivieren und den obigen Befehl erneut eingeben, sollte das Zertifikat als gültig markiert werden.
Es kann bis zu 5 Minuten dauern, bis die Meldung „Als gültig markiert“ erscheint.
Access Point kann ein von SCEPman ausgestelltes Authentifizierungszertifikat nicht verifizieren
Symptome: Cisco ISE zeigt einen OCSP-Unerreichbar-Fehler. Aruba ClearPass hat dieses Problem ebenfalls. Der Server, offenbar SCEPman, antwortet mit einem TCP-Reset-Paket auf die OCSP-Anfrage.
Ursache: Sowohl Cisco ISE als auch Aruba ClearPass unterstützen HTTP 1.1 nicht beim Nachschlagen von OCSP und senden in ihrer OCSP-Anfrage keinen Host-Header. Daher können sie sich nicht mit einer allgemeinen SCEPman-Instanz verbinden, die auf Azure App Services läuft. Die Fehlermeldung kann etwa so aussehen:
Lösung: Bitte siehe hier.
Gerätezertifikate auf meinen Android-(dedizierten) Systemen sind nicht gültig
Auf Android-(dedizierten) Systemen trägt Intune oder Android in manchen Fällen versehentlich die Intune-Geräte-ID statt der AAD-Geräte-ID in das Zertifikat ein, obwohl Sie die Variable im SCEP-Konfigurationsprofil konfigurieren. SCEPman kann dann kein Gerät mit dieser ID in AAD finden und betrachtet das Zertifikat daher als widerrufen.
Dies passiert nur, wenn Sie für die Registrierungsmethode von unternehmenseigenen dedizierten Geräten den Microsoft Entra ID (Azure AD)-Shared-Mode anstelle des Standardmodus verwenden. Wenn Sie für Tokentypen den Standardmodus Unternehmenseigenes dediziertes Gerätverwenden, sind Sie von dem Problem nicht betroffen. Intune trägt zwar weiterhin die Intune-Geräte-ID statt der AAD-Geräte-ID in das Zertifikat ein, aber im Standardmodus sind beide identisch, also spielt das keine Rolle. Um den Registrierungsmodus zu ändern, gehen Sie zu den Android-Registrierungseinstellungen des Microsoft Endpoint Manager Admin Centers und wählen Sie Unternehmenseigenes dediziertes Gerät (Standard) anstatt Unternehmenseigenes dediziertes Gerät mit Azure AD Shared Mode. Bitte beachten Sie die Microsoft-Dokumentation zu den Auswirkungen dieser Auswahl.
Wir arbeiten derzeit mit Microsoft daran, dieses Problem in allen Konfigurationen zu lösen. Bitte kontaktieren Sie unseren Support, wenn Sie ebenfalls betroffen sind.
Mein Storage Account sagt, dass er nicht verbunden ist
Wenn auf Ihrer SCEPman-Startseite ein rotes Tag „Nicht verbunden“ für die Storage-Account-Verbindung angezeigt wird, fehlen möglicherweise der Managed Identity des SCEPman App Service (und möglicherweise auch der von SCEPman Certificate Master) Berechtigungen für den Storage Account. In diesem Fall kann SCEPman nicht prüfen, ob ein Zertifikat manuell widerrufen wurde, und kann daher nicht auf OCSP-Anfragen antworten. Das passiert normalerweise, wenn Sie den Storage Account in ein anderes Abonnement oder eine andere Ressourcengruppe verschieben. Es kann auch nach einem Upgrade von einer Community-Edition-Version auf Enterprise Edition vorkommen -- in diesem Fall bestand das Berechtigungsproblem bereits vorher, wurde aber von der Community Edition nicht geprüft.
Um dies zu beheben, müssen Sie der Managed Identity des SCEPman App Service und der von SCEPman Certificate Master die Rolle „Storage Table Data Contributor“ auf dem Storage Account zuweisen. Die Rollenzuweisungen können manuell im Azure-Portal unter „Zugriffskontrolle (IAM)“ im Storage Account vorgenommen werden. Alternativ führen Sie einfach das SCEPman-Installations-CMDlet aus dem SCEPman-PowerShell-Modul erneut aus.
SCEPman stellt keine Zertifikate mit anderen EKUs als Client Authentication aus
Prüfen Sie Ihre SCEPman-Umgebungsvariablen, um zu sehen, was für AppConfig:UseRequestedKeyUsageskonfiguriert ist. Wenn es nicht gesetzt ist, ist der Standardwert „false“.
Neue Installationen setzen dies automatisch auf „true“, ältere SCEPman-Installationen haben dies jedoch auf false gesetzt. SCEPman-Updates ändern keinerlei Verhalten außer bei Fehlerbehebungen oder Änderungen, die unter keinen Umständen einen Nachteil haben. Wenn dies auf false gesetzt ist, werden die angeforderten EKUs und Key Usages ignoriert.
Zuletzt aktualisiert
War das hilfreich?