Hi Sean. Thanks for looking into this issue. I was wondering if there had been any further updates? Regards Bert
On Tue, 25 Jun 2019 at 19:08, Bert Eisen <bert.eisen.1...@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 >
