如何避免需要每 1 或 2 年重新签署我的代码？
我正在阅读代码签名证书过期时会发生什么 - 堆栈内存溢出a> 并想知道一个更可靠的答案。 提供的答案更多的是关于设置您自己的 CA。 即使拥有自己的 CA，您仍然需要处理过期的代码证书。
如果您在未使用时间戳服务的情况下签署代码，则证书过期后，您的代码将不再受信任，并且根据安全设置，可能不允许其运行。 您需要每 1 或 2 年使用新证书或更新的证书重新签署所有代码。
可信（数字）时间戳允许数字签名即使在证书本身过期后仍然有效。 仅当您进行了更改时，才需要使用新证书重新签署代码。
这一切听起来正确吗？ 如果是这样，我需要关于使用哪种时间戳服务的建议，最好是来自实际使用过的人的建议。 我还想知道是否有任何内部解决方案，类似于您自己的 CA。
目前这适用于 PowerShell 脚本，但我最终也会对其他代码遇到同样的问题。
更新：如何使用时间戳对 PS 脚本进行签名的示例（您可以为此制作一个脚本）：
Set-AuthenticodeSignature -filepath "D:\Projects\A Sample\MyFile.ps1"
-cert gci cert:\CurrentUser\My -codesigning
| where -Filter {$_.FriendlyName -eq "Thawte Code Signing"}
-IncludeChain All
-TimeStampServer "http://timestamp.verisign.com/scripts/timstamp.dll"
然后，要查看签名者证书和时间戳证书，您可以执行以下操作：
Get-AuthenticodeSignature MyFile.ps1 | fl *
它为您提供您的证书和时间戳记证书的主题（CN、OU 等）、颁发者、之前/之后日期以及指纹。 您还会收到一条指示签名状态的消息。
I was reading What happens when a code signing certificate expires - Stack Overflow and wondering about a more solid answer. The answer provided was more about setting up your own CA. Even with your own CA you will still need to deal with expiring code certificates.
If you signed the code without using a time stamping service, after the certificate expires your code will no longer be trusted, and depending on security settings it may not be allowed to run. You will need to re-sign all of your code with a new certificate, or with a renewed certificate, every 1 or 2 years.
Trusted (digital) timestamping allows the digital signature to be valid even after the certificate itself has expired. You would need to re-sign code with the new certificate only if you have made changes.
Does this all sound correct? If so, I need recommendations on what timestamping service to use, preferably from someone who has actually used one. I'd also like to know if there are any in-house solutions, similar to being your own CA.
Right now this applies to PowerShell scripts, but I will eventually have the same issue with other code.
Update: Sample of how to sign a PS script with a timestamp (you can make a script for this):
Set-AuthenticodeSignature -filepath "D:\Projects\A Sample\MyFile.ps1"
-cert gci cert:\CurrentUser\My -codesigning
| where -Filter {$_.FriendlyName -eq "Thawte Code Signing"}
-IncludeChain All
-TimeStampServer "http://timestamp.verisign.com/scripts/timstamp.dll"
Then, to see the Signer Certificate and TimeStamper Certificate, you can do this:
Get-AuthenticodeSignature MyFile.ps1 | fl *
It gives you the Subject (CN, OU, etc.), Issuer, Before/After Dates, and Thumbprints for both your cert and the timestamper's cert. You also get a message indicating the status of the signature.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您最好选择受信任的证书提供商之一（Verisign、Thawte、Comodo 等）。 这允许您在用户不明确信任您的私有根 CA 的情况下签署您的软件。 我们使用过 Verisign 和 Thawte、Comodo 甚至带有时间戳的 GoDaddy，没有任何软件在证书过期多年后失效的问题。
You're better off selecting one of the trusted certificate providers (Verisign, Thawte, Comodo, etc.). This allows you to sign your software without the user explicitly trusting your private root CA. We've used both Verisign and Thawte, Comodo even GoDaddy with timestamping without any issues with the software becoming invalid even years after the certificate expires.
时间戳是一项免费服务——它实际上只是一个值得信赖的提供商来验证您是否在给定时间签署了文件。 威瑞信的时间戳服务是标准服务。 Set-AuthenticodeSignature 帮助中的最后一个示例演示了如何使用它。
李·霍姆斯 [MSFT]
Windows PowerShell 开发
微软公司
Time stamping is a free service -- it's really only a trusted provider verifying that you signed the file at a given time. Verisign's timestamp service is the standard one. The final example in the help for Set-AuthenticodeSignature demonstrates how to use it.
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
您最终无法真正避免必须放弃代码。 运行自己的 CA 的优点是，您可以选择颁发比默认证书具有更长生命周期的代码签名证书，从而允许您在必须放弃任何内容之前等待更长的时间。 当然，缺点是需要处理另一个服务或服务器（您的 CA）。
You can't really escape having to resign code eventually. The advantage to running your own CA is that you could choose to issue your code-signing certs with longer lifetimes than the default, thereby allowing you to wait longer before having to resign anything. The downside is of course having another service or server (your CA) to deal with.