Is Digicert's continued use of the "Distrusted" certificates for code signing still valid?

Bert Eisen bert.eisen.1952 at
Mon Jul 22 13:23:19 UTC 2019

Hi Sean.
Thanks for looking into this issue.  I was wondering if there had been any
further updates?

On Tue, 25 Jun 2019 at 19:08, Bert Eisen <bert.eisen.1952 at> 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 [ <>], 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]
> <>
> [2]
> <>
> [3]  <>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the security-dev mailing list