問題描述
signtool 選擇錯誤(舊)證書進行代碼簽名 (signtool selects wrong (old) certificate for code‑signing)
我有一個我完全不明白的問題。幾天前,我從我們的供應商 (GlobalSign) 處頒發了一個新的協同簽名證書。
在使用執行構建/協同簽名的用戶登錄構建服務器後,我啟動了 certmgr
,導航到個人證書存儲並刪除舊證書。然後我使用導入對話框導入新證書,包括它的私鑰。
測試版本顯示signtool 仍然使用舊 證書來簽署應用程序。但是,我無法在 certmgr 中的任何位置找到此證書,甚至無法通過搜索該證書的 SHA1 校驗和。
a. 如何找出舊證書仍存儲在哪裡並將其刪除?灣。如何強制 signtool 使用新證書,或者至少失敗?!
參考解法
方法 1:
The workaround with using the PFX file and referencing to it is a good solution.
However, you may try the following:
add the parameter
/s MY
to the signtool parameters chain. "MY" links to the Personal store.in certmgr.msc, look in other stores, if they do not contain a copy of the old certificate
add
/a
to the parameters chain. This will cause to "automatically select the best signing certificate" (whatever this means :))you may wait until the old certificate expires. After that, it should automatically use only the new certificate
方法 2:
My situation seems similar, though in my case, putting the password for the certificate file in my build script wasn't an option. I was having trouble using any MMC snap‑in to view (such as certmgr.msc) to view the certificate stores because Windows Server 2012 R2 wasn't allowing my non‑admin build user to use the snap‑ins. I resorted to trying a variation of a PowerShell script that I found here (https://social.technet.microsoft.com/Forums/windowsserver/en‑US/7ed48943‑22e2‑4afd‑aa77‑2424d2a9eee1/how‑to‑delete‑archived‑certificates‑using‑the‑certutil‑command?forum=winserversecurity):
$store = New‑Object System.Security.Cryptography.X509Certificates.X509Store "My","CurrentUser"
$MaxAllowedIncludeArchive = ([System.Security.Cryptography.X509Certificates.openflags]::MaxAllowed –bor [System.Security.Cryptography.X509Certificates.openflags]::IncludeArchived)
$store.Open($MaxAllowedIncludeArchive)
[System.Security.Cryptography.X509Certificates.X509Certificate2Collection] $certificates = $store.certificates
foreach ($cert in $certificates)
{
Write‑Host $cert
}
$store.Close()
It showed me the certificate that was creating the conflict for me. (Strangely, trying to use certutil ‑viewstore My
yielded a different set of certificates. (The placement of certificate stores is still unfortunately confusing to me.)
In my case, the problem was that I wanted a newer SHA256 certificate instead of my older SHA1 certificate so adding an appropriate /i argument to my signtool command (with the SHA256 issuer name) fixed my problem.