GitHub Actions代碼簽名

每年有超過12億Windows用戶安裝軟件時看到"未知發(fā)布者"警告，其中67%會選擇直接取消安裝。這個數(shù)字背后，是無數(shù)開發(fā)者在CI/CD流水線里踩過的坑——代碼簽名證書放哪？私鑰怎么管？GitHub Actions的Windows runner怎么連HSM？

一位在GitHub上維護開源Windows工具三年的開發(fā)者，最近把整套方案開源了。他的結(jié)論很直接：別再把私鑰塞進GitHub Secrets，那是用保險箱存紙條，還忘了上鎖。

云HSM二選一：租CA的，還是自建？

代碼簽名的核心矛盾在于：私鑰必須絕對安全，但CI/CD流水線又需要自動化訪問。傳統(tǒng)做法是把證書存在開發(fā)者本地機器，每次發(fā)版手動簽名——這在2024年等同于用傳真機發(fā)郵件。

云HSM（硬件安全模塊）解決了這個悖論。它讓私鑰留在物理隔離的硬件里，只暴露簽名接口。目前有兩條路：

第一條是向證書頒發(fā)機構(gòu)（CA）租用。Sectigo、DigiCert都提供托管HSM服務(wù)，按年計費，簽名次數(shù)越多越貴。一位獨立開發(fā)者算過賬：每年簽名超過5000次，成本會超過自建方案的三倍。

第二條是在自己的云環(huán)境里部署。Google Cloud KMS、AWS CloudHSM都支持PKCS#11標(biāo)準(zhǔn)，能和OpenSSL引擎對接。代價是多一層基礎(chǔ)設(shè)施維護，但簽名次數(shù)無限制，適合發(fā)布頻繁的團隊。

「如果你的發(fā)版節(jié)奏是每周一次，自建HSM通常18個月回本。」上述開發(fā)者在技術(shù)文檔里寫道。

時間戳：90%開發(fā)者忽略的關(guān)鍵細節(jié)

證書會過期，這是常識。但很多人沒意識到：沒有第三方時間戳的簽名，會隨著證書過期一起失效。

原理很簡單。Windows驗證簽名時，需要確認兩個時間點——簽名時刻，和驗證時刻。如果簽名只包含本地機器時間，攻擊者可以把系統(tǒng)時間撥回證書有效期內(nèi)，偽造"有效簽名"。

時間戳服務(wù)器（TSA）的角色，就是提供不可抵賴的時間證明。簽名時把哈希值發(fā)給TSA，返回一個RFC 3161格式的時間戳令牌，嵌進簽名數(shù)據(jù)里。即使證書2025年到期，只要時間戳證明簽名發(fā)生在2024年的有效期內(nèi)，Windows就會繼續(xù)信任這個簽名。

Sectigo和DigiCert都提供免費TSA服務(wù)，但URL藏得很深。很多開發(fā)者直到證書過期、用戶投訴"軟件突然報毒"，才發(fā)現(xiàn)自己漏了這一步。

GitHub Actions實戰(zhàn)：Google Cloud KMS + Sectigo

具體到技術(shù)實現(xiàn)，這位開發(fā)者推薦了一套組合：用Google Cloud KMS存儲私鑰，Sectigo頒發(fā)證書，通過OpenSSL引擎在GitHub Actions里完成簽名。

流程分為三步：

第一步，在Google Cloud KMS里創(chuàng)建非對稱密鑰，算法選RSA 3072或4096。關(guān)鍵設(shè)置是"允許外部簽名"——這會讓KMS暴露PKCS#11接口，而不是直接導(dǎo)出私鑰。

第二步，本地生成證書簽名請求（CSR）。需要安裝Google的libkmsp11庫，配置PKCS11_MODULE_PATH環(huán)境變量，然后用OpenSSL的engine模式調(diào)用KMS密鑰。CSR生成命令和普通OpenSSL幾乎一樣，只是-key參數(shù)換成PKCS#11 URI。

第三步，把CSR提交給Sectigo，完成域名驗證和組織驗證。拿到的證書文件可以公開存進GitHub倉庫——它只包含公鑰和身份信息，沒有敏感數(shù)據(jù)。

GitHub Actions的workflow里，核心步驟是安裝libkmsp11、配置服務(wù)賬號密鑰、調(diào)用signtool.exe。Windows runner預(yù)裝了簽名工具，但PKCS#11支持需要額外配置。

「最坑的是路徑問題。KMS的PKCS#11 URI在Windows和Linux下的格式不一樣，復(fù)制粘貼會導(dǎo)致'密鑰未找到'錯誤。」開發(fā)者在排查指南里特別標(biāo)注了這一點。

成本與風(fēng)險的再平衡

這套方案的自建成本可以量化：Google Cloud KMS的RSA密鑰存儲約每月1美元，簽名操作按萬次計費，單次0.03美元。對比Sectigo托管HSM的起步價（約每年600美元起），簽名頻率是決定因素。

但成本之外還有隱性風(fēng)險。自建HSM需要管理云服務(wù)賬號密鑰的輪換、監(jiān)控異常簽名請求、配置VPC防火墻規(guī)則。一位安全工程師評論：「這相當(dāng)于把CA的安全責(zé)任扛在自己肩上，適合有專職SRE的團隊。」

對于個人開發(fā)者和小團隊，CA托管HSM的"開箱即用"仍有吸引力。只是需要接受按量計費的不確定性——某個月如果連續(xù)發(fā)版，賬單可能突然翻倍。

「沒有完美方案，只有對風(fēng)險的正確認知。」這位開發(fā)者在文章結(jié)尾寫道。他同時開源了一個GitHub Action模板，把KMS配置、時間戳URL、錯誤處理都封裝成了可復(fù)用的工作流。

目前該模板已獲得400多次fork，issue區(qū)最常見的提問是：Azure Key Vault什么時候支持？開發(fā)者的回復(fù)很簡短：「PR welcome。」