Java Web Start 应用程序（无时间戳签名）在证书过期时会发生什么情况？
What happens to Java Web Start application (signed without timestamp) when certificate expires?
我们有一个使用 CA (Thawte) 证书签名的 Java Web Start 应用程序。该应用程序分发给数百名客户。他们将其托管在他们的服务器上 运行 通过 Internet 或 Intranet 在他们的客户端计算机上。现在它完美无缺。问题是应用程序是在没有时间戳的情况下签名的。证书过期后客户会怎样？他们应该能够启动该应用程序吗？如果没有，我们如何帮助他们？将他们的服务器 URL 添加到例外站点列表对他们有帮助吗？
我们试图更改当地时间以假装证书过期。然后，由于安全原因，应用程序被阻止。将 URL 添加到例外站点列表没有帮助：
java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: Response is unreliable: its validity interval is out-of-date
at com.sun.deploy.security.RevocationChecker.checkOCSP(Unknown Source)
at com.sun.deploy.security.RevocationChecker.check(Unknown Source)
at com.sun.deploy.security.TrustDecider.checkRevocationStatus(Unknown Source)
at com.sun.deploy.security.TrustDecider.getValidationState(Unknown Source)
at com.sun.deploy.security.TrustDecider.validateChain(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGrantedInt(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
at com.sun.javaws.security.AppPolicy.grantUnrestrictedAccess(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access[=11=]0(Unknown Source)
at com.sun.javaws.Main.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Suppressed: com.sun.deploy.security.RevocationChecker$StatusUnknownException
at com.sun.deploy.security.RevocationChecker.checkCRLs(Unknown Source)
... 19 more
Caused by: java.security.cert.CertPathValidatorException: Response is unreliable: its validity interval is out-of-date
at sun.security.provider.certpath.OCSPResponse.verify(Unknown Source)
at sun.security.provider.certpath.OCSP.check(Unknown Source)
at sun.security.provider.certpath.OCSP.check(Unknown Source)
at sun.security.provider.certpath.OCSP.check(Unknown Source)
at com.sun.deploy.security.RevocationChecker.run(Unknown Source)
at com.sun.deploy.security.RevocationChecker.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.RevocationChecker.doPrivilegedOCSPCheck(Unknown Source)
... 20 more
我们能做什么？当然，我们要求 Thawte 更新我们的证书，并要求我们的客户升级到已辞职的应用程序。但我们不能涵盖所有这些。当他们问我们时，我们需要为他们提供一些快速建议。到期时间快到了，欢迎大家评论。
会发生什么？
WebStart 的行为很大程度上取决于它所属的 JRE 版本。
这些是我们的测试结果，其中的应用程序使用官方证书颁发机构的有效证书签名，但在证书过期后没有时间戳。通过在不同版本中直接执行 javaws.exe 并更改系统时钟以进行模拟，使用 x64 JRE 在 Windows 7 上进行了测试：
- <= 7u21: 警告消息（可以用复选框隐藏）
- 7u25 - 7u40：WebStart 以不同的方式被破坏，在每个更新版本中改变行为，无论如何不要使用
- 7u45 到 7u51：应用程序在安全设置 "very high" 中被阻止，设置 "high" 中的警告消息（可以使用复选框隐藏）
- >= 7u55：应用程序被阻止
- >= 8u0：应用程序被阻止
我们注意到，当从浏览器启动时，WebStart 会尝试使用系统上当前安装的最新版本。在浏览器中更改 JNLP 文件的应用程序是不够的 (Firefox)。有一个使用安装在 Programm Files\Java 文件夹中的 JRE 和 JDK 的查找策略。从命令行调用 javaws.exe 或 Windows link 真正执行要测试的版本。在Java控制台（成功启动）或任务管理器命令行栏（委托给另一个版本的jp2launcher.exe）可以看到版本。
解决方法
- 对我们来说，例外站点列表确实有效（使用 j8u66 测试）。但是，输入正确的URL似乎有点棘手。我们认为它必须与 JNLP 文件 URL 中使用的 URL 完全相同。当 JNLP URL 是
http://myhost:12345/my/app/test.jnlp 时，异常站点 http://myhost:12345/ 会起作用。使用 myhost 或 myhost.in-my-domain.com 的 IP 地址将不匹配。参见 http://java.com/de/download/faq/exception_sitelist.xml。
- 根据您的应用程序类型，创建 Windows 桌面 link 到 j7u21
...\javaws.exe <jnlp-url> 可能是一个出路。
使用时间戳和警告签名
Oracle 声明使用来自官方时间戳授权 (TSA) 的时间戳签名将防止签名过期。这使您可以防止在未来的版本中出现问题并提供更新版本。
请注意此警告：WebStart 对带时间戳的签名很满意，即使在签名证书过期后也是如此。但是，它会在您的 TSA 证书过期时阻止应用程序并声明 "certificate has expired or is not yet valid"。在我们的测试中，这是在 2020-03-16 使用 TSA http://tsa.starfieldtech.com/。您可以在 keytool -printcert -jarfile <your-signed.jar>.
的输出中看到 Timestamp: 之后的到期日期
时间戳只会让你在这颗定时炸弹的时钟上多活几年。根据您的应用程序类型，这可能不是问题，但对于在未来 10 年内必须 运行 的封闭环境中的嵌入式应用程序，这是一个杀手。
（使用 j8u66 测试）
2016-01-07 更新：Oracle Support 对这个问题的最终回答是 "There is no bug. The behaviour is expected and intentional. There will definitely be no change."。这意味着没有办法在没有过期的情况下签署申请。
我们有一个使用 CA (Thawte) 证书签名的 Java Web Start 应用程序。该应用程序分发给数百名客户。他们将其托管在他们的服务器上 运行 通过 Internet 或 Intranet 在他们的客户端计算机上。现在它完美无缺。问题是应用程序是在没有时间戳的情况下签名的。证书过期后客户会怎样？他们应该能够启动该应用程序吗？如果没有，我们如何帮助他们？将他们的服务器 URL 添加到例外站点列表对他们有帮助吗？
我们试图更改当地时间以假装证书过期。然后，由于安全原因，应用程序被阻止。将 URL 添加到例外站点列表没有帮助：
java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: Response is unreliable: its validity interval is out-of-date
at com.sun.deploy.security.RevocationChecker.checkOCSP(Unknown Source)
at com.sun.deploy.security.RevocationChecker.check(Unknown Source)
at com.sun.deploy.security.TrustDecider.checkRevocationStatus(Unknown Source)
at com.sun.deploy.security.TrustDecider.getValidationState(Unknown Source)
at com.sun.deploy.security.TrustDecider.validateChain(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGrantedInt(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
at com.sun.javaws.security.AppPolicy.grantUnrestrictedAccess(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access[=11=]0(Unknown Source)
at com.sun.javaws.Main.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Suppressed: com.sun.deploy.security.RevocationChecker$StatusUnknownException
at com.sun.deploy.security.RevocationChecker.checkCRLs(Unknown Source)
... 19 more
Caused by: java.security.cert.CertPathValidatorException: Response is unreliable: its validity interval is out-of-date
at sun.security.provider.certpath.OCSPResponse.verify(Unknown Source)
at sun.security.provider.certpath.OCSP.check(Unknown Source)
at sun.security.provider.certpath.OCSP.check(Unknown Source)
at sun.security.provider.certpath.OCSP.check(Unknown Source)
at com.sun.deploy.security.RevocationChecker.run(Unknown Source)
at com.sun.deploy.security.RevocationChecker.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.RevocationChecker.doPrivilegedOCSPCheck(Unknown Source)
... 20 more
我们能做什么？当然，我们要求 Thawte 更新我们的证书，并要求我们的客户升级到已辞职的应用程序。但我们不能涵盖所有这些。当他们问我们时，我们需要为他们提供一些快速建议。到期时间快到了，欢迎大家评论。
会发生什么？
WebStart 的行为很大程度上取决于它所属的 JRE 版本。
这些是我们的测试结果，其中的应用程序使用官方证书颁发机构的有效证书签名，但在证书过期后没有时间戳。通过在不同版本中直接执行 javaws.exe 并更改系统时钟以进行模拟，使用 x64 JRE 在 Windows 7 上进行了测试：
- <= 7u21: 警告消息（可以用复选框隐藏）
- 7u25 - 7u40：WebStart 以不同的方式被破坏，在每个更新版本中改变行为，无论如何不要使用
- 7u45 到 7u51：应用程序在安全设置 "very high" 中被阻止，设置 "high" 中的警告消息（可以使用复选框隐藏）
- >= 7u55：应用程序被阻止
- >= 8u0：应用程序被阻止
我们注意到，当从浏览器启动时，WebStart 会尝试使用系统上当前安装的最新版本。在浏览器中更改 JNLP 文件的应用程序是不够的 (Firefox)。有一个使用安装在 Programm Files\Java 文件夹中的 JRE 和 JDK 的查找策略。从命令行调用 javaws.exe 或 Windows link 真正执行要测试的版本。在Java控制台（成功启动）或任务管理器命令行栏（委托给另一个版本的jp2launcher.exe）可以看到版本。
解决方法
- 对我们来说，例外站点列表确实有效（使用 j8u66 测试）。但是，输入正确的URL似乎有点棘手。我们认为它必须与 JNLP 文件 URL 中使用的 URL 完全相同。当 JNLP URL 是
http://myhost:12345/my/app/test.jnlp时，异常站点http://myhost:12345/会起作用。使用myhost或myhost.in-my-domain.com的 IP 地址将不匹配。参见 http://java.com/de/download/faq/exception_sitelist.xml。 - 根据您的应用程序类型，创建 Windows 桌面 link 到 j7u21
...\javaws.exe <jnlp-url>可能是一个出路。
使用时间戳和警告签名
Oracle 声明使用来自官方时间戳授权 (TSA) 的时间戳签名将防止签名过期。这使您可以防止在未来的版本中出现问题并提供更新版本。
请注意此警告：WebStart 对带时间戳的签名很满意，即使在签名证书过期后也是如此。但是，它会在您的 TSA 证书过期时阻止应用程序并声明 "certificate has expired or is not yet valid"。在我们的测试中，这是在 2020-03-16 使用 TSA http://tsa.starfieldtech.com/。您可以在 keytool -printcert -jarfile <your-signed.jar>.
Timestamp: 之后的到期日期
时间戳只会让你在这颗定时炸弹的时钟上多活几年。根据您的应用程序类型，这可能不是问题，但对于在未来 10 年内必须 运行 的封闭环境中的嵌入式应用程序，这是一个杀手。 （使用 j8u66 测试）
2016-01-07 更新：Oracle Support 对这个问题的最终回答是 "There is no bug. The behaviour is expected and intentional. There will definitely be no change."。这意味着没有办法在没有过期的情况下签署申请。