Hi Bert,
Thanks for your post. We will be looking into it further and hope to
have a more detailed response in a few weeks.
Thanks,
Sean
On 6/25/19 2:08 PM, Bert Eisen 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.
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.
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.
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
