Java 8 下载 jar 时不会使用新的 Sectigo 交叉签名证书

Question

我们在 AWS 上托管了多个网站，这些网站均使用 Sectigo 签名的 SSL 证书进行签名。其中一个网站托管一个 Java applet/webstart 应用程序，该应用程序在 2020 年 5 月 31 日Sectigo AddTrust-External-CA-Root 证书过期之前一直运行良好。

此后，在任何浏览器中访问该网站都显示该网站是安全的，但在尝试下载 jar 文件时，Java 8u252 抱怨该网站不受信任。尽管 Sectigo 知识库页面说 Java8u51 或更高版本应该可以工作。它适用于从 Java 应用程序建立的连接，但不适用于通过 WebStart 或作为小程序加载应用程序本身。

我们的证书是由 COMODO RSA 证书颁发机构颁发的 中间证书颁发的。

根据交叉签名证书的描述，我的理解是，COMODO RSA 证书颁发机构可以是此证书（刚刚过期）、此证书（由此证书颁发）或此证书。所有这些证书都安装在 cacerts Java 文件以及 Windows 证书管理器中，但由于某种原因 Java 总是想使用过期的证书。

我什至不确定 Java 是从哪里获取证书的。我已经从 cacerts 中删除了过期的证书，甚至删除了 cacerts 文件，Java 仍然使用过期的证书。

知道为什么 Java 使用旧的过期证书以及如何让它使用有效的证书吗？

>keytool -list -storepass changeit -keystore cacerts | find "AF:E5:D2:44:A8:D1:19:42:30:FF:47:9F:E2:F8:97:BB:CD:7A:8C:B4"
Certificate fingerprint (SHA1): AF:E5:D2:44:A8:D1:19:42:30:FF:47:9F:E2:F8:97:BB:CD:7A:8C:B4
>keytool -list -storepass changeit -keystore cacerts | find "D1:EB:23:A4:6D:17:D6:8F:D9:25:64:C2:F1:F1:60:17:64:D8:E3:49"
Certificate fingerprint (SHA1): D1:EB:23:A4:6D:17:D6:8F:D9:25:64:C2:F1:F1:60:17:64:D8:E3:49

***
adding as trusted cert:
  Subject: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
  Issuer:  CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
  Algorithm: RSA; Serial number: 0x2766ee56eb49f38eabd770a2fc84de22
  Valid from Tue May 30 06:48:38 EDT 2000 until Sat May 30 06:48:38 EDT 2020

Found trusted certificate:
[
[
  Version: V3
  Subject: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
  Signature Algorithm: SHA384withRSA, OID = 1.2.840.113549.1.1.12

  Key:  Sun RSA public key, 4096 bits
  params: null
  modulus: 595250832037245141724642107398533641144111340640849154810839512193646804439589382557795096048235159392412856809181253983148280442751106836828767077478502910675291715965426418324395462826337195608826159904332409833532414343087397304684051488024083060971973988667565926401713702437407307790551210783180012029671811979458976709742365579736599681150756374332129237698142054260771585540729412505699671993111094681722253786369180597052805125225748672266569013967025850135765598233721214965171040686884703517711864518647963618102322884373894861238464186441528415873877499307554355231373646804211013770034465627350166153734933786011622475019872581027516832913754790596939102532587063612068091625752995700206528059096165261547017202283116886060219954285939324476288744352486373249118864714420341870384243932900936553074796547571643358129426474424573956572670213304441994994142333208766235762328926816055054634905252931414737971249889745696283503174642385591131856834241724878687870772321902051261453524679758731747154638983677185705464969589189761598154153383380395065347776922242683529305823609958629983678843126221186204478003285765580771286537570893899006127941280337699169761047271395591258462580922460487748761665926731923248227868312659
  public exponent: 65537
  Validity: [From: Tue May 30 06:48:38 EDT 2000,
               To: Sat May 30 06:48:38 EDT 2020]
  Issuer: CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
  SerialNumber: [    2766ee56 eb49f38e abd770a2 fc84de22]

Answer 1

如上所述，这是由于 AddTrust_External_Root 证书过期造成的

如果您使用的是基于 Linux 的服务器，这里有一个快速详细的修复方法：

1. 从系统中删除 AddTrust_External_Root.crt（通常位于/etc/ssl/certs）
2. 删除或注释“mozilla/AddTrust_External_Root”行/etc/ca-certificates.conf
3. 运行sudo update-ca-certificates以更新 openssl 使用的证书

我希望它有帮助:)