Bert,
Thanks for reaching out. A few of your questions should be addressed by
DigiCert but I’ll try to address the one about the root CAs included in
the JDK.
On Tue, 25 Jun 2019 at 19:08, Bert Eisen <bert.eisen.1...@gmail.com
<mailto:bert.eisen.1...@gmail.com>> wrote:
Hello,
I’m trying to understand why Digicert are still issuing signing
certificates from the distrusted Symantec root CAs and as a
consequence if the java code signing is still meaningful? I know
for sure that they are still issing certificates from the distrusted
"thawte Primary Root CA - G3" root, because i'm trying to verify the
signing certificate that has just been issued to the company that I
work for.
DigiCert should be able to answer your question about why they are still
issuing certificates from the Symantec root CAs and whether they have
any timelines to transition to other roots.
The root CA’s were distrusted by Google following the discovery of a
number of invalid certificates incorrectly issued by Symantec and
their partners[1]. And the subsequent investigation by Google
reviled that Symantec’s partners were allowed to issue certificates
without appropriate controls or adequate security processed. It
would appear that only certificates used for protecting websites are
listed in the Sectigo search engine
[<https://crt.sh>https://crt.sh/], thus it is unclear what other
types of certificates have been issued. Ultimately this means that
you should not “Trust” any certificate issued from those roots.
According to the Thawte Certification practice statement v3.7.20[2],
(as refernced by the G3 root certificate,) it describes the CA as
being “inactive”. In addition the policy document also describes
the intermediate code signing certificate “thawte SHA256 Code
Signing CA - G2” has having have a daily updates to its CRL, but the
URL seems to point to the wrong crl distribution list, which is only
being updated every 3 months.
These are both issues that I would recommend reporting to DigiCert.
Which brings us onto the java code signing. In response to the
Googles distrust statement, the JDK and the SunJSSE provider has
been updated[3] to explicitly reject TLS sessions rooted in the
affected CAs, however it stopped short of removing the CA’s
completely. This means that jar files signed by the affected roots
are still considered valid and pass all verification checks without
warning.
Given that the Trust has been eroded from the affected roots, a
third party can no-longer believe with certainty that the signed
code hasn’t been tampered with or has originated from the party
named in the certificate. As such I believe that digicert should
not be continuing to issue certifcates from those CAs and that java
(and other platforms) should deprecate the use of the affected
CA’s. At the very least the the JDK shoud warn of code and other
artefacts that have been signed since the distrust date.
Code signing certificates have different verification processes,
different lifetimes, and are used very differently. While updating TLS
certificates in a server is usually a relatively simple process and
under the control of the entity that hosts the server, updating signed
code involves re-distributing the signed code and requires that all
users of the signed code update their copies. This could be several
orders of magnitude more disruptive.
All incidents that we are aware of involving the affected root
certificates have been related to the issuance of TLS certificates. That
is why the remediation policies that we have implemented are about
restricting trust to TLS certificates. We have not heard of any issues
related to the issuance of code signing certificates. If you are aware
of any irregularity that could affect code signing certificates rather
than only TLS certificates, please see
http://openjdk.java.net/groups/vulnerability/report for information on
how to report these issues.
As an end user, you can choose to remove trust in any root CA by
removing it from your cacerts keystore.
--Sean
Regards
Bert
[1]
<https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html>https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html
[2]
<https://www.thawte.com/assets/documents/repository/cps/Thawte_CPS_3_7.20.pdf>https://www.thawte.com/assets/documents/repository/cps/Thawte_CPS_3_7.20.pdf
[3]
<https://bugs.openjdk.java.net/browse/JDK-8207258?subTaskView=all>https://bugs.openjdk.java.net/browse/JDK-8207258?subTaskView=all
