# 一般的な問題 ## SCEPman の起動時の問題 ### GitHub から SCEPman をデプロイして以前は動作していましたが、今は Web App が起動しなくなりました エラーが「503 Cannot download ZIP」の場合、Web App はアプリ設定 WEBSITE\_RUN\_FROM\_PACKAGE で構成された URL からアプリケーションのバイナリを含む ZIP をダウンロードできません（参照 [アプリケーション構成](https://docs.scepman.com/ja/scepman-gou-cheng/application-artifacts#change-artifacts)). URL ** この URL は、このドキュメントの以前のバージョンで GitHub デプロイ向けに推奨していたものですが、別の URL にリダイレクトされます。Microsoft は一部の Web Apps の動作を変更し、現在では一部のバージョンで WEBSITE\_RUN\_FROM\_PACKAGE とリダイレクトの併用をサポートしていません。そのため、URL を次のものに変更する必要があります `https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip`. ### SCEPman Azure Web App が実行されていません Azure リソースが稼働しているか確認してください。 ![](https://114237723-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) ### App Service が間違った .NET バージョンを使用しています SCEPman または Certificate Master の App Service リソースで、Settings -> Configuration -> General settings -> Stack settings の下に、その App Service に構成されている Stack とバージョンを確認できます。Stack が .NET であっても、.NET バージョンは SCEPman のバージョンに対して想定どおりでない場合があります。たとえば、SCEPman 2.8 で .NET 8 などです。 これは、一般的な .NET バージョンの一部が、設定でどの .NET バージョンを選択していても、すべての Windows App Service で自動的に利用可能だからです。SCEPman を新しい .NET バージョンへ移行するのは、そのバージョンが自動インストール済み .NET バージョンのセットに含まれている場合のみです。これは、 [WEBSITE\_RUN\_FROM\_PACKAGE ](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/basics#website_run_from_package)経由の更新メカニズムでは .NET バージョン設定を制御できないためです。したがって、実際には .NET バージョンとして何が構成されているかは重要ではありません。 ### 2024-11-27 には SCEPman App Service が動作していなかったのですが、長年問題なく動作していたにもかかわらず、2024-12-16 以降は完全に動作しなくなりました 非推奨の SCEPman アーティファクト リポジトリを停止しています アーティファクトを新しい場所へ移行してから 3 年以上が経過した後 。2024-11-27 水曜日には、2024-12-16 月曜日の恒久的な停止をユーザーに知らせるため、旧ロケーションを一時的に無効化しました。 影響を受けている場合は、WEBSITE\_RUN\_FROM\_PACKAGE の設定を確認し [値を更新してください](https://docs.scepman.com/ja/scepman-gou-cheng/application-artifacts) 新しいパッケージの場所に。これにより SCEPman のバージョンも 1.8 から最新バージョンへ更新され、 [多くの改善](https://docs.scepman.com/ja/changelog) を完全な下位互換性付きで利用できるようになります。 最新のリポジトリを使用しているか不明な場合は、SCEPman のスプラッシュページを開いてください。まだ古いリポジトリに設定されている場合は、次のような警告が表示されます（そして過去 3 年間も同様に表示されていました）。

SCEPman が WEBSITE_RUN_FROM_PACKAGE に古いパッケージの場所を使用しています

