パッケージの発行元が同じでも、署名に使う証明書が変わると、受け入れ側の設定を見直す必要があります。Microsoft の NuGet パッケージで署名者を制限している環境は、今回その対象になる可能性があります。

Microsoft は、2026年9月23日から新しい作成者署名証明書への切り替えを開始すると告知しました。気になるのは、自分たちの CI で対応が必要なのか、そして過去のパッケージも引き続き復元できるのか、という点ですね。

判断の軸は、Microsoft の証明書をどこで指定しているかです。署名の仕組みから設定箇所をたどり、検証の条件を保ったまま新証明書を追加する手順を整理します。

作成者署名を固定すると証明書の更新が復元に関わる

NuGet の作成者署名は、署名後にパッケージが改変されていないことを確かめ、発行元の真正性を検証するためのものです。一方、リポジトリ署名はリポジトリ側が付ける署名で、nuget.org へアップロードされたパッケージには自動で付与されます。この区別は NuGet の署名仕様で説明されています。

今回切り替わるのは Microsoft の作成者署名証明書です。Microsoft を信頼する設定でも、実際には証明書のフィンガープリントを列挙している場合、新しい証明書は許可済みの値に一致しません。

対応対象は、Microsoft を含む信頼済み署名者の許可リストを NuGet クライアントで適用している環境と、dotnet nuget verify で Microsoft の証明書を指定している環境です。どちらも使っていなければ、この更新による影響はない見込みと更新告知で案内されています。

つまり、最初に見るべきなのはアプリのコードではなく、パッケージの受け入れ条件です。

CI が読む設定と証明書を指定するスクリプトをたどる

nuget.config では、signatureValidationMode が require になっているか、trustedSigners の author に Microsoft の証明書が登録されているかを見ます。require は、信頼した証明書で署名されたパッケージを要求する設定です。信頼境界の設定方法に、この組み合わせが示されています。

ただし、リポジトリ直下のファイルだけでは判断できません。NuGet はコンピューター、ユーザー、ソリューションなどの設定を組み合わせます。設定の適用規則を踏まえ、CI の実行ユーザーや、コマンドで明示している設定ファイルまでたどりたいところです。

もう一つの確認先はビルド・配布用スクリプトです。dotnet nuget verify と --certificate-fingerprint を探し、既存の Microsoft 証明書だけを列挙していないかを調べます。設定ファイルとスクリプトの両方で指定していれば、更新箇所も両方になります。

旧証明書を残し、Microsoft の許可リストへ新証明書を追加する

既存パッケージの署名は、切り替え後も古い証明書のまま残ります。そのため、対応は新証明書の追加です。古い証明書を一括で削除すると、以前のパッケージを受け入れる条件まで失ってしまいます。

設定ファイルを直接編集する場合は、既存の trustedSigners 内にある Microsoft の author 要素へ、次の certificate 要素を追加します。これは追加する要素だけの例で、nuget.config 全体を置き換えるものではありません。

<certificate
  fingerprint="9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630"
  hashAlgorithm="SHA256"
  allowUntrustedRoot="false" />

フィンガープリントは更新告知に記載された SHA-256 値です。author は複数の certificate を持てるため、既存の値を維持したまま追加できます。属性の意味と構造は nuget.config リファレンスで確認できます。

検証スクリプトでは、既存の --certificate-fingerprint 引数を残し、新しい値をもう一つ加えます。次は、告知が挙げる新旧4個の値を許可する例です。./package.nupkg は検証対象のファイルに置き換えます。

dotnet nuget verify "./package.nupkg" --certificate-fingerprint 3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE --certificate-fingerprint AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27 --certificate-fingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353 --certificate-fingerprint 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

dotnet nuget verify のリファレンスでは、このオプションを複数回指定すると、指定した SHA-256 フィンガープリントのいずれかに署名証明書が一致するかを検証すると説明されています。新しい値だけに絞らないことが、過去のパッケージとの互換性につながります。

新旧パッケージの検証で CI の受け入れ条件を確かめる

更新後は、新証明書で署名されたパッケージと、以前から利用している旧証明書のパッケージを用意し、CI と同じ設定で復元・検証することを勧めます。dotnet nuget verify の出力には作成者・リポジトリの署名種別と SHA-256 値が表示されるので、パッケージの公開時期だけで新旧を推測せず、実際の署名を見て対象を選べます。

署名の不一致が残る場合は、エラーコードだけで原因を決めつけず、メッセージと適用中の許可リストを照合します。NU3034 の説明には、フィンガープリントの不一致に加えて、許可リストがない場合なども挙げられています。

今回の対応が必要かどうかは、Microsoft の証明書を受け入れ条件として固定しているかで判断できます。必要な環境では、新旧のパッケージが通ることまで確かめて初めて、証明書の追加が運用に反映されたと分かります。許可する署名者を管理する方針を保ちながら、証明書の世代交代を受け入れる作業です。

出典

• Title: Microsoft is updating its author-signing certificate starting September 23, 2026
• URL: https://devblogs.microsoft.com/dotnet/microsoft-author-signing-certificate-update-2026/