Microsoft is updating its author-signing certificate starting September 23, 2026 - .NET Blog

, "articleBody": "背景：一張憑證為何會影響套件安裝\n\nNuGet 是 .NET 生態系取得函式庫與工具的主要管道，開發者透過它把大量第三方與官方套件拉進專案。為了讓使用端能確認某個套件確實出自宣稱的發佈者、且內容在傳輸與保存過程中沒有被動過，NuGet 支援套件簽章機制。Microsoft 對自家發佈的 NuGet 套件採用的是作者簽章（author signing），也就是由套件作者本身以憑證證明「這個套件是我發的」。這裡使用的憑證屬於 X.509 標準，它是一種公開金鑰基礎建設格式，把一組金鑰與某個身分綁在一起，並由憑證授權單位簽發，同時帶有有效期限。憑證並非永久有效，定期輪替是資訊安全上的常態作法，用意是限制金鑰外洩或演算法弱化後可被濫用的時間範圍。\n\n問題在於，許多組織並不是被動接受簽章，而是採取更嚴格的做法：在 NuGet 用戶端設定政策，要求套件必須有簽章，並且只信任一份事先列好的簽署者允許清單。允許清單的比對方式通常是把憑證的 SHA-256 指紋寫進設定檔，指紋一旦不符就不接受。這種做法能有效防止來源遭替換，但同時也讓憑證輪替變成一件需要人為介入的事。只要發佈方換了憑證，而使用端的清單沒有跟著更新，原本可以正常安裝的套件就會突然被拒絕。\n\n核心內容：2026 年 9 月 23 日的憑證切換\n\n根據 .NET 官方部落格由 NuGet 團隊發布的公告，自 2026 年 9 月 23 日起，一張新的憑證將成為 Microsoft 對 NuGet 套件進行作者簽章的預設憑證。轉換的範圍僅限於「未來簽署的新套件」：過去已經用舊憑證簽署的套件，其簽章會原樣保留，不會被撤銷或重新簽署；但在切換之後，目前使用的憑證不再用於簽署新發佈的套件。\n\n公告中明確列出兩組指紋。現行憑證的 SHA-256 指紋是 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353，新憑證的 SHA-256 指紋是 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630。值得注意的是，在官方示範的信任清單中，Microsoft 這個作者項目底下其實已經存在三組指紋，分別是 3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE、AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27，以及上面提到的現行指紋。這說明憑證輪替並非首次發生，而每一次輪替都會對採用指紋鎖定策略的使用端造成同樣的維護需求。\n\n受影響的兩種情境\n\n第一種情境是使用 NuGet 用戶端政策來強制執行信任簽署者允許清單，且清單中包含 Microsoft。判斷方式是在 nuget.config 中尋找兩個要素：一個是 signatureValidationMode 設為 require，代表簽章驗證為強制模式；另一個是 trustedSigners 區段中存在 name 為 Microsoft 的 author 項目，其下以 certificate fingerprint 屬性列出可接受的憑證指紋，並搭配 hashAlgorithm 為 SHA256 以及 allowUntrustedRoot 設定。allowUntrustedRoot 若為 false，表示憑證鏈的根憑證本身也必須是被信任的，不能任意放行自簽或來源不明的根。需要留意的是，nuget.config 可能同時存在於多個位置，各自帶有不同的作用範圍，因此只看單一檔案不一定能掌握全貌。\n\n第二種情境是在流程中使用 dotnet nuget verify 指令，明確指定一或多個 certificate fingerprint 參數來確認套件確實由 Microsoft 作者簽章。這類呼叫通常會把既有的幾個指紋一併列出，只要其中一組與套件簽章相符即通過驗證。上述兩種情境以外的使用者，原則上不受這次憑證更新影響；以新憑證簽署的 Microsoft NuGet 套件，安裝方式與舊憑證簽署的套件並無不同。\n\n實務處理：把新指紋加進清單，並保留舊指紋\n\n對於採用用戶端政策的使用者，處理重點是盡快把新憑證加入允許清單，同時不要把舊憑證移除。保留舊憑證的原因是，舊套件仍帶著舊簽章，若清單只留新指紋，反而會讓既有套件無法安裝。若未更新信任清單就嘗試安裝以新憑證簽署的套件，安裝會失敗並回報 NU3034 錯誤，這個錯誤碼代表套件並非由信任清單中的簽署者所簽署。\n\n更新方式有兩種。其一是使用 dotnet nuget trust 指令，指定 author 為 Microsoft、帶入新指紋並指定演算法為 SHA256，這個指令在 .NET 6 SDK 及之後的版本提供，會直接更新適用的 nuget.config；若需要指定特定設定檔，可加上 --configfile 參數指向目標路徑。其二則是手動編輯 nuget.config，在既有的 Microsoft author 項目中加入新指紋，讓該項目同時包含三組舊指紋與新指紋。若組織內部透過版本控制或組態管理工具派送設定，手動編輯通常更容易控管變更內容與審核流程。\n\n至於使用 dotnet nuget verify 的流程，做法是在指令中追加新的 --certificate-fingerprint 參數，並保留原有的三組指紋。由於每一個參數都是「可接受的簽署者憑證指紋」之一，四組並存可以讓同一道指令同時驗證新簽署的套件與仍以舊憑證簽署的既有套件，避免在過渡期間出現驗證結果不一致。\n\n影響與限制\n\n這次變更的實質影響集中在「信任被寫死」的環節。對一般直接從 nuget.org 安裝套件的開發者而言，感受不到差異；但對需要通過內部軟體供應鏈審查、或在隔離環境建置的團隊來說，信任政策是安全防線的一部分，憑證輪替就必須被當成一次組態變更來處理。切換時間點公告在 2026 年 9 月 23 日，屬於可預期的時間窗，提前部署可避免在轉換當下才發現建置中斷。\n\n有幾點限制需要理解。第一，舊套件的簽章不會因為輪替而失效，因此「舊套件仍可安裝」與「新套件需要新指紋」是兩件必須同時滿足的事，這也是為何官方建議保留而非替換。第二，nuget.config 的多層級特性代表同一台機器或同一條 CI 流程可能套用到多份設定，只改其中一份未必足夠，需要逐一確認實際生效的範圍。第三，若驗證流程使用 allowUntrustedRoot 為 false 的設定，憑證鏈的根是否受信任仍是獨立條件，加入指紋並不會放寬這一層檢查。若對自身是否受影響有疑問，或在依步驟調整時遇到問題，官方公告提供了聯絡管道；一般性的 NuGet 意見與建議，則可透過 NuGet/Home 儲存庫的討論區或問題回報流程提出。\n\n本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。" }