ถ้าโปรเจกต์ของคุณติดตั้งแพ็กเกจ NuGet ตามปกติ การเปลี่ยนใบรับรองครั้งนี้อาจไม่ต้องทำอะไร แต่ถ้าองค์กรตั้งนโยบายให้รับเฉพาะแพ็กเกจที่ Microsoft เซ็น หรือ CI ตรวจ fingerprint ของผู้เซ็นไว้ตายตัว ควรตรวจการตั้งค่าตอนนี้: Microsoft ประกาศเมื่อ 23 กันยายน 2026 ว่าจะเริ่มใช้ใบรับรองใหม่สำหรับการเซ็นแพ็กเกจ โดยอาจเริ่มเป็นค่าหลักตั้งแต่วันเดียวกัน ประกาศของทีม NuGet
ประเด็นไม่ใช่ว่าแพ็กเกจเดิมใช้ไม่ได้ ลายเซ็นของแพ็กเกจที่เซ็นด้วยใบรับรองเก่ายังคงอยู่ สิ่งที่เปลี่ยนคือแพ็กเกจใหม่หลังช่วงเปลี่ยนผ่านอาจถูกเซ็นด้วยใบรับรองคนละใบ หาก allowlist ในเครื่องหรือ pipeline รู้จักแต่ fingerprint เก่า การติดตั้งอาจหยุดด้วยข้อผิดพลาด NU3034 ตามที่ Microsoft ระบุ แหล่งต้นทาง
ใครต้องตรวจ และใครไม่น่ากระทบ
| วิธีใช้ NuGet | สิ่งที่ควรทำ |
|---|---|
| ใช้ค่าปกติ ไม่มีนโยบาย trusted signers และไม่ได้ระบุ fingerprint ในคำสั่ง verify | โดยทั่วไปไม่ต้องปรับค่าเพราะการเปลี่ยนใบรับรองนี้ |
nuget.config ตั้ง signatureValidationMode=require และมี <trustedSigners> สำหรับ Microsoft | เพิ่ม SHA-256 fingerprint ใหม่ในรายการของ Microsoft โดย คงค่าเก่าไว้ |
CI เรียก dotnet nuget verify พร้อม --certificate-fingerprint | เพิ่ม fingerprint ใหม่ในคำสั่งตรวจ โดยคงค่าของใบรับรองเก่าไว้สำหรับแพ็กเกจเดิม |
แผนภาพต่อไปนี้แสดงเฉพาะการตัดสินใจของนโยบาย trusted signers ไม่ใช่การรับรองว่าแพ็กเกจจะติดตั้งผ่านเงื่อนไขอื่นทุกข้อ รูปแบบนโยบายในเอกสาร NuGet
ใบรับรองที่เปลี่ยนคือ author-signing certificate ของแพ็กเกจ Microsoft ไม่ใช่คำสั่งให้ปิดการตรวจลายเซ็นหรือยอมรับทุกผู้เซ็น การอนุญาตใบใหม่โดยคงใบเก่าไว้ช่วยให้ตรวจได้ทั้งแพ็กเกจที่เซ็นก่อนและหลังช่วงเปลี่ยนผ่าน ประกาศของทีม NuGet
เช็กระบบของตัวเองทีละขั้น
1. หาจุดที่บังคับนโยบาย ตรวจ nuget.config ที่ใช้ใน repository, CI และระดับผู้ใช้หรือเครื่อง โดยมองหา signatureValidationMode และ trustedSigners ไฟล์เหล่านี้อาจมีหลาย scope จึงอย่าตรวจเฉพาะไฟล์ใน repo แล้วสรุปว่าระบบทั้งหมดไม่กระทบ โครงสร้างและ scope ของ nuget.config
2. ถ้า trusted signers จำกัดผู้เซ็น Microsoft ให้เพิ่มค่าใหม่ SHA-256 fingerprint ที่ Microsoft เผยแพร่คือ 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 ตรวจค่าเทียบกับ ประกาศต้นทาง ก่อนคัดลอกลงระบบจริง จากนั้นใช้คำสั่งนี้กับ config ที่ต้องการ:
dotnet nuget trust author Microsoft 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 --algorithm SHA256คำสั่ง dotnet nuget trust มีใน .NET 6 SDK ขึ้นไป และเลือกไฟล์เฉพาะด้วย --configfile <Path> ได้ อย่าลบ fingerprint เดิมเพียงเพื่อให้ไฟล์ดูสะอาด เพราะแพ็กเกจเก่าที่เซ็นไว้แล้วยังต้องผ่านนโยบายเดิม เอกสารคำสั่ง, คำแนะนำของ Microsoft
3. ตรวจคำสั่งใน pipeline ถ้า CI ใช้ dotnet nuget verify <PackagePath> --certificate-fingerprint ... ให้เพิ่ม fingerprint ใหม่เป็นอีกหนึ่ง option ไม่แทนค่าทั้งชุดเดิม ตัวอย่างคำสั่งเต็มสำหรับใบรับรอง Microsoft ทั้งเก่าและใหม่อยู่ใน ประกาศต้นทาง การแก้เฉพาะเครื่องนักพัฒนาแต่ไม่แก้ pipeline อาจทำให้ restore ผ่านในเครื่องแต่ verify ไม่ผ่านใน CI
4. ทดลองกับแพ็กเกจจริงที่ทีมใช้ รัน restore และขั้นตอน verify ในสภาพแวดล้อมเดียวกับ CI หลังแก้ config แล้ว ตรวจ log ว่ายังบังคับลายเซ็นตามนโยบายเดิมและไม่มี NU3034 จาก fingerprint ที่ขาด การทดสอบนี้สำคัญกว่าการเห็นค่าใหม่ในไฟล์ เพราะ config หลาย scope อาจทำให้คำสั่งอ่านคนละไฟล์กับที่แก้ รายละเอียด trusted signers
ขอบเขตที่ไม่ควรตีความเกิน
Microsoft ระบุว่าใบใหม่ อาจ เริ่มเป็นค่าเริ่มต้นตั้งแต่ 23 กันยายน ไม่ได้แปลว่าทุกแพ็กเกจใน feed เปลี่ยนลายเซ็นพร้อมกัน และไม่ได้บอกว่าแพ็กเกจที่ติดตั้งตามค่าเริ่มต้นทุกตัวจะล้มเหลว ประเด็นนี้จำกัดอยู่ที่ผู้ใช้ซึ่งกำหนดนโยบาย signer หรือ fingerprint แบบเฉพาะเจาะจง ประกาศต้นทาง
สำหรับทีมที่ดูแล supply chain การตอบสนองที่ปลอดภัยคือ ปรับ allowlist อย่างเจาะจง แล้วทดสอบ ไม่ใช่ปิดการตรวจลายเซ็นเพื่อให้ build ผ่าน ลายเซ็นช่วยยืนยันผู้เซ็นและความสมบูรณ์ของแพ็กเกจ แต่ไม่ได้แทนการตรวจช่องโหว่ คุณภาพ หรือความเหมาะสมของ dependency เอกสาร NuGet เรื่องการเซ็นแพ็กเกจ
แหล่งข้อมูลหลัก: devblogs.microsoft.com › microsoft-author-signing-certificate-update-2026 · เอกสารประกอบ: learn.microsoft.com › nuget-config-file และ learn.microsoft.com › dotnet-nuget-trust