GitHubの公式ドキュメント更新「Update dotnet nuget verify docs for CRL and OCSP URL verbosity output」を見て、すぐにCI設定やネットワーク許可リストを変えるべきか迷っているなら、結論は明確です。この更新は一度マージされたものの、同日にリバートされているため、現時点では「dotnet nuget verifyでCRL URL/OCSP URLが正式に出力される」と決めつけないでください。 対応すべきことは、公式ドキュメントの差分だけで判断せず、利用中の.NET SDK、NuGetの実際の出力、CI/CD環境のログを確認することです。(GitHub)
今回の話題はGitHub上のdotnet/docsリポジトリにあるMicrosoft Learn向けドキュメント更新です。GitHubそのものの機能追加ではなく、.NET CLIのdotnet nuget verifyコマンドに関する説明変更として理解すると、運用影響を正しく切り分けられます。現在のMicrosoft Learnページでは、dotnet nuget verifyは署名付きNuGetパッケージを検証するコマンドとして説明され、verbosityの表にもCRL URL/OCSP URLの行は掲載されていません。(Microsoft Learn)
GitHubの公式ドキュメント更新「Update dotnet nuget verify docs for CRL and OCSP URL verbosity output」で何が変わったか
2026年4月28日にマージされたdotnet/docsのコミット44ff8c0では、docs/core/tools/dotnet-nuget-verify.mdに対して、dotnet nuget verifyのverbosity出力表を更新する変更が入っていました。主な内容は、Author/Repository証明書とTimestamp証明書について、CRL URLとOCSP URLがどのverbosityで表示されるかを表に追加するものです。対象行には「.NET SDK 10.0.300以降が必要」という脚注も追加されていました。(GitHub)
ただし、重要なのはその後です。同じ2026年4月28日に、このドキュメント更新を戻すPRがマージされました。リバート理由として、実装自体がリリース前に戻されていたことが説明されています。つまり、最初のドキュメント更新だけを見て「10.0.300以降なら必ずCRL URL/OCSP URLが出る」と判断するのは危険です。(GitHub)
| 確認項目 | 一度追加された内容 | 現時点での実務判断 |
|---|---|---|
| Author/Repository Certificate | CRL URL、OCSP URLの表示行 | 現行ドキュメントでは反映済み仕様として扱わない |
| Timestamp Certificate | CRL URL、OCSP URLの表示行 | 実際のSDK出力で確認する |
| verbosity | normal、detailed、diagnosticで表示される想定 | 公式ページと実行結果の両方を見る |
| バージョン注記 | .NET SDK 10.0.300以降が必要という脚注 | リバート済みのため移行条件として採用しない |
| 運用対応 | ログ、監査、ネットワーク確認に使える可能性 | 先に検証環境で再現性を確認する |
まず押さえるべき結論：これはGitHub機能の変更ではなく、dotnet/docsのドキュメント差分
今回の更新名にGitHubが絡むため、GitHub ActionsやGitHub Enterpriseの仕様変更と誤解しやすいですが、実体はGitHub上で管理されているdotnet/docsリポジトリのドキュメント更新です。GitHubのUI、リポジトリ権限、Actionsのワークフロー仕様が変わったわけではありません。
影響を受ける可能性があるのは、主に次のようなチームです。
| 読者・担当者 | 関係する理由 | まず確認すべきこと |
|---|---|---|
| .NET開発者 | NuGetパッケージ署名の検証結果を確認する | ローカルSDKでdotnet nuget verifyの出力を確認する |
| GitHub Actions運用者 | CI上でNuGet検証を実行している可能性がある | ワークフローのSDKバージョンとログ出力を確認する |
| クラウド管理者 | CRL/OCSPの宛先がネットワーク制御に関係する | 許可リストを即変更せず、実通信と監査ログを見る |
| ソリューションアーキテクト | サプライチェーンセキュリティ設計に関係する | パッケージ署名検証の位置づけを整理する |
| 技術意思決定者 | SDK更新やCI標準化の判断に関係する | 「仕様確定」ではなく「差分確認事項」として扱う |
CRL URLとOCSP URLとは何か
CRLとOCSPは、証明書が失効していないかを確認するために使われる仕組みです。NuGetパッケージの署名検証では、署名者やタイムスタンプの証明書が有効かどうかを確認する必要があります。
CRLはCertificate Revocation Listの略で、失効した証明書の一覧を取得する方式です。OCSPはOnline Certificate Status Protocolの略で、証明書の状態をオンラインで問い合わせる方式です。どちらも、証明書チェーンの検証や失効確認に関係します。
NuGet側の元の課題では、NuGetがなぜHTTPのURLへアクセスするのか、また証明書失効確認に使われるURLを見つけにくいことが問題として説明されていました。CRL URL/OCSP URLがdotnet nuget verifyの出力に表示されれば、ファイアウォール、プロキシ、監査ログの調査がしやすくなるという狙いがあります。(GitHub)
ただし、表示されるURLは「検証で参照され得るURL」を理解するための情報です。出力にURLがあることと、そのビルド実行中に必ず通信が発生したことは同じではありません。実際の通信有無は、OS、証明書ストア、キャッシュ、ネットワーク設定、失効確認モードによって変わる可能性があります。
なぜ今回の更新は運用チームが確認すべきなのか
今回のドキュメント更新が注目される理由は、単なる表記修正に見えて、CI/CD、証明書検証、ネットワーク制御、監査対応にまたがるためです。
特に企業環境では、ビルドサーバーやGitHub Actionsのセルフホステッドランナーが外部通信を制限されていることがあります。NuGetパッケージの署名検証でCRLやOCSPのエンドポイントが必要になる場合、プロキシ設定や証明書検証の失敗がビルドエラーとして表面化することがあります。
一方で、今回のCRL/OCSP URL出力に関する実装は、NuGet.Client側で一度マージされた後、「新しい出力を無効化する手段がない」という理由でリバートされています。したがって、運用チームは「出力が増える前提」でログパーサーや監査手順を変えるのではなく、まず実際に使っているSDKとCI環境で出力を確認すべきです。(GitHub)
現在のdotnet nuget verifyで確認できること
Microsoft Learnの現行説明では、dotnet nuget verifyは署名付きNuGetパッケージを検証するコマンドです。--all、--certificate-fingerprint、--verbosity、--configfileなどのオプションがあり、verbosityはquiet、minimal、normal、detailed、diagnosticを指定できます。デフォルトはminimalです。(Microsoft Learn)
基本的な確認コマンドは次のとおりです。
dotnet nuget verify ./path/to/package.nupkg出力レベルを変えて確認する場合は、次のように実行します。
dotnet nuget verify ./path/to/package.nupkg -v minimal
dotnet nuget verify ./path/to/package.nupkg -v normal
dotnet nuget verify ./path/to/package.nupkg -v detailed
dotnet nuget verify ./path/to/package.nupkg -v diagnostic特定の署名者証明書のSHA-256フィンガープリントと照合したい場合は、次の形式を使います。
dotnet nuget verify ./path/to/package.nupkg --certificate-fingerprint <SHA256-FINGERPRINT>CI/CDで使う場合は、diagnosticを常用するより、通常はminimalまたはnormalを基準にし、障害調査時だけdetailedやdiagnosticを使うほうが現実的です。詳細ログは調査に役立つ一方、ログ量が増え、パッケージ名、ローカルパス、証明書情報などが広く残る可能性があります。
GitHub ActionsやCIでの確認手順
GitHub Actions、Azure Pipelines、Jenkins、GitLab CIなどで.NETビルドを運用している場合、確認すべきポイントは「公式ドキュメントに何が書かれているか」だけではありません。実際にワークフローで使われるSDKバージョン、実行OS、プロキシ設定、ログ保存期間まで含めて見る必要があります。
| 手順 | 確認内容 | 判断ポイント |
|---|---|---|
| SDKバージョンを確認 | dotnet --infoをCI上で実行する | ローカルとCIでSDKが違う場合、出力も変わる可能性がある |
| verifyコマンドを実行 | dotnet nuget verifyを対象パッケージで実行する | CRL URL/OCSP URLが実際に出るか確認する |
| verbosityを変える | normal、detailed、diagnosticを比較する | ログ量と必要情報のバランスを見る |
| ネットワークログを見る | プロキシ、FW、DNS、監査ログを確認する | 表示URLと実通信を混同しない |
| ワークフローを固定する | SDKバージョンを明示する | ランナー更新による出力差分を抑える |
| 監査手順に反映 | Runbookや証跡取得手順を更新する | 実出力が確認できてから文書化する |
GitHub Actionsで確認用ステップを入れるなら、次のような形が分かりやすいです。
- name: Show .NET SDK info
run: dotnet --info
- name: Verify NuGet package signature
run: dotnet nuget verify ./artifacts/example.nupkg -v normalパッケージが複数ある場合は、対象を絞って検証することをおすすめします。すべての.nupkgに対してdiagnosticを使うと、ログが大きくなり、必要な情報が埋もれます。
運用影響を判断するチェックポイント
今回のGitHub公式ドキュメント更新を受けて、開発・運用チームが見るべきポイントは次の5つです。
.NET SDKのバージョンを固定しているか
CIでSDKバージョンを曖昧にしていると、ランナーイメージの更新やセットアップアクションの設定変更により、ある日突然出力が変わることがあります。global.jsonやCIのセットアップステップでSDKバージョンを明示しているか確認しましょう。
特に、署名検証や監査証跡をリリース判定に使っている場合、SDKバージョンの差分は「単なる環境差」ではなく、検証結果の再現性に関わります。
ログパーサーが人間向け出力に依存していないか
dotnet nuget verifyの出力を正規表現で解析し、成功・失敗・証明書情報を抽出している場合は注意が必要です。人間向けのCLI出力は、将来的に項目追加や表記変更が起こる可能性があります。
避けたい実装例は、次のようなものです。
「SHA256 hash:」の次の行数が固定だと仮定する
「Timestamp:」の直後に必ず特定の項目が来ると仮定する
出力行数が変わったら失敗扱いにする実務では、終了コード、明確な成功メッセージ、対象パッケージ、検証コマンド、SDKバージョンをセットで保存し、詳細な証明書項目は補助情報として扱うほうが堅実です。
CRL/OCSPのURLをそのまま許可リストに入れていないか
CRL URLやOCSP URLが表示されたとしても、表示されたURLを無条件に許可リストへ入れるのは避けるべきです。証明書発行局、証明書チェーン、パッケージ署名者、タイムスタンプ局によってURLは変わる可能性があります。
ネットワーク管理では、次の順序で判断すると失敗しにくくなります。
| 判断順 | やること | 理由 |
|---|---|---|
| 1 | 対象パッケージと署名者を確認する | どの証明書チェーンが関係するかを把握する |
| 2 | 実通信ログを確認する | CLI出力と実際の通信を区別する |
| 3 | CAや証明書ポリシーを確認する | 許可すべき宛先の妥当性を見る |
| 4 | 最小限の範囲で許可する | 過剰な外部通信許可を避ける |
| 5 | 定期的に見直す | 証明書更新で宛先が変わる可能性がある |
失効確認の失敗を「GitHub障害」と誤認していないか
GitHub Actions上でビルドが失敗すると、ついGitHub側の問題と考えがちです。しかし、NuGetパッケージ署名の検証失敗は、GitHub Actionsそのものではなく、SDK、証明書ストア、プロキシ、DNS、失効確認先への通信、企業ネットワークポリシーに起因することがあります。
切り分けでは、同じコマンドを次の環境で比較します。
dotnet --info
dotnet nuget verify ./path/to/package.nupkg -v normal比較対象は、ローカルPC、社内ビルドサーバー、GitHubホステッドランナー、セルフホステッドランナーです。どこでだけ失敗するかを見ると、原因の範囲を絞り込めます。
リバート済みの脚注を移行計画に使っていないか
今回の更新で一度追加された「.NET SDK 10.0.300以降が必要」という注記は、リバートされたドキュメント更新に含まれていたものです。そのため、現時点で「10.0.300へ上げればCRL/OCSP URLが出る」と断定して移行計画を作るのは避けるべきです。(GitHub)
移行準備としては、特定バージョンへの更新を前提にするより、次の条件がそろった時点で本格対応するのが安全です。
| 条件 | 対応判断 |
|---|---|
| 公式ドキュメントにCRL/OCSP URL出力が再掲載される | Runbook更新を検討する |
| NuGet.Client側で実装が再導入される | 検証環境で出力差分を確認する |
| SDKリリースノートで該当機能が明記される | CIのSDK更新計画に入れる |
| 自社CIで実際に出力が変わる | ログ・監査・パーサーを更新する |
セキュリティ監査での使い方
CRL URL/OCSP URLの可視化が将来的に正式提供された場合、最も役立つのはセキュリティ監査と障害調査です。
たとえば、監査担当者から「このNuGetパッケージの署名検証では、どの証明書チェーンを見ているのか」「失効確認に関係する外部宛先は何か」と聞かれた場合、dotnet nuget verifyの詳細出力を証跡の一部として使える可能性があります。
ただし、注意すべき点があります。CRL URL/OCSP URLの表示は、失効確認の成功を完全に証明するものではありません。監査証跡としては、少なくとも次の情報をセットで残すべきです。
| 証跡 | 残す理由 |
|---|---|
| 実行日時 | いつ検証したかを示す |
| 実行環境 | OS、ランナー、SDKバージョンの差分を説明できる |
| 実行コマンド | どのverbosity、どのパッケージを検証したかを示す |
| 終了コード | 検証が成功したかを機械的に確認する |
| 出力ログ | 証明書情報や署名種別を確認する |
| ネットワークログ | 実際の通信有無を補強する |
開発者が今すぐやるべきこと
今回の更新を見た開発者が、最初にやるべきことは大がかりな移行ではありません。自分のプロジェクトでNuGetパッケージ署名検証をどの程度使っているかを確認することです。
まず、CIやリリース手順に次のようなコマンドが含まれているか検索します。
dotnet nuget verify
nuget verify
--certificate-fingerprint
-v detailed
-v diagnostic含まれていない場合、今回のドキュメント差分による直接の影響は小さいと考えられます。ただし、サプライチェーンセキュリティを強化したいプロジェクトでは、署名検証をどこで行うかを検討するきっかけになります。
すでにdotnet nuget verifyを使っている場合は、次の3点を確認してください。
| 確認項目 | 具体的な見方 |
|---|---|
| SDKバージョン | dotnet --infoでCIとローカルを比較する |
| 出力差分 | minimal、normal、detailedでログを比較する |
| 失敗時の扱い | 検証失敗がビルド停止、警告、監査記録のどれになるか確認する |
クラウド管理者・ネットワーク管理者が注意すべきこと
クラウド管理者にとって重要なのは、CRL/OCSPのURLが「セキュリティ上怪しい通信」ではなく、証明書失効確認に関係する可能性がある点です。NuGetの課題でも、NuGetがなぜHTTPを使うのかという問い合わせがあること、検証に使われるURLを見つけにくいことが背景として挙げられています。(GitHub)
ただし、HTTPという文字列だけを見て遮断すると、署名検証や証明書チェーン検証で問題が起きる場合があります。逆に、全てを許可すると外部通信制御が緩くなります。
現実的には、次のように段階的に対応します。
- 失敗しているビルドのログを確認する
dotnet --infoでSDKとOSを確認する- 同じパッケージを検証環境で再現する
- プロキシやファイアウォールの拒否ログを見る
- 証明書チェーンとCAを確認する
- 必要な宛先だけを一時許可し、再検証する
- 恒久対応として許可範囲と理由を文書化する
CRL/OCSP関連の通信は、パッケージ取得先であるNuGet.orgへの通信とは別に考える必要があります。パッケージをダウンロードできるのに署名検証で失敗する場合、失効確認先への通信が切り分けポイントになることがあります。
ソリューションアーキテクトが設計に反映すべき観点
ソリューションアーキテクトは、今回の更新を「出力項目が増えるかどうか」だけで見るのではなく、ソフトウェアサプライチェーン全体の設計として捉えるべきです。
NuGetパッケージの利用には、パッケージソース、署名検証、ロックファイル、CIでの再現性、証明書検証、監査証跡が関わります。dotnet nuget verifyはその一部であり、単独で全てのリスクを解消するものではありません。
設計上は、次のように役割を分けると整理しやすくなります。
| 領域 | 目的 | 代表的な確認 |
|---|---|---|
| パッケージ取得 | 信頼できるソースから取得する | NuGetソース、社内フィード、プロキシ |
| バージョン固定 | 依存関係の再現性を保つ | lock file、CIの復元結果 |
| 署名検証 | パッケージ署名の妥当性を見る | dotnet nuget verify |
| 証明書検証 | 署名者やタイムスタンプの信頼性を見る | 証明書チェーン、失効確認 |
| 監査証跡 | 後から説明できる状態にする | 実行ログ、SDKバージョン、承認履歴 |
今回のCRL/OCSP URL出力は、このうち「証明書検証」と「監査証跡」を補助する情報です。表示されるようになった場合でも、パッケージの安全性を単独で保証するものではありません。
失敗しやすいポイント
今回のような公式ドキュメント更新で、特に失敗しやすいのは次のパターンです。
| 失敗パターン | 何が問題か | 回避策 |
|---|---|---|
| マージ済みPRだけを見て仕様確定と判断する | リバートや実装側の変更を見落とす | 関連PR、Issue、現行Docsを確認する |
| SDKバージョン注記をそのまま移行条件にする | リバート済み注記の可能性がある | 実機で出力を確認する |
| 表示URLを通信実績と混同する | 監査やネットワーク判断を誤る | プロキシやFWログで裏取りする |
diagnosticログを常時有効にする | ログ量が増え、必要情報が埋もれる | 障害調査時だけ使う |
| CLI出力を固定行でパースする | 項目追加で壊れる | 終了コードと明確なキーワードを中心に扱う |
| GitHub Actionsの問題と決めつける | 原因がSDKや証明書検証側にある可能性を見落とす | ローカル、CI、別ランナーで比較する |
今後の更新を追うときの見方
今回のようなケースでは、1つのコミットだけを見ると判断を誤ります。確認すべき順序は次のとおりです。
- Microsoft Learnの現行ページを見る
- GitHubの
dotnet/docsで該当PRとリバート有無を見る - NuGet.Client側の実装PRとリバート有無を見る
- NuGet/HomeのIssueで背景と未解決事項を見る
- 自社環境のSDK出力で再現する
特に、今回の関連情報では、ドキュメント更新PRがマージされた後にリバートされ、NuGet.Client側の実装も「opt-outがない」という理由で戻されています。仕様確認では、ドキュメントと実装の両方を追う必要があります。(GitHub)
まとめ：今は移行ではなく、確認手順の整備が最優先
GitHubの公式ドキュメント更新「Update dotnet nuget verify docs for CRL and OCSP URL verbosity output」は、NuGetパッケージ署名検証の透明性を高める可能性がある重要なテーマです。しかし、今回のドキュメント更新は同日にリバートされており、現時点では正式な出力仕様として扱うべきではありません。
開発者、クラウド管理者、ソリューションアーキテクトが今すぐ行うべきことは、CIやローカル環境でdotnet nuget verifyを使っているか確認し、SDKバージョン、verbosity、ログ保存、ネットワーク制御、監査証跡の扱いを整理することです。
特にGitHub Actionsで.NETビルドを運用している場合は、SDKバージョンを明示し、dotnet --infoとdotnet nuget verifyの出力を同じログで確認できるようにしておくと、今後CRL URL/OCSP URLの出力が正式に導入されたときにもスムーズに対応できます。
最終的な判断基準はシンプルです。公式ページ、実装PR、リバート履歴、自社環境の実行結果の4つがそろってから、運用ルールを変更する。 これが、今回の更新を安全に扱うための最も実務的な対応です。
コメント