Windows 10/11で内部証明書が消える原因調査：CAPI2ログ有効化と一括収集（PowerShell・レジストリ）

2025年6月10日以降、Windows 10/11 混在環境で「社内システムへ急にアクセスできない」「certmgr.msc から内部証明書が消えているように見える」端末が散発する場合、原因追跡の第一歩は“証明書ストアで何が起きたか”を時系列で記録することです。CryptoAPI の詳細な動作を残せる CAPI2（Operational）ログを有効化し、削除・更新・検証失敗の痕跡を集めて絞り込みましょう。

内部証明書が「消えた」に見えるときに最初に確認したいこと

「certmgr.msc に表示されない＝証明書が必ず削除された」とは限りません。調査の手戻りを減らすために、まずは次を押さえます。

どのストアの証明書が消えているか（現在のユーザー / ローカルコンピューター、個人 / 中間CA / ルートなど）
対象証明書は“クライアント認証用（ユーザー証明書）”か、“信頼の連鎖（ルート/中間）”か
実際は期限切れ・更新失敗・秘密鍵不整合で使えないだけなのか、証明書エントリ自体が消えているのか
発生タイミング（GPO更新、OSアップデート、EDR更新、VPNクライアント更新、プロファイル再作成などの直後か）

特にcertmgr.msc は「現在のユーザー」ストアが中心です。社内システムが端末証明書（ローカルコンピューター）を使っているケースもあるため、MMC の「証明書（ローカルコンピューター）」でも同じ証明書が存在するかを必ず確認してください。

CAPI2 Operational ログとは（なぜ有効化すると効くのか）

CAPI2（CryptoAPI 2.0）の Operational ログは、Windows が証明書を使って行う処理（チェーン構築、失効確認、証明書ストアの操作、暗号操作の失敗など）を詳細に記録します。既定では無効のことが多い一方、有効化すると次のような調査がしやすくなります。

いつ・どのタイミングでチェーン構築や検証が失敗し始めたか
失効（CRL/OCSP）取得失敗やネットワーク要因が絡んでいるか
証明書ストアに対する操作（追加・更新・削除の痕跡）が出ていないか
どのプロセス/コンポーネントが関与したかを示す手掛かりが残ることがある

今回のように「約14,000台中 250台以上」といった限定的な影響は、GPO/自動登録の失敗・特定ソフトの更新・プロファイル周りの個別要因が絡むことが多く、まずはログで“いつから何が変わったか”を掴むのが近道です。

イベントビューアーで手動有効化する基本手順

まずは影響端末や検証端末で、手動でログを有効化して挙動を確認できます。

イベントビューアーを開く
Win + R → eventvwr → Enter
ログの場所
「アプリケーションとサービスログ」→「Microsoft」→「Windows」→「CAPI2」→「Operational」
必要ならログを消去
Operational を右クリック →「ログの消去」
ログを有効化
Operational を右クリック →「ログを有効にする」
問題を再現して記録
証明書が消える／アクセスできなくなる操作やタイミングを再現し、ログを蓄積させます。
調査が終わったら無効化
Operational を右クリック →「ログを無効にする」

ただし大規模環境では手動対応は現実的ではないため、次の「一括有効化（PowerShell / レジストリ）」を使います。

一括展開向け：PowerShell（wevtutil）で CAPI2 ログを有効化する

Intune / SCCM / EDR のスクリプト配布機能などで端末一括に適用しやすいのが、wevtutil を使った方法です。設定変更が即時反映されやすく、レジストリ直書きより運用が安定します。

有効化＋最大ログサイズ＋「必要に応じて上書き」設定（推奨例）

「最大サイズ 100MB」「必要に応じて上書き（保持しない）」の例です。必要ならログ消去も行えます。

# CAPI2 Operational ログ名
$logName = "Microsoft-Windows-CAPI2/Operational"

# 最大ログサイズ（MB）
$maxSizeMB = 100
$maxBytes  = $maxSizeMB * 1024 * 1024

