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).
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.
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 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 auf den neuen Paketstandort. Dadurch wird auch Ihre SCEPman-Version von 1.8 auf die neueste Version aktualisiert, was viele Verbesserungen 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:
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:
Öffnen Sie die Anwendung "Ereignisanzeige" von Windows
Klicken Sie Anwendungs- und Dienstprotokolle
Klicken Sie anschließend Microsoft
Dann klicken Sie Windows
Scrollen Sie nach unten und suchen Sie nach DeviceManagement-Enterprise-Diagnostics-Provider und klicken Sie darauf.
Im erscheinenden Fenster klicken Sie Administrator
Scrollen Sie durch die Liste und suchen Sie nach der Ereignis-ID 32
Sie enthält einen kurzen Fehlerbericht
SCEP: Zertifikatsregistrierung fehlgeschlagen. Ergebnis (Der Hashwert ist nicht korrekt.).
Wenn Sie eine Intermediate CA verwenden, beachten Sie, dass Sie das Intermediate-CA-Zertifikat auswählen müssen 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
Dies ist nur ein Problem vor Version 1.2
Wenn das Gerätezertifikat einen localhost-URL-Eintrag für OCSP im Zertifikat hat, wie folgt:
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:
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:
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 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:
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 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.
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:
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).
Um zu überprüfen, ob der OCSP-Responder funktioniert, können Sie den OCSP-URL-Cache mit folgendem Befehl anzeigen:
macOS-Rechner
Um die Gültigkeit eines Zertifikats auf einem macOS-Rechner mit OCSP zu prüfen, gehen Sie bitte wie folgt vor:
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).
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.
Extrahieren Sie die OCSP-Responder-URL aus der Authority Information Access (AIA)-Eigenschaft des Client-Authentifizierungszertifikats:
Öffnen Sie ein Terminal und
cdin den 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 Optionen:
Den Benutzer aus Microsoft Entra ID (Azure AD) löschen oder
Anmeldung für den Benutzer blockieren
Wenn Sie ein Geräte Zertifikat, Sie haben mehrere Optionen abhängig von AppConfig:IntuneValidation:DeviceDirectory:
Microsoft Entra ID (Azure AD): Gerät löschen oder deaktivieren (Microsoft Entra ID (Azure AD) Portal: "Geräte" - "Alle Geräte").
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).
Beide Verzeichnisse: Aktionen für Microsoft Entra ID (Azure AD) ausführen und Intune wie beschrieben.
Für weitere Details zu Geräteverzeichnissen lesen Sie bitte den 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
Klicken Sie Deaktivieren
Geben Sie anschließend 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) wieder aktivieren und den obigen Befehl erneut eingeben, sollte das Zertifikat als gültig markiert sein.
Es kann bis zu 5 Minuten dauern, bis die Aufforderung '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, 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:
Lösung: Bitte siehe hier.
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ätverwenden, 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 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 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.
SCEPman stellt keine Zertifikate mit EKUs außer Client Authentication aus
Prüfen Sie Ihre SCEPman-Umgebungsvariablen, um zu sehen, was für AppConfig:UseRequestedKeyUsageskonfiguriert ist. Wenn es nicht gesetzt ist, lautet 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 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.
Zuletzt aktualisiert
War das hilfreich?