一般的な問題
SCEPman の起動に関する問題
SCEPman を GitHub からデプロイしており以前は動作していましたが、現在は Web アプリが起動しなくなりました
エラーが「503 Cannot download ZIP」の場合、Web アプリがアプリ設定 WEBSITE_RUN_FROM_PACKAGE に設定された URL からアプリケーションバイナリの ZIP をダウンロードできないことを意味します（参照： アプリケーション構成).
次の URL https://github.com/glueckkanja/gk-scepman/raw/master/dist/Artifacts.zip は、以前のドキュメントで GitHub デプロイ向けに推奨していたものですが別の URL にリダイレクトします。Microsoft は一部の Web アプリの挙動を変更し、WEBSITE_RUN_FROM_PACKAGE とリダイレクトの併用をサポートしないバージョンが存在するため、URL を次のものに変更する必要があります： https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip.
SCEPman の Azure Web App が実行されていない
Azure リソースが起動しているか確認してください。
App Service が間違った .NET バージョンを使用している
SCEPman または Certificate Master の App Service リソースで、[設定] -> [構成] -> [全般設定] -> [スタック設定] にどのスタックとバージョンが設定されているかを確認できます。スタックが .NET であっても、.NET のバージョンが SCEPman のバージョンに期待されるもの（例：SCEPman 2.8 では .NET 8）と一致しないことがあります。
これは、一部の一般的な .NET バージョンが、設定で選択した .NET バージョンに関係なく、すべての Windows App Service に自動的に利用可能であるためです。私たちはこの自動インストールされる .NET バージョンのセットに新しいバージョンが含まれたときにのみ SCEPman を新しい .NET バージョンに対応させます。これは、更新メカニズムが WEBSITE_RUN_FROM_PACKAGE により .NET バージョン設定を制御できないためです。したがって、実際には .NET バージョンに何が設定されているかは重要ではありません。
私の SCEPman App Service は 2024-11-27 には動作しておらず、その後長年問題なく動作していたのに 2024-12-16 以降完全に動作しなくなりました
非推奨の SCEPman アーティファクトリポジトリをシャットダウンしています https://github.com/glueckkanja/gk-scepman アーティファクトを新しい場所へ移動してから3年以上経過した後に https://github.com/scepman/installに移行しました。2024-11-27（水）に、2024-12-16（月）の恒久的シャットダウンを周知するために一時的に古い場所を無効にしました。
影響を受けている場合は、WEBSITE_RUN_FROM_PACKAGE 設定を確認し、 値を更新 して新しいパッケージの場所にしてください。これにより SCEPman のバージョンが 1.8 から最新バージョンへ更新され、 多くの改善点 が提供され、後方互換性は完全に保持されます。
最新のリポジトリを使用しているか不明な場合は、SCEPman のスプラッシュページを確認してください。まだ古いリポジトリに設定されている場合、次のような警告が表示されます（過去 3 年間既に表示されていました）：
証明書発行に関する問題
信頼されたルート証明書は展開されているが、SCEP プロファイル経由でのデバイス証明書がエラーになる
証明書展開が成功していない場合、SCEP プロファイルはエラーになります。エラーにはいくつかの原因があります：
SCEP 証明書プロファイルがエラーで構成されている
SCEP 証明書プロファイルで誤った信頼されたルート証明書が選択されている場合に発生することがあります。これはイベントログにも表示されます：
Windows イベント アプリケーションを開きます
クリック アプリケーションおよびサービス ログ
次に、クリック Microsoft
さらに、クリック Windows
下へスクロールして次を検索します DeviceManagement-Enterprise-Diagnostics-Provider をクリックしてください。
表示されるウィンドウで、クリック 管理者
リストをスクロールしてイベント ID を検索します 32
短いエラー報告が含まれています
SCEP: 証明書の登録に失敗しました。結果 (ハッシュ値が正しくありません)。
中間 CA を使用している場合は、次の点に注意してください： SCEP 構成プロファイルで中間 CA 証明書を選択する必要があります SCEP 構成プロファイルでルート CA 証明書ではなく中間 CA 証明書を選択してください。これは Windows プラットフォーム特有の挙動であり、例えば Android では SCEP 構成プロファイルでルート CA 証明書を選択する必要があります。
私の証明書に正しい OCSP URL エントリがない
これはバージョン 1.2 より前の問題に限られます
デバイス証明書の OCSP エントリが次のように localhost の URL になっている場合：
App Service に次の名前の重要なアプリケーション設定が欠けています AppConfig:BaseUrl を azurewebsite の URL に設定してください。これを修正するには、変数を追加して App Service の構成を保存します：
デバイスからこの証明書を削除して MDM 同期を行ってください。実行すると OCSP エントリに正しい URL が表示されます：
SCEP 構成プロファイルが保留中になっていて適用されない
SCEP 構成プロファイルは信頼されたルート証明書プロファイルに依存します。ユーザーまたはデバイスが重複するように、両方のプロファイルを同じ Azure Active Directory のユーザーまたはデバイス グループに割り当てて、両方がデバイスにターゲットされていることを確認してください。ユーザーグループとデバイスグループを混在させないでください。Intune で構成プロファイルのステータスが長時間「保留中」のままの場合、割り当てが間違っている可能性があります。
一部の Windows マシンが証明書を登録または更新しない
SCEPman 側とクライアント側の両方で確認できます。問題によっては（事前にはわからないことが多い）原因が両者のどちらか一方にのみ表示されます。
次のようなエントリがないか確認してください： [ERROR] SCEPman のログにエントリがないか確認してください。場合によっては検索語も試してください： [WARNただし、これには偽陽性が含まれる場合があります。
Oliver Kieselbach と Christoph Hannebauer は 証明書要求や更新の問題解析に関するブログ記事を執筆しました これはクライアント側での登録問題の追跡に役立ちます。
Windows の SCEP クライアントは TLS 1.2 までしかサポートしていません。SCEPman App Service で受信 TLS の最小バージョンを 1.3 に設定すると、 DeviceManagement-Enterprise-Diagnostics-Provider イベントログ に特定のエントリが記録されます。以下は Windows 11 マシンの例です：
Windows 10 デバイスは AutoPilot で登録できない
現在、一部の Windows 10 デバイスは OOBE 実行中に正しい時刻になっていません。画面に時計が表示されないため判別が難しいです。これにより新規発行された証明書が まだ 有効でない
ためエラーになります。Windows はこれらの「無効な」証明書を破棄してエラーを表示します。小さな時計のずれに対応するために、証明書はデフォルトで 10 分前に発行されますが、最近では最大 9 時間遅れている Windows 10 デバイスが確認されています。 登録を続行すると、登録完了後にデバイスは正常に証明書を取得します（その時点で時計が正しいため）。または新しいオプション AppConfig:ValidityClockSkewMinutes
を使用して証明書の発行時刻を 10 分以上前倒しすることができます。証明書を1日分前倒しするには 1440 分を使用してください。これはこの問題に対処するために新しい SCEPman インストールのデフォルトになります。
今日証明書を発行しましたが、発行日が昨日になっている Windows 10 デバイスは AutoPilot で登録できない.
これは、クロックが遅れているデバイスの問題に対処するために SCEPman が証明書の日付を1日戻しているためです。詳細は次を参照してください：
証明書の有効性に関する問題
ローカルの証明書を確認する
Windows マシン
certutil -verifyStore MY
SCEPman-Device-Root-CA-V1 によって発行されたデバイス ID の証明書を確認し、証明書が有効かどうかを確認してください（最終行を参照）。
certutil -urlcache OCSP
macOS マシン
OCSP を使用して macOS マシン上の証明書の有効性を確認するには、次の手順に従ってください： SCEPman ルート CA 証明書を次からエクスポートします： (キーチェーンアクセスシステムキーチェーン > システムルート
) を *.cer ファイルとしてエクスポートし、フォルダに置きます（代わりに SCEPman インスタンスのウェブサイトからダウンロードしても構いません）。 SCEPman ルート CA 証明書を次からエクスポートします： (確認したいクライアント認証証明書を次からエクスポートします：システムキーチェーン > システム > My Certificates
) を *.cer ファイルとして同じフォルダに保存します。 クライアント認証証明書の Authority Information Access
(AIA) プロパティから OCSP レスポンダの URL を抽出します： ターミナル セッションを開き、
cdでエクスポートした証明書を含むフォルダに移動します。次のコマンドを実行してください：
応答の最後の方に失効ステータスが表示されます:\
他のマシンから証明書を確認する
代替として、デバイス証明書をエクスポートして次を使用することができます： certutil Windows マシン上で certutil を使用すると、OCSP チェック用の小さな certutil UI が表示されます：
ユーザーの取り消し（Revoke）
ユーザーの 証明書を取り消す場合、次の 2 つのオプションがあります： Microsoft Entra ID (Azure AD) からユーザーを削除する、または
ユーザーのサインインをブロックする
デバイスの
ユーザーの 証明書を取り消す場合、状況に応じて複数のオプションがあります： Microsoft Entra ID (Azure AD)：デバイスを削除または無効化する（ AppConfig:IntuneValidation:DeviceDirectory:
Microsoft Entra ID (Azure AD) ポータル：「デバイス」 - 「すべてのデバイス」）。Intune
：デバイスを削除するかリモート操作をトリガーします（"WipePending" のようないくつかの管理状態は前述のとおり自動的に証明書を取り消します）。両方のディレクトリ AppConfig:IntuneValidation:RevokeCertificatesOnWipe).
：Microsoft Entra ID (Azure AD) に対する操作を実行し、および Intune の操作を実行してください（上記の説明の通り）。 詳細なデバイスディレクトリに関する情報は、次の記事を参照してください：
次の例は Microsoft Entra ID (Azure AD) 経由でデバイス証明書を取り消す方法です： デバイスディレクトリ.
に移動します
デバイス - すべてのデバイス あなたの Microsoft Entra ID (Azure AD) 内の デバイスを選択します
デバイスを選択
クリック 無効化
次に、以下のコマンドをもう一度入力します：
上記コマンドの最後の行に示されているように、 証明書は取り消されています
デバイスを Microsoft Entra ID (Azure AD) で再度有効化し、上記のコマンドを再度実行すると、証明書は有効としてマークされるはずです。
'Marked as valid' のプロンプトが表示されるまで最大 5 分かかる場合があります。
アクセスポイントが SCEPman 発行の認証証明書を検証できない
症状：Cisco ISE が OCSP 到達不能のエラーを表示します。Aruba ClearPass でも同様の問題があります。サーバ（見かけ上は SCEPman）が OCSP リクエストに対して TCP リセットパケットで応答します。
原因：Cisco ISE および Aruba ClearPass は OCSP 照会時に HTTP/1.1 をサポートしておらず、OCSP リクエストに Host ヘッダーを送信しません。したがって、Azure App Services 上で動作する一般的な SCEPman インスタンスに接続できません。エラーメッセージは次のように表示されることがあります：
解決策：詳細は次を参照してください ここ.
Android（専用）端末でのデバイス証明書が有効でない
Android（専用）端末では、Intune または Android がランダムなケースで SCEP 構成プロファイルに変数を構成していても、AAD デバイス ID の代わりに Intune デバイス ID を証明書に入れてしまうことがあります。SCEPman はその ID のデバイスを AAD で見つけられず、証明書を取り消されたものと見なします。
これは、企業所有の専用デバイスの登録方法として既定モードではなく Microsoft Entra ID (Azure AD) の共有モードを使用した場合にのみ発生します。トークンタイプの既定モードで 企業所有の専用デバイスを使用している場合、この問題の影響は受けません。Intune は依然として証明書に Intune デバイス ID を入れますが、既定モードでは Intune デバイス ID と AAD デバイス ID が同じになるため問題になりません。登録モードを変更するには、 Microsoft Endpoint Manager 管理センター の Android 登録設定 へ移動し、 企業所有の専用デバイス（既定） を選択してください（代わりに Azure AD 共有モードの企業所有専用デバイスを選択しないでください）。この選択の影響については Microsoft のドキュメント を参照してください。
私たちは現在 Microsoft と協力してあらゆる構成でこの問題を解決する作業を行っています。影響を受けている場合はサポートにご連絡ください。
私のストレージアカウントが「接続されていない」と表示される
SCEPman のホームページにストレージアカウントの接続性が赤いタグ「Not Connected」で表示される場合、SCEPman App Service（および場合によっては SCEPman Certificate Master）のマネージド ID にストレージアカウントへの権限が付与されていない可能性があります。この場合、SCEPman は手動で取り消された証明書をチェックできず、OCSP リクエストに応答できません。通常、ストレージアカウントを別のサブスクリプションやリソースグループに移動したときに発生します。また、Community Edition から Enterprise Edition にアップグレードした後に発生することもあります—この場合、権限の問題は以前から存在していましたが Community Edition はそれをチェックしていませんでした。
これを修正するには、SCEPman App Service と SCEPman Certificate Master のマネージド ID に対してストレージアカウント上で「Storage Table Data Contributor」ロールを付与する必要があります。ロールの割り当てはストレージアカウントの「アクセス制御 (IAM)」で手動で行えます。あるいは単に SCEPman PowerShell モジュールから SCEPman インストール用 CMDlet を再実行してください.
SCEPman がクライアント認証以外の EKU で証明書を発行しない
AppConfig:UseRequestedKeyUsages に何が設定されているかを SCEPman の環境変数で確認してください AppConfig:UseRequestedKeyUsagesが設定されていない場合、デフォルトは "false" です。
新規インストールでは自動的にこれを "true" に設定しますが、古い SCEPman インストールでは false に設定されているものがあります。SCEPman の更新は、いかなる状況でも不利益が生じない修正や変更を除いて既存の動作を変更しません。これが false に設定されていると、リクエストの EKU とキー使用法は無視されます。
最終更新
役に立ちましたか？