# 既存ログをクリアしたい場合だけ $true
$clearExisting = $false

if ($clearExisting) {
  wevtutil cl $logName
}

# /e:true   → ログ有効化
# /ms:      → 最大サイズ（バイト）
# /rt:false → 必要に応じて上書き（Retention 無効）
# /ab:false → 自動バックアップしない（必要なら true）
wevtutil sl $logName /e:true /ms:$maxBytes /rt:false /ab:false

# 設定確認（出力が長いので必要に応じて）
wevtutil gl $logName

ポイントを整理します。

目的	設定/オプション	効果	運用上の目安
ログを有効化	`/e:true`	Operational ログが記録される	調査期間だけ有効化し、終了後は無効化推奨
ログサイズを増やす	`/ms:104857600`（100MB）	短時間でログが溢れるのを防ぐ	現象頻度が高いほど大きめに（例：100〜500MB）
上書き運用	`/rt:false`	満杯時に古いログから上書き	端末負担を抑えつつ継続収集しやすい
自動バックアップ	`/ab:true`	満杯時に退避してからクリア	台数が多いとバックアップファイル増加に注意

調査後に無効化するスクリプト例

調査を終えたらログを止め、端末負荷とディスク消費を抑えます。

$logName = "Microsoft-Windows-CAPI2/Operational"
wevtutil sl $logName /e:false

Intune / SCCM 配布時の実務ポイント

管理者権限（SYSTEM など）で実行：ログ設定は端末全体の構成なので、ユーザー権限だと失敗することがあります。
段階展開（リング運用）：まず影響が出ている端末群や検証用グループに限定し、ログ量と端末負荷を確認してから全体へ広げます。
ログクリアは慎重に：全端末で一律に wevtutil cl すると、既存の手掛かりを消してしまう可能性があります。初回だけ、または影響端末のみで使うのが安全です。

レジストリで CAPI2 ログを有効化する（GPO 配布・端末管理向け）

端末管理ツールによっては「レジストリ配布」がやりやすい場合があります。CAPI2 Operational のチャンネル設定は、一般に次の領域で管理されます。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-CAPI2/Operational

代表的に使う値は以下です。

値名	型	例	意味
Enabled	DWORD	1	ログ有効（0 で無効）
MaxSize	QWORD	104857600（100MB）	最大ログサイズ（バイト）
Retention	DWORD	0	0=上書き可、1=上書き不可（環境により挙動差が出る場合あり）
AutoBackupLogFiles	DWORD	0	満杯時にバックアップを作るか
File	文字列	%SystemRoot%\System32\Winevt\Logs\…	イベントログの保存先（変更は慎重に）

.reg ファイル例（有効化＋100MB＋上書き運用）

配布する場合は、端末の実装差や権限の影響を避けるため、可能なら wevtutil の方が安定します。どうしてもレジストリ配布に寄せる場合の例として掲載します。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-CAPI2/Operational]
"Enabled"=dword:00000001
"Retention"=dword:00000000
"AutoBackupLogFiles"=dword:00000000
; 100MB = 104,857,600 = 0x06400000
"MaxSize"=qword:0000000006400000

注意：レジストリ変更のみだと反映タイミングが読みづらい環境もあります。配布後に確実に反映させたい場合は、同時に wevtutil sl を実行する、もしくは端末再起動のタイミングに合わせて適用する運用が安全です。

ログを「特定フォルダーに保存」したい場合の現実解

イベントログは既定で %SystemRoot%\System32\Winevt\Logs 配下の .evtx に保存されます（例：Microsoft-Windows-CAPI2%4Operational.evtx のように、チャンネル名の区切りが特殊表記になります）。この保存先を直接変更することも可能ですが、権限・ディスク設計・障害時の復旧性を考えると、既定の保存場所は触らず「必要なタイミングでエクスポートして別フォルダーへ退避」が最も運用しやすいです。

任意フォルダーへエクスポートする（推奨）

