# Häufige 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](/de/scepman-konfiguration/application-artifacts.md#change-artifacts)). Die URL ** 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. ![](/files/f04ec4b7fe57c7cc9c134d92fb2b0652a467456e) ### 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 ](/de/scepman-konfiguration/application-settings/basics.md#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 nachdem Artefakte über drei Jahre lang an den neuen Speicherort verschoben wurden . 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](/de/scepman-konfiguration/application-artifacts.md) auf den neuen Paket-Speicherort. Dadurch wird auch Ihre SCEPman-Version von 1.8 auf die neueste Version aktualisiert und [viele Verbesserungen](/de/changelog.md) 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:

SCEPman verwendet den alten Paket-Speicherort für WEBSITE_RUN_FROM_PACKAGE

## 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: 1. Öffnen Sie die Windows-Ereignisanwendung 2. Klicken Sie auf **Anwendungs- und Dienstprotokolle** 3. Klicken Sie als Nächstes auf **Microsoft** 4. Dann klicken Sie auf **Windows** 5. Scrollen Sie nach unten und suchen Sie nach **DeviceManagement-Enterprise-Diagnostics-Provider** und klicken Sie darauf. 6. Im nun erscheinenden Fenster klicken Sie auf **Admin** 7. Scrollen Sie durch die Liste und suchen Sie nach Ereignis-ID **32** 8. Es enthält einen kurzen Fehlerbericht * SCEP: Zertifikatregistrierung fehlgeschlagen. Ergebnis (Der Hashwert ist nicht korrekt.). ![](/files/4fb3a9cdb3b454e8952080df84170723d2808723) Wenn Sie eine Zwischen-CA verwenden, beachten Sie, dass Sie das [Zwischen-CA-Zertifikat auswählen](/de/scepman-bereitstellung/intermediate-certificate.md#intermediate-cas-and-intune-scep-profiles) 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 {% hint style="info" %} Dies ist nur vor Version 1.2 ein Problem {% endhint %} Wenn das Gerätezertifikat für den OCSP-Eintrag eine localhost-URL wie diese hat: ![](/files/db953f0f563c29766fc69baafaa83a274a642aaf) 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: ``` AppConfig:BaseUrl https://scepman-XXXXX.azurewebsites.net ``` 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: ![](/files/77c213ed9b12c69f23dcebcfd658e6d72eb99e4d) ### 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](https://oliverkieselbach.com/2022/09/21/deep-dive-of-scep-certificate-request-renewal-on-intune-managed-windows-clients/) 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: {% code overflow="wrap" fullWidth="false" %} ``` TimeCreated : 7/2/2025 12:51:06 PM ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider Id : 32 Message : SCEP: Zertifikatsregistrierung fehlgeschlagen. Ergebnis: (Unbekannter Win32-Fehlercode: 0x80072f8f). TimeCreated : 7/2/2025 12:51:06 PM ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider Id : 307 Message : SCEP: Failed LogError Message : (SCEPInstallCertificateWithScepHelper:Failed to Initialize SCEP-Registrierung mit NDES-Server 'https://scepman.contoso.com/certsrv/mscep/mscep.dll/pkiclient.exe', CA-Zertifikats-Fingerabdruck '24C45EF4284A5093A9C3886A6466C1D6D84EE058' und Serverzertifikate ''. LogError 0x80) ``` {% endcode %} ### 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**](/de/scepman-konfiguration/application-settings/certificates.md#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](#windows-10-devices-cannot-enroll-with-autopilot). ## 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: ``` certutil -verifyStore MY ``` 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). ![](/files/21c3ebf97faeaacc3e9165ae394da0e58fc0662d) Um zu überprüfen, ob der OCSP-Responder funktioniert, können Sie den OCSP-URL-Cache mit dem folgenden Befehl ansehen: ``` certutil -urlcache OCSP ``` ![](/files/01914b7510354de0fcca57e1fcaff75d168fb92d) #### macOS-Rechner Um die Gültigkeit eines Zertifikats auf einem macOS-Rechner mithilfe von OCSP zu prüfen, befolgen Sie bitte diese Schritte: 1. 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). 2. 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. 3. Extrahieren Sie die OCSP-Responder-URL aus der **Authority Information Access** (AIA)-Eigenschaft des Client-Authentifizierungszertifikats:
4. Öffnen Sie eine **Terminal** Sitzung und `cd` zu dem Ordner, der die exportierten Zertifikate enthält. 5. Führen Sie den folgenden Befehl aus: ``` openssl ocsp -issuer -cert -text -url ``` 6. 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: ``` certutil -url ``` ![](/files/009535bece41d3fd8cdda1b663f19135ead6d4da) ### Einen Benutzer widerrufen Wenn Sie ein **Benutzer** zertifikat widerrufen möchten, haben Sie zwei Möglichkeiten: 1. Den Benutzer aus Microsoft Entra ID (Azure AD) löschen oder 2. Die Anmeldung für den Benutzer blockieren Wenn Sie ein **Geräte** zertifikat, haben Sie mehrere Möglichkeiten, je nach [Intune-Validierung](/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-devicedirectory): 1. Microsoft Entra ID (Azure AD): Das Gerät löschen oder deaktivieren ([Microsoft Entra ID (Azure AD) Portal](https://aad.portal.azure.com/): „Geräte“ - „Alle Geräte“). 2. **Intune**: Das Gerät löschen oder eine Remote-Aktion auslösen (mehrere Verwaltungszustände wie „WipePending“ widerrufen Zertifikate automatisch, wie unter [Intune-Validierung](/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-revokecertificatesonwipe)). 3. **Beide Verzeichnisse**: Aktionen für Microsoft Entra ID (Azure AD) ausführen **und** Intune wie beschrieben. {% hint style="info" %} Weitere Informationen zu Geräteverzeichnissen finden Sie im Artikel [Geräteverzeichnisse](/de/scepman-konfiguration/device-directories.md). {% endhint %} Das folgende Beispiel widerruft ein Gerätezertifikat über Microsoft Entra ID (Azure AD): 1. Navigieren Sie zu **Geräte - Alle Geräte** in Ihrem Microsoft Entra ID (Azure AD) 2. Wählen Sie ein Gerät aus 3. Klicken Sie auf **Deaktivieren** Geben Sie dann den folgenden Befehl erneut ein: ``` certutil -verifyStore MY ``` Wie Sie in der letzten Zeile sehen können, ist das **Zertifikat WIDERRUFEN** ![](/files/b3fd403a49210bc7cae450ea2de27eca269f4c36) 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. {% hint style="info" %} Es kann bis zu 5 Minuten dauern, bis die Meldung „Als gültig markiert“ erscheint. {% endhint %} ### 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: ![](/files/4bc899dac1a02351b3485237117ebe1dd9fdb8f8) *Lösung*: Bitte siehe [hier](/de/sonstiges/troubleshooting/cisco-ise-host-header-limitation.md). ### 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ät`verwenden, 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](https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/DevicesAndroidMenu/androidEnrollment) 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](https://docs.microsoft.com/en-us/mem/intune/enrollment/android-kiosk-enroll) 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](/de/scepman-bereitstellung/permissions/post-installation-config.md#running-the-scepman-installation-cmdlet). ## SCEPman stellt keine Zertifikate mit anderen EKUs als Client Authentication aus Prüfen Sie Ihre SCEPman-Umgebungsvariablen, um zu sehen, was für [AppConfig:UseRequestedKeyUsages](/de/scepman-konfiguration/application-settings/certificates.md#appconfig-userequestedkeyusages)konfiguriert 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.
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.scepman.com/de/sonstiges/troubleshooting/general.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.