GitHub Actions簽Windows應(yīng)用

2024年微軟收緊了代碼簽名規(guī)則——新頒發(fā)的標(biāo)準(zhǔn)證書有效期從3年砍到1年，EV證書從3年變2年。這對靠GitHub Actions自動打包的開發(fā)者來說，意味著每年至少多掏幾百美元續(xù)費，還得重配一遍流水線。

但有個細(xì)節(jié)被很多人忽略了：證書會過期，簽名卻可以永久有效。關(guān)鍵只在有沒有打時間戳。這篇文章講透怎么在GitHub Actions里搭一套能扛住證書輪換的簽名架構(gòu)，不用買CA的托管HSM也能省下一筆。

為什么你的安裝包總被Windows標(biāo)紅

用戶下載.exe雙擊后，Windows先查兩件事：這文件有沒有被篡改？發(fā)布者是誰？沒簽名的應(yīng)用直接彈"未知發(fā)布者"，企業(yè)環(huán)境更是秒被攔截。代碼簽名就是用來解決這個信任問題的。

傳統(tǒng)做法是在本地機(jī)器上用USB令牌（比如YubiKey）手動簽名，再上傳。但CI/CD流水線講究無人值守，私鑰不能躺在GitHub倉庫里，也不能塞進(jìn)GitHub Secrets——Secrets有長度限制，且任何能訪問倉庫的人都能讀到。

云HSM成了唯一解。它把私鑰鎖在硬件里，只暴露簽名接口，連GitHub Actions的臨時虛擬機(jī)都碰不到密鑰本體。架構(gòu)上分成兩派：CA托管的HSM（如DigiCert、Sectigo提供），或者自己在AWS/Azure/GCP上搭的HSM。

CA托管的坑在于按次計費。某主流廠商2024年的報價是每年5000次簽名操作約800美元，超出部分另算。對發(fā)布頻繁的團(tuán)隊，這個數(shù)字會快速膨脹。自建HSM的固定成本更高，但簽名次數(shù)無上限，適合有運維能力的中型團(tuán)隊。

時間戳：讓1年證書發(fā)揮10年效力

很多人配完簽名就完事，漏了時間戳這一步。沒打時間戳的簽名，驗證時只看系統(tǒng)當(dāng)前時間——證書過期即失效。打了時間戳，Windows會去問第三方時間戳服務(wù)器："這簽名當(dāng)時證書有效嗎？"得到確認(rèn)后，即使證書后來過期或吊銷，簽名依然可信。

免費的時間戳服務(wù)器有不少選擇。Sectigo和DigiCert都提供公共端點，RFC 3161標(biāo)準(zhǔn)兼容。配置時只要在簽名命令里加一行參數(shù)，成本為零，收益是簽名永久有效。

GitHub Actions的Windows runner是標(biāo)準(zhǔn)版Server系統(tǒng)，自帶signtool.exe。整個流程可以拆解成：檢出代碼→編譯→從云HSM拉取證書文件→調(diào)用HSM接口簽名→打時間戳→上傳產(chǎn)物。證書文件本身不含私鑰，可以放心放在runner本地；私鑰始終留在HSM里。

具體實現(xiàn)上，OpenSSL的PKCS#11引擎是橋梁。它把云HSM的API翻譯成OpenSSL能理解的指令，讓signtool間接調(diào)用硬件密鑰。AWS KMS、Azure Dedicated HSM、Google Cloud HSM都有對應(yīng)的PKCS#11模塊，配置大同小異。

自建HSM的完整配置路徑

假設(shè)選AWS CloudHSM，流程如下：先開HSM集群，初始化后生成私鑰，然后在本地Linux機(jī)器上創(chuàng)建CSR（證書簽名請求）。這一步需要裝AWS的PKCS#11庫，設(shè)置兩個環(huán)境變量指向模塊路徑和配置文件。

「openssl req -new -subj '/CN=your-domain.com/' -sha256 -key pub.pem -engine pkcs11 -keyform engine -key pkcs11:object=your_key_name」

這條命令的意思是：用PKCS#11引擎，從HSM里找名叫your_key_name的密鑰，生成CSR。私鑰從未離開HSM，CSR里只有公鑰信息。把CSR提交給CA，換來正式的代碼簽名證書。

證書下來后，GitHub Actions的工作流里需要幾步：安裝AWS CLI和CloudHSM客戶端，用IAM角色授權(quán)runner訪問HSM，下載證書文件到本地，最后執(zhí)行簽名。時間戳參數(shù)別忘了——「/tr http://timestamp.sectigo.com /td sha256」。

如果嫌OpenSSL折騰，CA托管HSM確實省事。DigiCert的KeyLocker、Sectigo的SSL Manager都把CSR生成、密鑰保管、簽名調(diào)用包成了API，代價是按簽名次數(shù)掏錢。對每月只發(fā)一版的獨立開發(fā)者，這可能更劃算；對日構(gòu)建的團(tuán)隊，賬單會很難看。

證書輪換時的隱藏成本

2024年的新規(guī)把證書壽命砍短，倒逼開發(fā)者更頻繁地處理續(xù)期。但有了時間戳，老版本的簽名不會失效，用戶不會突然看到"證書已過期"的警告。需要做的只是在CI/CD里更新證書文件路徑，私鑰可以復(fù)用——只要它還在HSM里。

一個常見陷阱：有人把證書和中間證書鏈一起打包時漏了根證書，導(dǎo)致部分Windows版本無法驗證簽名完整性。完整的鏈應(yīng)該包含葉子證書、中間CA、根CA，signtool的「/ac」參數(shù)可以附加交叉證書。

另一個細(xì)節(jié)是SHA-1的徹底淘汰。2021年后Windows不再信任SHA-1時間戳，所有新簽名必須用SHA-256。部分老舊時間戳服務(wù)器還在用SHA-1，配置前務(wù)必確認(rèn)端點支持的算法。

GitHub Actions的免費額度對大多數(shù)簽名場景夠用——Windows runner每月2000分鐘，單次簽名作業(yè)通常在5分鐘內(nèi)完成。但如果你的構(gòu)建矩陣很大（同時簽x86、x64、ARM64），或者用了自托管runner，要注意并行度對HSM連接數(shù)的消耗。AWS CloudHSM默認(rèn)每個HSM實例支持幾百個并發(fā)會話，超限時請求會排隊。

這套架構(gòu)跑通后，開發(fā)者得到的其實是一個"簽名即服務(wù)"的閉環(huán)：代碼提交→自動構(gòu)建→硬件級簽名→帶時間戳的發(fā)布包。證書可以年年換，用戶側(cè)的驗證體驗始終如一。

最后留個開放問題：如果你的團(tuán)隊已經(jīng)在用GitHub Actions簽Windows應(yīng)用，是選了CA托管HSM圖省事，還是自建云HSM控成本？證書有效期縮短后，有沒有考慮過把簽名步驟拆成獨立微服務(wù)，讓多個倉庫共享同一套HSM資源？