以下は C:\Logs\CAPI2 に、端末名＋日時付きでエクスポートする例です。収集サーバーへ回収する前段としても使えます。

$logName = "Microsoft-Windows-CAPI2/Operational"
$folder  = "C:\Logs\CAPI2"

New-Item -ItemType Directory -Path $folder -Force | Out-Null

$timestamp = Get-Date -Format "yyyyMMdd_HHmmss"
$filePath  = Join-Path $folder ("CAPI2-{0}-{1}.evtx" -f $env:COMPUTERNAME, $timestamp)

# /ow:true で同名ファイルがあっても上書き
wevtutil epl $logName $filePath /ow:true

「影響端末を見つけたらすぐ回収」も重要ですが、散発する事象では取り逃しが起きがちです。そこで次のように、定期エクスポートをスケジュールタスクで回すと、現象発生前後のログを継続的に確保できます。

定期エクスポートをスケジュールタスクで回す例

1日1回（例：02:30）にエクスポートするシンプルな例です。タスク名は環境に合わせて変更してください。

$scriptPath = "C:\ProgramData\CAPI2\Export-CAPI2.ps1"
$scriptDir  = Split-Path $scriptPath -Parent

New-Item -ItemType Directory -Path $scriptDir -Force | Out-Null

@'
$logName = "Microsoft-Windows-CAPI2/Operational"
$folder  = "C:\Logs\CAPI2"
New-Item -ItemType Directory -Path $folder -Force | Out-Null
$timestamp = Get-Date -Format "yyyyMMdd_HHmmss"
$filePath  = Join-Path $folder ("CAPI2-{0}-{1}.evtx" -f $env:COMPUTERNAME, $timestamp)
wevtutil epl $logName $filePath /ow:true
'@ | Set-Content -Path $scriptPath -Encoding UTF8

# スケジュールタスク登録（SYSTEM 実行）
$taskName = "Export CAPI2 Operational Log"
$time     = "02:30"

schtasks /Create /F /TN $taskName /SC DAILY /ST $time /RU "SYSTEM" `
  /TR "powershell.exe -NoProfile -ExecutionPolicy Bypass -File `"$scriptPath`""

ログ回収の運用をさらに安定させるなら、エクスポート後に ZIP 圧縮（Compress-Archive）して転送量を減らす、一定世代を超えたファイルは削除する、といった“回収の後始末”もセットにすると現場が回ります。

「最大ログサイズ」「上書き」「バックアップ」の考え方（設定の選び方）

CAPI2 は詳細ログのため、想像以上に増えます。14,000台規模でいきなり全台有効化すると、ディスク使用量と回収コストが跳ね上がることがあります。次の指針で設計すると失敗しにくいです。

まずは影響端末＋周辺端末（同じ部署/同じ構成）に限定して有効化
ログは上書き運用にして端末を安定させる（/rt:false）
回収は定期エクスポートで“必要な期間”を確保（例：1日1回、もしくは4時間ごと）
最大サイズは現象頻度に比例（最初は 100MB、足りなければ 200～500MB へ）

設定の違いを、実務目線でまとめます。

運用パターン	端末の挙動	向いているケース	注意点
上書き運用（推奨）	古いログから自動で消えていく	散発事象の継続収集、全社展開前の試験	回収が遅いと、欲しい期間が上書きされる
保持（上書きしない）	満杯になると記録が止まる可能性	短時間に確実にログを取り切りたい検証	満杯停止に気づかないとログが欠落する
自動バックアップ	満杯時に退避ファイルが増える	端末側で“溢れる前提”の確実な証跡確保	バックアップファイル管理（世代削除）が必須

CAPI2 で特に見たいイベントと、読むときのコツ

CAPI2 はイベント数が多く、全部読むのは現実的ではありません。まずは「失敗」「ストア操作」「チェーン構築/検証」に寄せて見ると、原因へ早く近づけます。

代表的なイベント ID と見るべきポイント

