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

Question

我们有几个托管在AWS上的网站，它们都使用Sectigo签名的SSL证书签名。其中一个网站托管了一个Java applet/webstart应用程序，直到2020年5月31日，当Sectigo AddTrust-External-CA-Root certificate expired。

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

我们的证书由科莫多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将显式地使用这个链，而忽略了可以使用的有效链的事实。

Answer 2

如上所述，这是由于AddTrust_External_Root证书过期所致

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

openssl

• 从系统中删除AddTrust_External_Root.crt (通常位于/etc/ssl/certs)

• remove中，或注释/etc/ca-certificates.conf

• run sudo update-ca-certificates中的“mozilla/AddTrust_External_

• ”行，以更新AddTrust_External_Root.crt

使用的证书

我希望它能有所帮助:)