## 証明書発行時の問題 ### Trusted Root Certificate はデプロイ済みなのに、SCEP プロファイル経由のデバイス証明書でエラーになる 証明書のデプロイが成功しなかった場合、SCEP プロファイルはエラーになります。エラーにはいくつかの理由があります。 ### SCEP 証明書プロファイルの構成にエラーがあります SCEP 証明書プロファイルで誤った Trusted Root Certificate が選択されている場合、これが起こりえます。これはイベントログにも表示されます。 1. Windows のイベント アプリを開く 2. をクリックする **アプリケーションとサービス ログ** 3. 次に、 **Microsoft** 4. その後、 **Windows** 5. 下にスクロールして **DeviceManagement-Enterprise-Diagnostics-Provider** を探してクリックします。 6. 表示されるウィンドウで、 **Admin** 7. 一覧をスクロールしてイベント ID を検索します **32** 8. 短いエラーレポートが含まれています * SCEP: 証明書の登録に失敗しました。結果（ハッシュ値が正しくありません）。 ![](https://114237723-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) 中間 CA を使用している場合は、 [SCEP 構成プロファイルで Intermediate CA 証明書を選択する](https://docs.scepman.com/ja/scepman-zhan-kai/intermediate-certificate#intermediate-cas-and-intune-scep-profiles) 必要があり、Root CA 証明書を選択してはいけません。これは Windows プラットフォーム特有のもので、たとえば Android では SCEP 構成プロファイルで Root CA 証明書を選択する必要があります。 ### 証明書に正しい OCSP URL エントリがありません {% hint style="info" %} これはバージョン 1.2 より前にのみ発生する問題です {% endhint %} デバイス証明書の OCSP エントリに localhost の URL がこのように入っている場合: ![](https://114237723-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) App Service に、次の名前の重要なアプリケーション設定がありません **AppConfig:BaseUrl** azurewebsite の URL に設定されていません。これを修正するには、変数を追加して App Service の構成を保存します: ``` AppConfig:BaseUrl https://scepman-XXXXX.azurewebsites.net ``` この証明書をデバイスから削除し、MDM 同期を実行してください。実行すると、OCSP エントリに適切な URL が表示されます。 ![](https://114237723-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) ### SCEP 構成プロファイルが保留中のままで適用されません SCEP 構成プロファイルは Trusted Root 証明書プロファイルに依存します。ユーザーまたはデバイスが重複し、両方のプロファイルがデバイスを対象にするように、両方のプロファイルを同じ Azure Active Directory ユーザーまたはデバイス グループに割り当ててください。ユーザー グループとデバイス グループを混在させないでください。Intune で構成プロファイルの状態が長時間 pending のままの場合、割り当てが間違っている可能性があります。 ### 一部の Windows マシンで証明書の登録または更新ができません SCEPman 側とクライアント側の両方から確認できます。事前には分からないことが多い問題の種類によっては、根本原因は 2 つの側のうち片方にだけ表示されます。 次のものがあるか確認してください `[ERROR]` SCEPman のログ内にエントリ。検索語として次も検索してみてください `[WARN`、ただし誤検出がいくつか出る可能性があります。 Oliver Kieselbach と Christoph Hannebauer は [証明書要求または更新の問題の分析に関するブログ記事を書きました](https://oliverkieselbach.com/2022/09/21/deep-dive-of-scep-certificate-request-renewal-on-intune-managed-windows-clients/) これにより、クライアント側での登録の問題を追跡できます。 Windows の SCEP クライアントは TLS 1.2 までしかサポートしません。SCEPman App Service で最小受信 TLS バージョンを 1.3 に設定すると、 `DeviceManagement-Enterprise-Diagnostics-Provider` イベント ログに特定のエントリが表示されます。以下は Windows 11 マシンの例です: {% code overflow="wrap" fullWidth="false" %} ``` TimeCreated : 7/2/2025 12:51:06 PM ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider Id : 32 Message : SCEP: Certificate enroll failed. Result: (Unknown Win32 Error code: 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 NDES サーバーでの SCEP 登録 'https://scepman.contoso.com/certsrv/mscep/mscep.dll/pkiclient.exe'、CA 証明書のサムプリント '24C45EF4284A5093A9C3886A6466C1D6D84EE058' およびサーバー証明書 ''。LogError 0x80) ``` {% endcode %} ### Windows 10 デバイスは AutoPilot で登録できません 現在、一部の Windows 10 デバイスは OOBE 体験中に時刻が正しくありません。画面に時計が表示されないため、これは簡単には分かりません。これにより新しく発行された証明書に問題が発生します。証明書は *まだ* 有効ではないためです。Windows はその後、これらの「無効な」証明書を破棄し、エラーを表示します。小さな時計ずれに対応するため、証明書は既定で 10 分前の時刻に発行されますが、最近では最大 9 時間遅れている Windows 10 デバイスも確認されています。 登録を続行して構いません。完了すると、時刻が正しくなるため、デバイスは正常に証明書を取得します。次の新しいオプションも使用できます [**AppConfig:ValidityClockSkewMinutes**](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/certificates#appconfig-validityclockskewminutes) を使って、証明書を 10 分より長く過去にずらすことができます。証明書を丸 1 日分過去にずらすには 1440 分を使用してください。これは、この問題に対処するため、新規の SCEPman インストールにおける既定値になります。 ### 今日証明書を発行したのに、発行日が昨日になっています これは、時刻が遅れているデバイスの問題に対処するために SCEPman が証明書の日付を 1 日戻しているためです。参照 [Windows 10 デバイスは AutoPilot で登録できません](#windows-10-devices-cannot-enroll-with-autopilot). ## 証明書の有効性に関する問題 ### ローカル証明書を確認 #### Windows マシン 最初に、デバイス証明書の有効性を確認する必要があります。そのため、管理者としてコマンド プロンプトを開き、次のコマンドを入力してください: ``` certutil -verifyStore MY ``` SCEPman-Device-Root-CA-V1 によって発行されたデバイス ID の証明書を確認し、証明書が有効かどうかを確認します（最後の行を参照）。 ![](https://114237723-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) OCSP 応答者が動作していることを確認するには、次のコマンドで OCSP URL キャッシュを確認できます: ``` certutil -urlcache OCSP ``` ![](https://114237723-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 マシン OCSP を使用して macOS マシン上の証明書の有効性を確認するには、次の手順に従ってください: 1. SCEPman Root CA 証明書を **Keychain Access** (**System Keychains > System Roots**）から \*.cer ファイルとしてエクスポートし、フォルダーに置きます（または、SCEPman インスタンスの Web サイトからダウンロードすることもできます）。 2. 確認したいクライアント認証証明書を **Keychain Access** (**System Keychains > System > My Certificates**）から同じフォルダーへ \*.cer ファイルとしてエクスポートします。 3. クライアント認証証明書の **Authority Information Access** (AIA) プロパティから OCSP 応答者 URL を抽出します:
4. 開いて **Terminal** セッションに入り、 `cd` を使ってエクスポートした証明書が含まれるフォルダーに移動します。 5. 次のコマンドを実行します: ``` openssl ocsp -issuer -cert <検証対象証明書のファイル名> -text -url ``` 6. 応答の最後の方で、失効状態が表示されます:\\
### 他のマシンの証明書を確認 代替として、デバイス証明書をエクスポートして `certutil` Windows マシン上で使用し、OSCP チェック用の小さな certutil UI を表示できます: ``` certutil -url <エクスポートしたデバイス証明書へのパス> ``` ![](https://114237723-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) ### ユーザーを失効させる ユーザーの **証明書を失効させたい場合は、2 つの方法があります:‌** Microsoft Entra ID (Azure AD) からそのユーザーを削除する、または 1. ユーザーのサインインをブロックする 2. デバイス ユーザーの **証明書の場合は、** いくつかのオプションがあります。 [#appconfig-intunevalidation-devicedirectory](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-devicedirectory "mention"): 1. Microsoft Entra ID (Azure AD): デバイスを削除または無効化する（[Microsoft Entra ID (Azure AD) ポータル](https://aad.portal.azure.com/): 「Devices」-「All devices」）。 2. **Intune**: デバイスを削除するか、リモート操作を実行します（「WipePending」などの複数の管理状態は、次の項目に記載のとおり証明書を自動的に失効させます [#appconfig-intunevalidation-revokecertificatesonwipe](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-revokecertificatesonwipe "mention")). 3. **両方のディレクトリ**: Microsoft Entra ID (Azure AD) 向けのアクションを実行 **および** Intune で説明されているとおりです。 {% hint style="info" %} デバイス ディレクトリの詳細については、次の記事をお読みください [device-directories](https://docs.scepman.com/ja/scepman-gou-cheng/device-directories "mention"). {% endhint %} 次の例では、Microsoft Entra ID (Azure AD) 経由でデバイス証明書を失効させます: 1. に移動する **Devices - All devices** Microsoft Entra ID (Azure AD) の 2. デバイスを選択 3. をクリックする **無効化** 次に、もう一度次のコマンドを入力します: ``` certutil -verifyStore MY ``` 最後の行に示されているとおり、 **証明書は失効済みです** ![](https://114237723-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) Microsoft Entra ID (Azure AD) でデバイスを再度有効化し、上記のコマンドをもう一度入力すると、証明書は有効としてマークされるはずです。 {% hint style="info" %} 「有効としてマークされました」というプロンプトが表示されるまで、最大 5 分かかることがあります。 {% endhint %} ### Access Point は、SCEPman が発行した認証証明書を検証できません *症状*: Cisco ISE では OCSP に到達できないエラーが表示されます。Aruba ClearPass にも同じ問題があります。サーバーは、SCEPman と思われるものが、OCSP 要求に対して TCP reset パケットを返します。 *原因*: Cisco ISE も Aruba ClearPass も、OCSP の照会時に HTTP 1.1 をサポートしておらず、OCSP 要求で host ヘッダーを送信しません。そのため、Azure App Services で実行されている一般的な SCEPman インスタンスに接続できません。エラーメッセージは次のようになる場合があります: ![](https://114237723-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) *解決策*: 以下を参照してください [こちら](https://docs.scepman.com/ja/sono/troubleshooting/cisco-ise-host-header-limitation). ### Android（専用）システム上のデバイス証明書が有効ではありません Android（専用）システムでは、SCEP 構成プロファイルで変数を構成していても、Intune または Android が誤って AAD デバイス ID の代わりに Intune デバイス ID を証明書へ入れてしまうことがあります。そのため SCEPman は AAD 内でこの ID を持つデバイスを見つけられず、証明書を失効済みと見なします。 これは、既定モードではなく、企業所有の専用デバイス向けに Microsoft Entra ID (Azure AD) の共有モードを登録方法として使用した場合にのみ発生します。Token types に対して既定モードを使用している場合は `Corporate-owned dedicated device`、この問題の影響を受けません。Intune は引き続き AAD デバイス ID の代わりに Intune デバイス ID を証明書へ入れますが、既定モードでは両者が同じになるため問題ありません。登録モードを変更するには、 [Microsoft Endpoint Manager admin center の Android 登録設定](https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/DevicesAndroidMenu/androidEnrollment) を選択し、 `Corporate-owned dedicated device (default)` を選択し、 `Corporate-owned dedicated device with Azure AD shared mode`を使わないようにしてください。詳細については、 [Microsoft のドキュメント](https://docs.microsoft.com/en-us/mem/intune/enrollment/android-kiosk-enroll) を参照して、この選択の影響を確認してください。 現在、すべての構成でこの問題を解決するために Microsoft と協力しています。影響を受けている場合は、サポートまでご連絡ください。 ### Storage Account に「接続されていません」と表示されます SCEPman のホームページで Storage Account 接続に赤いタグ「Not Connected」が表示される場合、SCEPman App Service の Managed Identity（および場合によっては SCEPman Certificate Master のもの）に Storage Account への権限がない可能性があります。この場合、SCEPman は証明書が手動で失効しているかどうかを確認できず、そのため OCSP 要求に応答できません。これは通常、Storage Account を別のサブスクリプションまたはリソース グループに移動した場合に発生します。Community Edition のバージョンを Enterprise Edition にアップグレードした後にも発生することがあります。この場合、権限の問題は以前から存在していましたが、Community Edition では確認していませんでした。 これを修正するには、SCEPman App Service と SCEPman Certificate Master の Managed Identity に、Storage Account 上で「Storage Table Data Contributor」ロールを付与する必要があります。ロールの割り当ては、Azure Portal の Storage Account 内「Access Control (IAM)」で手動で行えます。あるいは、単に [SCEPman PowerShell モジュールから SCEPman Installation CMDlet をもう一度実行してください](https://docs.scepman.com/ja/scepman-zhan-kai/permissions/post-installation-config#running-the-scepman-installation-cmdlet). ## SCEPman は Client Authentication 以外の EKU を持つ証明書を発行しません SCEPman 環境変数を確認して、 [AppConfig:UseRequestedKeyUsages](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/certificates#appconfig-userequestedkeyusages)に何が構成されているか確認してください。設定されていない場合は、既定で「false」になります。 新規インストールでは自動的にこれが「true」に設定されますが、古い SCEPman インストールでは false に設定されています。SCEPman の更新では、いかなる場合でも不利にならない修正や変更以外の動作は変わりません。これが false に設定されている場合、要求された EKU と Key Usage は無視されます。