イベント ID	カテゴリ（目安）	何が分かるか	見どころ
11	Build Chain	証明書チェーン構築の成否	ErrorStatus / RevocationStatus、対象の証明書サブジェクト/発行者、失効確認の成否
30	Verify Chain	チェーン検証の成否	ID 11 と時刻を突き合わせ、どの段階で落ちたかを確認
40 / 41	Store Operations	証明書ストアの操作（追加・削除等）の痕跡	Delete/Remove の文言、対象ストア、関連するプロセス/コンポーネントのヒント
53	Object Open/Close	暗号オブジェクトのオープン/クローズ	どの操作が連鎖しているか、直前直後の失敗イベントを追う
64	Crypto Operation Failed	暗号処理失敗の詳細	鍵コンテナ不在、アクセス拒否、プロバイダーエラーなど“実害の理由”が出やすい

同じ端末でも、Windows のビルドや構成、暗号プロバイダー、ネットワーク条件で出るイベントは変わります。固定の ID だけにこだわらず、発生時刻の前後で「Error」「Warning」を優先し、メッセージ内のキーワード（削除、失効、CRL、OCSP、denied、keyset など）で絞り込むと効率的です。

PowerShell で「必要な ID と時間帯」だけ抜き出す

散発事象では「発生した時刻の前後 10〜30分」が最重要です。次の例は、直近6時間の代表 ID を抽出し、CSV に落とします（集計・差分比較が楽になります）。

$log   = "Microsoft-Windows-CAPI2/Operational"
$ids   = 11,30,40,41,53,64
$start = (Get-Date).AddHours(-6)

Get-WinEvent -FilterHashtable @{ LogName=$log; Id=$ids; StartTime=$start } |
  Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message |
  Export-Csv -Path "C:\Logs\CAPI2\CAPI2-extract.csv" -NoTypeInformation -Encoding UTF8

「削除っぽい動き」だけを探したい場合は、メッセージで二段階フィルタをかけます。

$log   = "Microsoft-Windows-CAPI2/Operational"
$start = (Get-Date).AddDays(-1)

Get-WinEvent -FilterHashtable @{ LogName=$log; StartTime=$start } |
  Where-Object { $_.Message -match "Delete|Remove|削除|消去" } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Out-File -FilePath "C:\Logs\CAPI2\CAPI2-delete-like.txt" -Encoding UTF8

証明書消失の切り分けを速くする「現場向けチェックリスト」

今回のように影響が数百台規模で散発する場合、原因は1つとは限りません。以下を“同じフォーマット”で埋めると、比較が圧倒的に速くなります。

観点	確認方法	分かること	次の一手
どのストアが欠けた？	certmgr.msc / MMC（ローカルコンピューター）	ユーザー証明書か、端末証明書か	以後のログやGPO確認の対象を絞る
期限切れ・更新失敗？	証明書の有効期限、更新履歴、テンプレート	「消えた」ではなく「更新できず使えない」可能性	自動登録（Auto-Enrollment）とCA側ログへ
秘密鍵が壊れた？	証明書の“秘密鍵が存在する”表示、CAPI2 ID 64	証明書はあるが鍵がなく認証不可のケース	鍵コンテナ、プロファイル、TPM/プロバイダーを確認
GPOが関与？	`gpresult /h`、適用GPOの差分	配布/削除/制限の設定が紛れた可能性	公開キーのポリシー、信頼ルート配布、制限設定を精査
ソフト更新が関与？	インストール履歴、EDR/VPNの更新時刻	特定エージェントがストアを触る可能性	同時期の更新差分で当たりを付け、ベンダーログへ
プロファイル問題？	一時プロファイル、プロファイル再作成の痕跡	ユーザー証明書が“別のプロファイルにある”可能性	サインイン時イベント、プロファイルサービス関連ログへ

証明書が消える可能性のある原因候補（深掘りアイデア）

ここからは「実際に現場で当たりやすい原因」を、CAPI2 の見方と結び付けて整理します。いきなり全部調べるのではなく、発生日（2025年6月10日以降）を境に変わった要素に優先順位を置くのがコツです。

