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

Question

我们在 AWS 上托管了几个网站，这些网站都使用 Sectigo 签名的 SSL 证书进行签名。其中一个网站托管了一个 Java 小程序/webstart 应用程序，该应用程序运行良好，直到 2020 年 5 月 31 日 Sectigo AddTrust-External-CA-Root certificate expired .

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

我们的证书由 COMODO RSA 证书颁发机构颁发的 this intermediate certificate 颁发。

根据对交叉签名证书的描述，我的理解是 COMODO RSA 证书颁发机构可以是 this certificate (刚刚过期)、 this one (由 this one 颁发)或 this one 。所有这些证书都安装在 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

我们注意到有人在 AWS 的证书中包含了整个证书链。我们目前的理论是 Java 将显式使用该链，而忽略存在可以使用的有效链这一事实。浏览器似乎没有这个问题。