> For the complete documentation index, see [llms.txt](https://docs.scepman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scepman.com/de/andere/troubleshooting/general.md).

# Häufige Probleme

## Probleme beim Starten von SCEPman

### Ich habe SCEPman von GitHub bereitgestellt und es hat früher funktioniert, aber jetzt startet die Web-App nicht mehr

Wenn der Fehler '503 Cannot download ZIP' lautet, kann die Web-App das ZIP mit den Anwendungs-Binaries 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 *<https://github.com/glueckkanja/gk-scepman/raw/master/dist/Artifacts.zip>* die wir in früheren Versionen dieser Dokumentation für GitHub-Bereitstellungen empfohlen hatten, leitet auf eine andere URL um. Microsoft hat das Verhalten einiger ihrer Web-Apps geändert, und nun unterstützen einige Versionen Weiterleitungen 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.

![](https://2075553437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-fa1f838cc58fdfc0443c4d1e663643b3df01dd4e%2Fevent32_2%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(11\)%20\(2\).png?alt=media)

### 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 diesem Satz automatisch installierter .NET-Versionen enthalten ist. Wir tun dies, 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 spielt es eigentlich keine Rolle, was als .NET-Version konfiguriert ist.

### Mein SCEPman App Service funktionierte am 27.11.2024 nicht und funktioniert seit dem 16.12.2024 überhaupt nicht mehr, nachdem er viele Jahre lang ohne Probleme funktioniert hat

Wir schalten das veraltete SCEPman-Artefakte-Repository ab <https://github.com/glueckkanja/gk-scepman> nach über drei Jahren, in denen Artefakte 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 Benutzer auf die dauerhafte Abschaltung am Montag, dem 16.12.2024 aufmerksam zu machen.

Wenn Sie betroffen sind, überprü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 bietet [viele Verbesserungen](/de/changelog.md) mit vollständiger Abwärtskompatibilität.

Wenn Sie nicht sicher sind, ob Sie das neueste Repository verwenden, besuchen Sie die Startseite Ihres SCEPman. Wenn sie immer noch im alten Repository konfiguriert ist, zeigt sie eine Warnung an (und hat dies bereits in den letzten drei Jahren getan), die so aussieht:

<figure><img src="https://2075553437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FbX4ATqv8O0f3cXCdqwLy%2Fimage.png?alt=media&amp;token=b9ed1f6f-ce4f-4745-b30b-9b01c518997c" alt=""><figcaption><p>SCEPman verwendet den alten Paket-Speicherort für WEBSITE_RUN_FROM_PACKAGE</p></figcaption></figure>

## Probleme beim Ausstellen von Zertifikaten

### Trusted Root Certificate 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 kann mehrere Gründe haben:

### SCEP-Zertifikatsprofil ist fehlerhaft konfiguriert

Dies kann passieren, wenn im SCEP-Zertifikatsprofil ein falsches vertrauenswürdiges Stammzertifikat ausgewählt wurde. Dies wird auch im Ereignisprotokoll angezeigt:

1. Öffnen Sie die Windows-Ereignisanzeige
2. Klicken Sie auf **Anwendungs- und Dienstprotokolle**
3. Dann klicken Sie 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 erscheinenden Fenster klicken Sie auf **Admin**
7. Scrollen Sie durch die Liste und suchen Sie nach Ereignis-ID **32**
8. Er enthält einen kurzen Fehlerbericht
   * SCEP: Zertifikatregistrierung fehlgeschlagen. Ergebnis (Der Hashwert ist nicht korrekt.).

![](https://2075553437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-4e964c4cda9f70b7c0a4c24a293f0bf7133844c3%2Fevent32_1%20\(2\)%20\(3\)%20\(3\)%20\(3\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(11\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(12\).png?alt=media)

Wenn Sie eine Intermediate CA verwenden, beachten Sie, dass Sie [das Intermediate-CA-Zertifikat auswählen müssen](/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 Android beispielsweise das Auswählen des Root-CA-Zertifikats im SCEP-Konfigurationsprofil erfordert.

### Mein Zertifikat hat nicht den korrekten OCSP-URL-Eintrag

{% hint style="info" %}
Dies ist nur ein Problem vor Version 1.2
{% endhint %}

Wenn das Gerätezertifikat einen localhost-URL für den OCSP-Eintrag im Zertifikat hat, wie hier:

![](https://2075553437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-13206c885994d08c4ec6e5996ea261b2d3ee5912%2Fevent32_7%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(1\).png?alt=media)

Die App Service-Ressource fehlt eine wichtige Anwendungseinstellung mit dem Namen **AppConfig:BaseUrl** auf die azurewebsite-URL gesetzt. Um dies 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:

![](https://2075553437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-7729e8388eaa003c5561f926e7f26c54972fd5b2%2Fevent32_8%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\).png?alt=media)

### Mein SCEP-Konfigurationsprofil zeigt ausstehend an und wird nicht angewendet

Das SCEP-Konfigurationsprofil hängt vom Trusted Root-Zertifikatsprofil ab. Weisen Sie beide Profile derselben Benutzer- oder Gerätegruppe in Microsoft Entra ID (Azure AD) zu, um sicherzustellen, dass Benutzer oder Gerät übereinstimmen und beide Profile auf das Gerät ausgerichtet sind. Mischen Sie keine Benutzer- und Gerätegruppen. Wenn der Status der Konfigurationsprofile in Intune lange Zeit ausstehend ist, ist die Zuordnung wahrscheinlich falsch.

### Einige Windows-Computer registrieren oder erneuern keine Zertifikate

Sie können sowohl auf der SCEPman-Seite als auch auf der Client-Seite prüfen. Je nach Problem, das Ihnen oft im Voraus nicht bekannt ist, wird die Ursache nur auf einer der beiden Seiten angezeigt.

Prüfen Sie, ob es einen `[ERROR]` Eintrag in den SCEPman-Logs gibt. Suchen Sie möglicherweise auch nach dem Suchbegriff `[WARN`aber dies kann zu einigen Fehlalarmen führen.

Oliver Kieselbach und Christoph Hannebauer haben [einen Blogartikel über die Analyse von Problemen bei Zertifikatsanforderungen oder -erneuerungen 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 nur TLS 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-Rechner:

{% code overflow="wrap" fullWidth="false" %}

```
TimeCreated  : 7/2/2025 12:51:06 PM
ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
Id           : 32
Message      : SCEP: Zertifikatregistrierung 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: Fehler beim Protokollieren der Fehlermeldung : (SCEPInstallCertificateWithScepHelper:Fehler beim Initialisieren
               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 richtige Zeit. Das ist nicht leicht zu erkennen, da der Bildschirm keine Uhr anzeigt. Dies verursacht ein Problem mit neu ausgestellten Zertifikaten, 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 hinterherhinken.

Sie können die Registrierung fortsetzen, 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 zurückzudatieren. Verwenden Sie 1440 Minuten, um die Zertifikate um einen ganzen Tag zurückzudatieren. Dies wird die Standardeinstellung für neue SCEPman-Installationen sein, um dieses Problem zu beheben.

### Ich habe heute ein Zertifikat ausgestellt, aber das Ausstellungsdatum sagt, es war gestern

Das liegt daran, dass SCEPman Zertifikate um einen Tag zurückdatiert, um Probleme mit Geräten zu kompensieren, deren Uhr nachgeht; 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 überprü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 vom SCEPman-Device-Root-CA-V1 ausgestellt wurde, und prüfen Sie, ob das Zertifikat gültig ist (siehe letzte Zeile).

![](https://2075553437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-cb549f4e3708565d2455a9f459c2e54254ee26e8%2Fscepman_revocation1%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(1\).png?alt=media)

Um zu überprüfen, ob der OCSP-Responder funktioniert, können Sie den OCSP-URL-Cache mit dem folgenden Befehl ansehen:

```
certutil -urlcache OCSP
```

![](https://2075553437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-6c46d2b65ee1277d01b26b0f496975a577d35f21%2Fscepman_revocation2%20\(2\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(5\).png?alt=media)

#### macOS-Rechner

Um die Gültigkeit eines Zertifikats auf einem macOS-Rechner mithilfe von OCSP zu prüfen, folgen Sie bitte diesen Schritten:

1. Exportieren Sie das SCEPman-Root-CA-Zertifikat aus **Schlüsselbundverwaltung** (**System-Schlü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 Clientauthentifizierungszertifikat, das Sie überprüfen möchten, aus **Schlüsselbundverwaltung** (**System-Schlüsselbunde > System > Meine Zertifikate**) als \*.cer-Datei in denselben Ordner.
3. Extrahieren Sie die OCSP-Responder-URL aus der Eigenschaft **Authority Information Access** (AIA):

   <figure><img src="https://2075553437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FaJqT97xxEUx1py2f0xbT%2Fimage.png?alt=media&amp;token=3c0ca083-8cb9-471f-a7ab-4a314337b585" alt=""><figcaption></figcaption></figure>
4. Öffnen Sie eine **Terminal** Sitzung und `cd` Sie in den Ordner mit den exportierten Zertifikaten.
5. Führen Sie den folgenden Befehl aus:

```
openssl ocsp -issuer <Dateiname-scepman-root-ca-zertifikat> -cert <Dateiname-zertifikat-zur-Überprüfung> -text -url <ocsp-responder-url>
```

6. Gegen Ende der Antwort wird der Widerrufsstatus angezeigt:\\

   <figure><img src="https://2075553437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FRXQI4xRp0NRt5vBwDY89%2Fimage.png?alt=media&amp;token=ee8e2761-e249-4bd1-ae82-0eac933363d2" alt=""><figcaption></figcaption></figure>

### 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 <pfad-zum-exportierten-gerätezertifikat>
```

![](https://2075553437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-d3dffe20c2939eddc1ea08c0e4164440e9c7a3c3%2Fscepman_revocation4%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(5\).png?alt=media)

### Einen Benutzer widerrufen

Wenn Sie ein **Benutzer** Zertifikat widerrufen möchten, haben Sie zwei Optionen:‌

1. Löschen des Benutzers aus Microsoft Entra ID (Azure AD) oder
2. Anmeldung für den Benutzer blockieren

Wenn Sie ein **Geräte** Zertifikat, haben Sie mehrere Optionen, abhängig von [Intune-Validierung](/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-devicedirectory):

1. Microsoft Entra ID (Azure AD): Löschen oder Deaktivieren des Geräts ([Microsoft Entra ID (Azure AD)-Portal](https://aad.portal.azure.com/)": "Geräte" - "Alle Geräte").
2. **Intune**: Löschen Sie das Gerät oder lösen Sie eine Remote-Aktion aus (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**: Führen Sie Aktionen für Microsoft Entra ID (Azure AD) aus **und** Intune wie beschrieben.

{% hint style="info" %}
Weitere Details 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 als Nächstes den folgenden Befehl erneut ein:

```
certutil -verifyStore MY
```

Wie Sie in der letzten Zeile sehen können, ist das **Zertifikat WIDERRUFEN**

![](https://2075553437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-42dfe633eca8d878a1bce1a117ef10e83ec46734%2Fscepman_revocation3%20\(2\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\).png?alt=media)

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 überprüfen

*Symptome*: Cisco ISE zeigt einen OCSP-unreachable-Fehler an. Aruba ClearPass hat ebenfalls dieses Problem. Der Server, offenbar SCEPman, antwortet auf die OCSP-Anfrage mit einem TCP-Reset-Paket.

*Ursache*: Sowohl Cisco ISE als auch Aruba ClearPass unterstützen HTTP 1.1 bei der OCSP-Suche nicht und senden keinen Host-Header in ihrer OCSP-Anfrage. Daher können sie keine Verbindung zu einer allgemeinen SCEPman-Instanz herstellen, die auf Azure App Services läuft. Die Fehlermeldung kann so aussehen:

![](https://2075553437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-73190ac3e2e77c25974776ffa48e74b2c33f96da%2Fcisco-ocsp-error%20\(2\)%20\(4\)%20\(4\)%20\(4\)%20\(4\)%20\(4\)%20\(2\)%20\(1\).jpg?alt=media)

*Lösung*: Bitte siehe [hier](/de/andere/troubleshooting/cisco-ise-host-header-limitation.md).

### Gerätezertifikate auf meinen Android-(dedizierten) Systemen sind nicht gültig

Auf Android-(dedizierten) Systemen platziert Intune oder Android zufällig in manchen Fällen die Intune-Geräte-ID anstelle der AAD-Geräte-ID in das Zertifikat, 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 geschieht nur, wenn Sie den Microsoft Entra ID (Azure AD)-Freigabemodus als Anmeldemethode für firmeneigene dedizierte Geräte anstelle des Standardmodus verwenden. Wenn Sie den Standardmodus für Tokentypen verwenden `Firmeneigenes dediziertes Gerät`, 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, daher spielt das keine Rolle. Um den Anmeldemodus zu ändern, gehen Sie zu den [Android-Anmeldungseinstellungen des Microsoft Endpoint Manager Admin Centers](https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/DevicesAndroidMenu/androidEnrollment) und wählen Sie `Firmeneigenes dediziertes Gerät (Standard)` anstatt `Firmeneigenes dediziertes Gerät mit Azure AD-Freigabemodus`. Bitte beachten Sie die [Microsoft-Dokumentation](https://docs.microsoft.com/en-us/mem/intune/enrollment/android-kiosk-enroll) für die 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 zeigt an, dass keine Verbindung besteht

Wenn Ihre SCEPman-Startseite ein rotes Etikett "Not Connected" für die Storage Account-Konnektivität anzeigt, fehlen dem Managed Identity des SCEPman App Service (und möglicherweise auch dem von SCEPman Certificate Master) möglicherweise Berechtigungen für den Storage Account. In diesem Fall kann SCEPman nicht prüfen, ob ein Zertifikat manuell widerrufen wurde, und daher auch nicht auf OCSP-Anfragen reagieren. Dies geschieht normalerweise, wenn Sie den Storage Account in ein anderes Abonnement oder eine andere Ressourcengruppe verschieben. Es kann auch nach einem Upgrade von Community Edition auf Enterprise Edition auftreten -- in diesem Fall bestand das Berechtigungsproblem bereits zuvor, aber die Community Edition hat es nicht überprüft.

Um dies zu beheben, müssen Sie dem Managed Identity des SCEPman App Service und dem von SCEPman Certificate Master die Rolle "Storage Table Data Contributor" für den Storage Account zuweisen. Die Rollenzuweisungen können manuell im Azure Portal unter "Access Control (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). 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 kein 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.<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.scepman.com/de/andere/troubleshooting/general.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