グループポリシー（GPO）の設定・競合・適用不備

自動登録（Auto-Enrollment）の失敗
テンプレート更新、CA到達性、権限、失効確認、時刻ずれなどで更新が失敗すると、内部システムが要求する証明書が“存在しない”状態になります。CAPI2 ではチェーン構築・検証失敗（ID 11/30）として表面化しやすいです。
信頼ルート/中間CAの配布ポリシーの競合
あるGPOが配布し、別のGPOが置き換えや削除に近い挙動をするなど、意図せぬ差分が起きることがあります。gpresult /h で影響端末と正常端末の差分を比較すると、想像以上に早く当たりが付く場合があります。
「制限付き」や拒否リスト系の設定
内部CAや特定証明書が“信頼しない側”に入ると、利用不可になり、結果的に「証明書が消えた」「使えない」に見えます。CAPI2 の検証失敗の詳細に、ヒントが残ることがあります。

サードパーティ製ソフト（EDR/VPN/管理エージェント）の影響

証明書を使う製品（VPN、ゼロトラスト、TLSインスペクション、端末認証、MDM関連など）は、証明書ストアを監視・調整することがあります。影響が一部端末に偏るのは、次のような条件差があるためです。

対象製品のバージョン差（ロールアウト段階、更新失敗、特定チャンネルのみ先行）
端末属性によるポリシー分岐（部署/ネットワーク帯/端末種別で挙動が変わる）
証明書の用途差（VPN用、Wi-Fi用、社内Web用などテンプレートが別）

CAPI2 の「ストア操作」系イベントや、同時刻のアプリケーションログ、該当製品の独自ログを突き合わせると、関与の有無を切り分けやすくなります。

Windows 更新・暗号基盤周りの変化

発生し始めた日付がはっきりしている場合、Windows Update（品質更新/機能更新）や暗号プロバイダー（TPM、スマートカード、CNG/KSP 等）周りの更新がトリガーになることがあります。影響端末だけで確認するより、正常端末と並べて以下を比較するのが効率的です。

インストールされた更新プログラム（例：Get-HotFix、設定の更新履歴）
ビルド番号（同じ Windows 11 でもビルド差で挙動が変わることがあります）
暗号デバイス/プロバイダー（TPM あり/なし、仮想化ベースセキュリティの有無）

ユーザープロファイル（TEMPプロファイル、再作成、プロファイルコンテナ）の問題

certmgr.msc が主に見る「現在のユーザー」証明書は、ユーザープロファイル（レジストリハイブ）に強く依存します。以下の状態では、ユーザー証明書が“消えたように見える”ことがあります。

一時プロファイルでサインインしている（別のプロファイルの証明書は見えない）
プロファイル再作成・ローミング/コンテナの同期失敗で、証明書ストアが巻き戻った
プロファイル破損により、証明書ストアの一部キーが読み込めない

このパターンでは、CAPI2 だけでなく「ユーザープロファイルサービス」系のイベントや、ログオン直後の異常（設定が初期化された、デスクトップが一時状態になった等）も手掛かりになります。

失効確認（CRL/OCSP）到達性・時刻ずれ

これは「消失」そのものではなく“利用不可”として表面化しやすい原因です。社内システムが厳格に失効確認を要求している場合、CRL/OCSP に到達できないだけで認証が失敗し、「証明書が悪い」「消えた」と誤認されることがあります。

プロキシ/VPN/分割DNS で CRL 参照先に到達できない
端末時刻ずれで有効期間判定が失敗する
証明書チェーンの中間が欠け、ダウンロードに失敗する

CAPI2 のチェーン構築・検証イベント（ID 11/30）の詳細に、失効関連のステータスや URL 取得失敗が残ることがあるため、ネットワーク/時刻系の当たりを付けるのに役立ちます。

証明書ストアの破損・整合性エラー

