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

[Sean Mullan]

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