# Häufige Probleme

## Probleme beim Starten von SCEPman

### Ich habe SCEPman von GitHub bereitgestellt und es funktionierte früher, 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-Binärdateien nicht von der in der App-Einstellung WEBSITE\_RUN\_FROM\_PACKAGE konfigurierten URL herunterladen (siehe [Anwendungskonfiguration](https://docs.scepman.com/de/scepman-konfiguration/application-artifacts#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 weiter. Microsoft hat das Verhalten einiger Web-Apps geändert und nun unterstützen einige Versionen keine Weiterleitungen zusammen mit WEBSITE\_RUN\_FROM\_PACKAGE. Daher müssen Sie die URL ändern zu `https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip`.

### SCEPman Azure Web App läuft nicht

Prüfen Sie, ob die Azure-Ressource aktiv und betriebsbereit ist.

![](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\).png?alt=media)

### Mein App Service verwendet die falsche .NET-Version

Im 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 sind. Während der Stack .NET ist, stimmt die .NET-Version möglicherweise nicht mit der erwarteten Version für Ihre SCEPman-Version überein, 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. Wir tun dies, weil unser Update-Mechanismus über [WEBSITE\_RUN\_FROM\_PACKAGE ](https://docs.scepman.com/de/scepman-konfiguration/application-settings/basics#website_run_from_package)uns keine Kontrolle über die .NET-Versions-Einstellung gibt. Daher ist es tatsächlich egal, was als .NET-Version konfiguriert ist.

### Mein SCEPman App Service funktionierte am 2024-11-27 nicht und er hat seit dem 2024-12-16 komplett aufgehört zu funktionieren, nachdem er jahrelang ohne Probleme lief

Wir stellen das veraltete SCEPman-Artefakt-Repository ein <https://github.com/glueckkanja/gk-scepman> nach über drei Jahren, in denen Artefakte an den neuen Ort verschoben wurden <https://github.com/scepman/install>. Am Mittwoch, dem 2024-11-27, haben wir den alten Ort vorübergehend deaktiviert, um die Benutzer auf die dauerhafte Abschaltung am Montag, dem 2024-12-16, aufmerksam zu machen.

Wenn Sie betroffen sind, prüfen Sie Ihre WEBSITE\_RUN\_FROM\_PACKAGE-Einstellung und [aktualisieren Sie den Wert](https://docs.scepman.com/de/scepman-konfiguration/application-artifacts) auf den neuen Paketstandort. Dadurch wird auch Ihre SCEPman-Version von 1.8 auf die neueste Version aktualisiert, was [viele Verbesserungen](https://docs.scepman.com/de/changelog) mit vollständiger Abwärtskompatibilität bringt.

Wenn Sie unsicher sind, ob Sie das neueste Repository verwenden, besuchen Sie die Startseite Ihrer SCEPman-Instanz. Wenn sie noch auf das alte Repository konfiguriert ist, zeigt sie eine Warnung an (und tut dies bereits seit den letzten drei Jahren), die wie folgt 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&#x26;token=b9ed1f6f-ce4f-4745-b30b-9b01c518997c" alt=""><figcaption><p>SCEPman verwendet den alten Paketstandort für WEBSITE_RUN_FROM_PACKAGE</p></figcaption></figure>

## Probleme bei der Ausstellung von Zertifikaten

### Vertrauenswürdiges Stammzertifikat ist bereitgestellt, aber mein Gerätezertifikat über SCEP-Profil führt zu einem Fehler

Das SCEP-Profil führt zu einem Fehler, wenn die Zertifikatbereitstellung nicht erfolgreich war. Fehler können mehrere Ursachen haben:

### SCEP-Zertifikatprofil ist mit einem Fehler konfiguriert

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

1. Öffnen Sie die Anwendung "Ereignisanzeige" von Windows
2. Klicken Sie **Anwendungs- und Dienstprotokolle**
3. Klicken Sie anschließend **Microsoft**
4. Dann klicken Sie **Windows**
5. Scrollen Sie nach unten und suchen Sie nach **DeviceManagement-Enterprise-Diagnostics-Provider** und klicken Sie darauf.
6. Im erscheinenden Fenster klicken Sie **Administrator**
7. Scrollen Sie durch die Liste und suchen Sie nach der Ereignis-ID **32**
8. Sie enthält einen kurzen Fehlerbericht
   * SCEP: Zertifikatsregistrierung 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\).png?alt=media)