端末の状態によっては、証明書ストア（実体はレジストリや関連ファイル）の整合性が崩れている場合があります。影響端末で次を実行し、エラーの有無を確認します。

certutil -user -verify
certutil -verify

加えて、証明書が存在しても秘密鍵が参照できないケースでは、CAPI2 の失敗イベント（例：ID 64）に“鍵が見つからない/アクセスできない”系の情報が出ることがあります。

併用すると原因特定が速くなる関連ログ

CAPI2 は強力ですが、証明書の自動登録やクライアント証明書配布が絡む場合、専用のログも併用すると特定が一気に進みます。

ログ	場所（例）	得意領域	こんなとき有効
AutoEnrollment / CertEnroll 系	Microsoft-Windows-CertificateServicesClient-*	自動登録・更新の成否	「更新できず証明書が無い」疑いが強い
Schannel	System / Schannel	TLSハンドシェイク失敗	社内Webアクセス不可が TLS 起因か切り分けたい
プロファイル/ログオン関連	Application / User Profile Service 等	一時プロファイル・読み込み失敗	「ユーザー証明書だけが消える」疑いが強い

「CAPI2 を有効化しても“削除”の痕跡が見つからない」場合は、実際に削除ではなく、自動更新できずに期限切れ→利用不可、チェーン検証失敗で利用不可、プロファイル切り替わりで見えなくなったといったパターンが残りやすいです。

現場で回る調査フロー（ログ有効化→収集→比較→原因特定）

散発かつ影響台数がある事象は、手順がブレると比較ができず、調査が長期化しがちです。次の流れで“データを揃える”ことを優先すると、原因特定までの距離が短くなります。

少数端末でパイロット収集

影響端末（既に消えた端末）数台
影響が出やすい属性の端末（同じ部署、同じVPN、同じ更新チャンネルなど）
正常端末（比較用）数台

これらに CAPI2 を有効化し、ログサイズを確保した上で、定期エクスポートを仕込みます。

証明書の“スナップショット”を残して差分を見る

証明書が本当に消えたか、いつ消えたかを把握するには、ログと同じくらい“状態のスナップショット”が効きます。以下のようにテキストへ吐いておくと、差分比較が簡単です。

# 現在のユーザーの個人ストア（例）をテキスト化
certutil -user -store My > C:\Logs\CAPI2\MyStore-before.txt

# ローカルコンピューター側も必要なら
certutil -store My > C:\Logs\CAPI2\MachineMyStore-before.txt

現象発生後にも同様に採取し、シリアル番号・拇印（Thumbprint）・発行者・有効期限の差分を確認します。

GPO とソフトウェア差分を“同じ観点”で並べる

影響端末と正常端末の比較で特に効くのが、GPO とインストールソフトの差分です。

gpresult /h C:\Logs\CAPI2\gpresult.html を影響/正常で取得
ソフト一覧（例：管理ツールのインベントリ、もしくは社内標準手順）を影響/正常で比較
更新日（2025年6月10日以降）を境に変わったものを優先的に疑う

まとめ：CAPI2 ログで「誰が・いつ・何をしたか」に近づく

内部証明書が消える/見えなくなる問題は、GPO・自動登録・端末更新・セキュリティ製品・プロファイルなど複数要因が絡むことが多く、推測だけでは収束しません。CAPI2 Operational ログを一括で有効化し、ログサイズと上書き運用を適切に設計して継続収集することで、削除操作の痕跡や検証失敗の根本原因を時系列で追いやすくなります。

最短で原因へたどり着くコツは、（1）影響端末と正常端末で同じ形式のデータを集める、（2）発生時刻の前後に絞ってログを見る、（3）GPO/更新/プロファイル/ネットワークの“変化点”を優先する、の3点です。上記のスクリプトをベースに、組織の運用（回収頻度、保存期間、対象台数）に合わせて調整してみてください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Windows 10/11で内部証明書が消える原因調査：CAPI2ログ有効化と一括収集（PowerShell・レジストリ）

内部証明書が「消えた」に見えるときに最初に確認したいこと

