想象一下这个场景：
2014 年 12 月 1 日 - 证书被盗并用于签署具有 2014-12-01 时间戳的恶意软件。
2014 年 12 月 15 日 - 证书被吊销。检查 CRL 的系统将阻止恶意软件运行。
2014 年 12 月 31 日 - 证书过期并按照此答案的建议从 CRL 中删除- “已过期的证书已从 CRL 中删除”。
2015 年 1 月 1 日 - 恶意软件现在可以再次运行，因为签名时间戳表明证书在签名时有效，这是系统在确定是否信任签名时使用的。
这是可能的，还是我误解了代码签名的工作方式？我是否在步骤 4 中做出假设？Java 文档等来源似乎暗示它是这样工作的——“因为签名证书通常每年到期，这会迫使客户每年重新签署已部署的 JAR 文件，从而导致客户出现重大问题。从 J2SE 5.0 开始，jarsigner 可以生成签名包括时间戳，从而使系统/部署者（包括 Java 插件）能够在签名证书仍然有效时检查 JAR 文件是否已签名。 "
这就是为什么 Microsoft 建议永远不要从 CRL 中删除过期的代码签名证书。另一种情况：攻击者在证书到期之前签署他们的恶意软件。如果他们在证书过期后仍然未被发现，那么即使在发现时证书也不会被添加到 CRL 中，他们的恶意软件将永远不会被阻止。因此，必须永远跟踪代码签名证书的撤销状态。
来自 Microsoft 的代码签名最佳实践文档：
在大多数 PKI 部署中，只有尚未过期的证书才会放在 CRL 上。这意味着当被撤销的证书过期时，它最终会从 CRL 中删除。但是，时间戳允许 Authenticode 签名无限期地保持有效。因此，不应从 CRL 中删除已撤销的代码签名证书。本文建议始终撤销用于签署公开发布软件的受损证书，并在 CRL 中无限期地维护这些条目。
Microsoft 证书服务器使管理员能够配置 CA 以将所有吊销的证书保留在 CRL 中。但是，CA 不区分代码签名证书和其他证书。出于这个原因，管理员应该将一个 CA 专门用于处理代码签名生产证书的唯一目的。
所以回答你的问题 - 是的，如果代码签名证书的 CRL 没有得到正确管理，恶意软件可以再次运行。
处理数字签名比我们乍看之下想象的要复杂得多。
您的情况是正确的：如果您没有签名日期/时间的证明，则无法确定在证书吊销和到期后还没有完成。您还可以注意到，即使证书没有被吊销，在证书到期后进行的签名也不应被视为有效。
为软件签名添加时间戳。这个时间戳称为签名时间戳。此时间戳提供了签名在给定日期存在的证明。它证明签名是在证书到期之前计算的。但这并没有解决第二个问题：如果证书被吊销了怎么办？
除了签名时间戳之外，您还可以将 CRL（或 OCSP 响应）的副本附加到签名中。它将证明在生成签名时证书没有被吊销。
但时间戳令牌和 CRL 也是签名对象。它们也需要得到验证。那么，我们是否也应该获得证明签名时间戳已由有效证书签名的 CRL？简短的回答：是的，事情似乎变得更加复杂。
一些签名标准（如CAdES）提出了更好的解决方案：连同签名时间戳，您应该收集离线验证签名所需的所有项目（即能够验证证书而无需下载任何其他对象） . 它包括所有中间 CA 证书和 CRL。这不是一个无止境的过程，因为您最终会到达一个或多个受信任的根 CA，但它可能非常复杂（请注意，一个好的 X.509 验证算法应该输出所有这些项目以及证书的有效性状态）。在获取所有这些对象之后，您必须在其上加上时间戳。这个时间戳称为归档时间戳
现在签名验证过程如下：
使用此解决方案，您所呈现的场景是不可能的，因为签名验证者在签名之日拥有证书到期和有效性状态的证明。
该解决方案目前正在实施以验证长期文档签名，但不幸的是，据我所知，不适用于代码签名验证。如今，供应商正在使用其他机制，例如被盗证书黑名单，这些机制更易于实施。
2014 年 9 月 25 日更新（阅读@maureen 评论后）
首先，您对流程的理解是正确的：由于每个证书都在到期日期之后从 CRL 中删除，因此您无法评估过去是否已撤销证书。因此，在证书到期后无法验证签名。
但即使证书已被泄露（或仅仅因为客户丢失了他的 USB 加密令牌而被撤销），之前创建的所有签名都应被视为有效。我在回答中描述的过程试图解释如何在今天（即即使在证书到期之后）回答这个问题：“签名是否有效，如果它被创建”。