Wenn Sie eine Intermediate CA verwenden, beachten Sie, dass Sie [das Intermediate-CA-Zertifikat auswählen müssen](https://docs.scepman.com/de/scepman-bereitstellung/intermediate-certificate#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 verlangt, das Root-CA-Zertifikat im SCEP-Konfigurationsprofil auszuwählen.

### 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-Eintrag für OCSP im Zertifikat hat, wie folgt:

![](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)

Der App Service fehlt eine wichtige Anwendungseinstellung mit dem Namen **AppConfig:BaseUrl** gesetzt auf die azurewebsite-URL. 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 die MDM-Synchronisierung 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' und wird nicht angewendet

Das SCEP-Konfigurationsprofil hängt vom Profil des vertrauenswürdigen Stammzertifikats ab. Ordnen 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 zielen. Mischen Sie keine Benutzer- und Gerätegruppen. Wenn Sie sehen, dass die Konfigurationsprofile in Intune lange Zeit den Status 'ausstehend' haben, ist die Zuweisung wahrscheinlich falsch.

### Einige Windows-Rechner 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 Sie oft nicht im Voraus kennen, wird die Ursache nur auf einer der beiden Seiten angezeigt.

Prüfen Sie, ob es einen `[ERROR]` Eintrag in den SCEPman-Protokollen gibt. Suchen Sie möglicherweise auch nach dem Suchbegriff `[WARN`, dies kann jedoch einige falsch positive Ergebnisse liefern.

Oliver Kieselbach und Christoph Hannebauer haben [einen Blogartikel über die Analyse von Problemen bei Zertifikatsanfragen 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 TLS nur bis Version 1.2. Das Setzen der minimalen eingehenden TLS-Version auf 1.3 im SCEPman App Service verursacht bestimmte Fehlerinträge im `DeviceManagement-Enterprise-Diagnostics-Provider` Ereignisprotokoll. Hier ein Beispiel von einer Windows-11-Maschine:

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

```
TimeCreated  : 02.07.2025 12:51:06
ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
Id           : 32
Message      : SCEP: Zertifikatsregistrierung fehlgeschlagen. Ergebnis: (Unbekannter Win32-Fehlercode: 0x80072f8f).

TimeCreated  : 02.07.2025 12:51:06
ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
Id           : 307
Message      : SCEP: Fehlermeldung LogError : (SCEPInstallCertificateWithScepHelper:Failed to Initialize
               SCEP-Registrierung mit NDES-Server
               'https://scepman.contoso.com/certsrv/mscep/mscep.dll/pkiclient.exe', CA-Zertifikat-Thumbprint
               '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 sehen, da der Bildschirm keine Uhr anzeigt. Das führt zu einem Problem mit neu ausgestellten Zertifikaten, da diese *noch nicht* gültig sind. Windows verwirft dann diese "ungültigen" Zertifikate und zeigt einen Fehler. Zertifikate werden standardmäßig um 10 Minuten zurückdatiert, um kleinere Uhrenabweichungen zu berücksichtigen, aber wir haben kürzlich Windows-10-Geräte gesehen, die bis zu 9 Stunden hinterherhinken.

Sie können mit der Registrierung fortfahren und sobald diese abgeschlossen ist, erhält das Gerät erfolgreich ein Zertifikat, da dann die Uhr korrekt ist. Sie können auch die neue Option [**AppConfig:ValidityClockSkewMinutes**](https://docs.scepman.com/de/scepman-konfiguration/application-settings/certificates#appconfig-validityclockskewminutes) verwenden, 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 adressieren.

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

Das liegt daran, dass SCEPman Zertifikate um einen Tag zurückdatiert, um Probleme mit Geräten zu umgehen, deren Uhr zu spät geht, 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
```

Suchen Sie das Zertifikat mit der Geräte-ID, ausgestellt von der SCEPman-Device-Root-CA-V1, 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 folgendem Befehl anzeigen:

```
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\).png?alt=media)

#### macOS-Rechner

Um die Gültigkeit eines Zertifikats auf einem macOS-Rechner mit OCSP zu prüfen, gehen Sie bitte wie folgt vor:

1. Exportieren Sie das SCEPman Root-CA-Zertifikat aus **Schlüsselbundverwaltung** (**Systemschlüsselbunde > System Roots**) als \*.cer-Datei und legen Sie diese in einem Ordner ab (alternativ können Sie es von der Website Ihrer SCEPman-Instanz herunterladen).
2. Exportieren Sie das Client-Authentifizierungszertifikat, das Sie prü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:

   <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&#x26;token=3c0ca083-8cb9-471f-a7ab-4a314337b585" alt=""><figcaption></figcaption></figure>
4. Öffnen Sie ein **Terminal** und `cd` in den Ordner, der die exportierten Zertifikate enthält.
5. Führen Sie den folgenden Befehl aus:

```
openssl ocsp -issuer <dateiname-scepman-root-ca-zertifikat> -cert <dateiname-zu-prüfendes-zertifikat> -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&#x26;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äte-zertifikat>
```

![](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\).png?alt=media)

### Einen Benutzer widerrufen

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

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

Wenn Sie ein **Geräte** Zertifikat, Sie haben mehrere Optionen abhängig von [#appconfig-intunevalidation-devicedirectory](https://docs.scepman.com/de/scepman-konfiguration/application-settings/scep-endpunkte/intune-validation#appconfig-intunevalidation-devicedirectory "mention"):

1. Microsoft Entra ID (Azure AD): Gerät löschen oder deaktivieren ([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 [#appconfig-intunevalidation-revokecertificatesonwipe](https://docs.scepman.com/de/scepman-konfiguration/application-settings/scep-endpunkte/intune-validation#appconfig-intunevalidation-revokecertificatesonwipe "mention")).
3. **Beide Verzeichnisse**: Aktionen für Microsoft Entra ID (Azure AD) ausführen **und** Intune wie beschrieben.

{% hint style="info" %}
Für weitere Details zu Geräteverzeichnissen lesen Sie bitte den Artikel [device-directories](https://docs.scepman.com/de/scepman-konfiguration/device-directories "mention").
{% 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
3. Klicken Sie **Deaktivieren**

Geben Sie anschließend 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) wieder aktivieren und den obigen Befehl erneut eingeben, sollte das Zertifikat als gültig markiert sein.

{% hint style="info" %}
Es kann bis zu 5 Minuten dauern, bis die Aufforderung '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, scheinbar SCEPman, antwortet mit einem TCP-Reset-Paket auf die OCSP-Anfrage.

*Ursache*: Sowohl Cisco ISE als auch Aruba ClearPass unterstützen bei der OCSP-Abfrage kein HTTP 1.1 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 wie folgt 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](https://docs.scepman.com/de/andere/troubleshooting/cisco-ise-host-header-limitation).

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

Auf Android (dedicated)-Systemen setzt Intune oder Android in Einzelfällen versehentlich 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 passiert nur, wenn Sie den Microsoft Entra ID (Azure AD) Shared Mode als Registrierungsmodus für unternehmenseigene dedizierte Geräte verwenden, anstatt des Standardmodus. Wenn Sie den Standardmodus für Token-Typen `Unternehmenseigenes dediziertes Gerät`verwenden, sind Sie von dem Problem nicht betroffen. Intune wird weiterhin die Intune-Geräte-ID anstelle der AAD-Geräte-ID in das Zertifikat setzen, aber im Standardmodus sind diese identisch, sodass es keine Rolle spielt. Um den Registrierungsmodus zu ändern, gehen Sie zu den [Android-Registrierungseinstellungen im Microsoft Endpoint Manager Admin Center](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 konsultieren 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 zusammen, um dieses Problem in allen Konfigurationen zu lösen. Bitte kontaktieren Sie unseren Support, wenn Sie ebenfalls betroffen sind.

### Mein Storage-Konto zeigt 'Nicht verbunden' an

Wenn auf der SCEPman-Startseite ein roter Tag "Not Connected" für die Storage Account-Konnektivität angezeigt wird, fehlen möglicherweise der Managed Identity des SCEPman App Service (und möglicherweise auch der von SCEPman Certificate Master) Berechtigungen für das Storage-Konto. In diesem Fall kann SCEPman nicht prüfen, ob ein Zertifikat manuell widerrufen wurde und kann daher nicht auf OCSP-Anfragen antworten. Dies passiert normalerweise, wenn Sie das Storage-Konto in ein anderes Abonnement oder eine andere Ressourcengruppe verschieben. Es kann auch nach dem Upgrade einer Community-Edition auf die Enterprise-Edition auftreten – in diesem Fall bestand das Berechtigungsproblem bereits zuvor, aber die Community-Edition hat nicht danach 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" für das Storage-Konto gewähren. Die Rollenzuweisungen können manuell im Azure-Portal unter "Zugriffssteuerung (IAM)" des Storage-Kontos vorgenommen werden. Alternativ [führen Sie das SCEPman-Installations-CMDlet aus dem SCEPman-PowerShell-Modul noch einmal aus](https://docs.scepman.com/de/scepman-bereitstellung/permissions/post-installation-config#running-the-scepman-installation-cmdlet).

## SCEPman stellt keine Zertifikate mit EKUs außer Client Authentication aus

Prüfen Sie Ihre SCEPman-Umgebungsvariablen, um zu sehen, was für [AppConfig:UseRequestedKeyUsages](https://docs.scepman.com/de/scepman-konfiguration/application-settings/certificates#appconfig-userequestedkeyusages)konfiguriert ist. Wenn es nicht gesetzt ist, lautet der Standardwert "false".&#x20;

Neue Installationen setzen dies automatisch auf "true", ältere SCEPman-Installationen haben dies jedoch auf false gesetzt. SCEPman-Updates ändern kein Verhalten, außer für Fehlerbehebungen oder Änderungen, die unter keinen Umständen einen Nachteil darstellen. Wenn dies auf false gesetzt ist, werden die im Antrag angegebenen EKUs und Schlüsselnutzungen ignoriert.<br>
