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

[Sean Mullan]

Hi Bert,

On 7/22/19 9:23 AM, Bert Eisen wrote:
> Hi Sean.
> Thanks for looking into this issue.  I was wondering if there had been 
> any further updates?
> Regards
> Bert

Sorry, not yet. I was on vacation recently. I hope to have an update in 
the next couple of weeks.

Thanks,
Sean

> On Tue, 25 Jun 2019 at 19:08, Bert Eisen <bert.eisen.1952 at gmail.com 
> <mailto:bert.eisen.1952 at 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.
> 
>     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
>