Is Digicert's continued use of the "Distrusted" certificates for code signing still valid?
Sean Mullan
sean.mullan at oracle.com
Thu Jun 27 15:19:54 UTC 2019
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
More information about the security-dev
mailing list