CAPI2 Operational ログとは（なぜ有効化すると効くのか）

イベントビューアーで手動有効化する基本手順

一括展開向け：PowerShell（wevtutil）で CAPI2 ログを有効化する

有効化＋最大ログサイズ＋「必要に応じて上書き」設定（推奨例）

調査後に無効化するスクリプト例

Intune / SCCM 配布時の実務ポイント

レジストリで CAPI2 ログを有効化する（GPO 配布・端末管理向け）

.reg ファイル例（有効化＋100MB＋上書き運用）

ログを「特定フォルダーに保存」したい場合の現実解

任意フォルダーへエクスポートする（推奨）

定期エクスポートをスケジュールタスクで回す例

「最大ログサイズ」「上書き」「バックアップ」の考え方（設定の選び方）

CAPI2 で特に見たいイベントと、読むときのコツ

代表的なイベント ID と見るべきポイント

PowerShell で「必要な ID と時間帯」だけ抜き出す

証明書消失の切り分けを速くする「現場向けチェックリスト」

証明書が消える可能性のある原因候補（深掘りアイデア）

グループポリシー（GPO）の設定・競合・適用不備

サードパーティ製ソフト（EDR/VPN/管理エージェント）の影響

Windows 更新・暗号基盤周りの変化

ユーザープロファイル（TEMPプロファイル、再作成、プロファイルコンテナ）の問題

失効確認（CRL/OCSP）到達性・時刻ずれ

証明書ストアの破損・整合性エラー

併用すると原因特定が速くなる関連ログ

現場で回る調査フロー（ログ有効化→収集→比較→原因特定）

少数端末でパイロット収集

証明書の“スナップショット”を残して差分を見る

GPO とソフトウェア差分を“同じ観点”で並べる

まとめ：CAPI2 ログで「誰が・いつ・何をしたか」に近づく

この記事を書いた人

コメント

コメントするコメントをキャンセル

Windows 10/11で内部証明書が消える原因調査：CAPI2ログ有効化と一括収集（PowerShell・レジストリ）

内部証明書が「消えた」に見えるときに最初に確認したいこと

CAPI2 Operational ログとは（なぜ有効化すると効くのか）

イベントビューアーで手動有効化する基本手順

一括展開向け：PowerShell（wevtutil）で CAPI2 ログを有効化する

有効化＋最大ログサイズ＋「必要に応じて上書き」設定（推奨例）

調査後に無効化するスクリプト例

Intune / SCCM 配布時の実務ポイント

レジストリで CAPI2 ログを有効化する（GPO 配布・端末管理向け）

.reg ファイル例（有効化＋100MB＋上書き運用）

ログを「特定フォルダーに保存」したい場合の現実解

任意フォルダーへエクスポートする（推奨）

定期エクスポートをスケジュールタスクで回す例

「最大ログサイズ」「上書き」「バックアップ」の考え方（設定の選び方）

CAPI2 で特に見たいイベントと、読むときのコツ

代表的なイベント ID と見るべきポイント

PowerShell で「必要な ID と時間帯」だけ抜き出す

証明書消失の切り分けを速くする「現場向けチェックリスト」

証明書が消える可能性のある原因候補（深掘りアイデア）

グループポリシー（GPO）の設定・競合・適用不備

サードパーティ製ソフト（EDR/VPN/管理エージェント）の影響

Windows 更新・暗号基盤周りの変化

ユーザープロファイル（TEMPプロファイル、再作成、プロファイルコンテナ）の問題

失効確認（CRL/OCSP）到達性・時刻ずれ

証明書ストアの破損・整合性エラー

併用すると原因特定が速くなる関連ログ

現場で回る調査フロー（ログ有効化→収集→比較→原因特定）

少数端末でパイロット収集

証明書の“スナップショット”を残して差分を見る

GPO とソフトウェア差分を“同じ観点”で並べる

まとめ：CAPI2 ログで「誰が・いつ・何をしたか」に近づく

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル