1100532 - Thawte Premium Server CA, question about re-issued version that contains a SHA1-based signature (instead of the original MD5-based signature)

Status: RESOLVED WORKSFORME

(NSS :: CA Certificates Code, task)

Description

[Kai Engert [:KaiE:]]

This is a question about the root CA certificate with the following CN:

/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=[e-mail]

I understand that it got removed from the Mozilla CA list in bug 986014.

Unfortunately I have been asked to still support it in a legacy environment, and if you don't mind, I'd like to use the Mozilla bugzilla to create a public record of some information, to ensure my actions can be publicly verified.

I was made aware that at least two self-signed versions of a root CA certificate with the above subject/issuer exist.

The one that had been included in the Mozilla CA list, and which got removed in bug 986014, contained a self-signature using MD5, and has SHA1-fingerprint
  62:7F:8D:78:27:65:63:99:D2:7D:7F:90:44:C9:FE:B3:F3:3E:FA:9A

The other certificate I saw contained a self-signature using SHA1 and has SHA1-fingerprint
E0:AB:05:94:20:72:54:93:05:60:62:02:36:70:F7:CD:2E:FC:66:66

Both certificates are based on the same key.

I would like to ask you to kindly confirm the following:

Has this certificate containing a sha1WithRSAEncryption signature:
-----BEGIN CERTIFICATE-----
MIIDNjCCAp+gAwIBAgIQNhIilsXjOKUgodJfTNcJVDANBgkqhkiG9w0BAQUFADCB
zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh
d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl
cnZlckB0aGF3dGUuY29tMB4XDTk2MDgwMTAwMDAwMFoXDTIxMDEwMTIzNTk1OVow
gc4xCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEdMBsGA1UEChMUVGhhd3RlIENvbnN1bHRpbmcgY2MxKDAmBgNV
BAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xITAfBgNVBAMTGFRo
YXd0ZSBQcmVtaXVtIFNlcnZlciBDQTEoMCYGCSqGSIb3DQEJARYZcHJlbWl1bS1z
ZXJ2ZXJAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0jY2
aovXwlue2oFBYo847kkEVdbQ7xwblRZH7xhINTpS9CtqBo87L+pW46+GjZ4X9560
ZXUCTe/LCaIhUdib0GfQug2SBhRz1JPLlyoAnFxODLz6FVL88kRu2hFKbgifLy3j
+ao6hnO2RlNYyIkFvYMRuHM/qgeN9EJN50CdHDcCAwEAAaMTMBEwDwYDVR0TAQH/
BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQBlkKyID1bZ5jA01CbH0FDxkt5r1DmI
CSLGpmODA/eZd9iy5Ri4XWPz1HP7bJyZePFLeH0ZJMMrAoT4vCLZiiLXoPxx7JGH
IPG47LHlVYCsPVLIOQ7C8MAFT9aCdYy9X9LcdpoFEsmvcsPcJX6kTY4XpeCHf+Ga
WuFg3GQjPEIuTQ==
-----END CERTIFICATE-----
SHA1 Fingerprint=E0:AB:05:94:20:72:54:93:05:60:62:02:36:70:F7:CD:2E:FC:66:66


been made by Thawte, intended as a valid replacement for the following older certificate, which contains a md5WithRSAEncryption signature?
-----BEGIN CERTIFICATE-----
MIIDJzCCApCgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBzjELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD
VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv
biBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhhd3RlIFByZW1pdW0gU2Vy
dmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNlcnZlckB0aGF3dGUuY29t
MB4XDTk2MDgwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgc4xCzAJBgNVBAYTAlpB
MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEdMBsG
A1UEChMUVGhhd3RlIENvbnN1bHRpbmcgY2MxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xITAfBgNVBAMTGFRoYXd0ZSBQcmVtaXVtIFNl
cnZlciBDQTEoMCYGCSqGSIb3DQEJARYZcHJlbWl1bS1zZXJ2ZXJAdGhhd3RlLmNv
bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0jY2aovXwlue2oFBYo847kkE
VdbQ7xwblRZH7xhINTpS9CtqBo87L+pW46+GjZ4X9560ZXUCTe/LCaIhUdib0GfQ
ug2SBhRz1JPLlyoAnFxODLz6FVL88kRu2hFKbgifLy3j+ao6hnO2RlNYyIkFvYMR
uHM/qgeN9EJN50CdHDcCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG
9w0BAQQFAAOBgQAmSCwWwlj66BZ0DKqqX1Q/8tfJeGBeXm43YyJ3Nn6yF8Q0ufUI
hfzJATj/Tb7yFkJD57taRvvBxhEf8UqwKEbJw8RCfbz6q1lu1bdRiBHjpIUZa4JM
pAwSremkrj/xw0llmozFyD4lt5SZu5IycQfwhl7tUCemDaYj+bvLpgcUQg==
-----END CERTIFICATE-----
SHA1 Fingerprint=62:7F:8D:78:27:65:63:99:D2:7D:7F:90:44:C9:FE:B3:F3:3E:FA:9A


If you confirm, I will feel confident to replace the old with the new one in the legacy environment that I have to support.

Thanks in advance


FYI: We found that OpenJDK 1.7.0 fails to accept the MD5-variant of the root CA certificate when attempting to verify the signature of a signed JAR file, but it works when the certificate trust store contains the SHA1-variant of the root CA.

Comment 1

[Kathleen Wilson]

Rashmi and Rick, Looking to you for the answer...

Comment 2

[Rick Andrews]

We're working on it.

One question, though: what does it mean to "support it in a legacy environment"? We may re-use roots that are removed from browsers for non-browser applications. We can't use this root for that if you're still holding on to it. Can you explain?

Comment 3

[Kai Engert [:KaiE:]]

(In reply to Rick Andrews from comment #2)
> One question, though: what does it mean to "support it in a legacy
> environment"? We may re-use roots that are removed from browsers for
> non-browser applications. We can't use this root for that if you're still
> holding on to it. Can you explain?

This is about codesigning for Java Applets.
I was pointed to applets that use the following chain:

(customer's signing cert)

-> /C=US/O=Thawte, Inc./CN=Thawte Code Signing CA - G2

-> /C=US/O=thawte, Inc./OU=Certification Services Division
   /OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA

-> /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc
   /OU=Certification Services Division/CN=Thawte Premium Server CA
   /emailAddress=[e-mail]

OpenJDK on RHEL 6 doesn't find a trusted chain, if the system trusts the MD5 variant.
However, when configuring the system to instead trust the SHA1 variant, it works.

I've been told that Oracle JRE 1.7.0 ships the SHA1 variant.

Comment 4

[Rick Andrews]

OK, so you're not proposing putting the root back into Mozilla's CA list, you're just using this thread as a public record of what you're doing, correct? No affect on NSS or Mozilla's trust store?

Comment 5

[Kai Engert [:KaiE:]]

(In reply to Rick Andrews from comment #4)
> OK, so you're not proposing putting the root back into Mozilla's CA list,
> you're just using this thread as a public record of what you're doing,
> correct? No affect on NSS or Mozilla's trust store?

correct!

Comment 6

[Kai Engert [:KaiE:]]

No change to NSS proposed.

No change to the Mozilla CA list proposed.

Comment 7

[Kai Engert [:KaiE:]]

Hello Symantec,

can you please give me some kind of confirmation?

All I need is a confirmation, that the SHA1 version of the mentioned root CA certificate is an official certificate from Thawte/Symantec.

Thanks in advance.

Comment 8

[Kai Engert [:KaiE:]]

(In reply to Kai Engert (:kaie) from comment #3)
> OpenJDK on RHEL 6 doesn't find a trusted chain, if the system trusts the MD5
> variant.
> However, when configuring the system to instead trust the SHA1 variant, it
> works.
> 
> I've been told that Oracle JRE 1.7.0 ships the SHA1 variant.


For the record, thanks to Jiri Vanek and Miloslav Trmač who have helped me to understand the issue.

It seems, in signed applets, a copy of the root CA certificate is bundled with the signed applet.

OpenJDK apparently searches for an exact match of the included root CA in the list of certificates that have been marked as trusted.

If the (Java/Linux) trust store contains the MD5 version, but the applet ships with the SHA1 version, Then Java fails to find the match, and rejects the signature.

We consider to potentially include both versions of the root CA certificate in the Linux trust store, to make any signed applet work, regardless of which version of the root they bundle in their signature.

Comment 9

[Rashmi Tabada]

Confirmed - the roots listed in the bug are correct.(In reply to Kai Engert (:kaie) from comment #7)
> Hello Symantec,

can you please give me some kind of confirmation?

All I
> need is a confirmation, that the SHA1 version of the mentioned root CA
> certificate is an official certificate from Thawte/Symantec.

Thanks in
> advance.

Confirmed - the roots listed in the bug are correct.

Comment 10

[Kai Engert [:KaiE:]]

(In reply to Rashmi Tabada from comment #9)
> Confirmed - the roots listed in the bug are correct.

Thank you.