Closed Bug 601950 Opened 14 years ago Closed 12 years ago

Turn on the code signing trust bit for the Thawte Primary Root CA


(CA Program :: CA Certificate Root Program, task)

Not set


(Not tracked)



(Reporter: tony_berman, Assigned: kathleen.a.wilson)



(Whiteboard: In FF16)


(3 files, 1 obsolete file)

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; InfoPath.1; MS-RTC LM 8)
Build Identifier: 

When this root was added to the Mozilla root store, the code signing trust bit was not turned on for the thawte Primary Root CA.

Reproducible: Always

Steps to Reproduce:
When encountering a Code in Firefox that chains to the Thawte Primary Root CA a  message is displayed indicating that the root is not recognized for recognizing software makers
Assignee: nobody → kathleen95014
Component: Security → CA Certificates
Product: Firefox →
QA Contact: firefox → ca-certificates
Version: unspecified → other
I see that only the websites trust bit was turned on for the G1 root:

Both the code signing and websites trust bits were enabled for the G2 an G3 roots:

Enabling a trust bit follows the same process as doing a new root inclusion request:

I'll begin the Information Gathering and Verification process soon.
Ever confirmed: true
Whiteboard: Information incomplete
The attached document summarizes the information that has been gathered and

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
Response to requst for more information is being loaded as an attachment
Thanks for the information.

In regards to DV, please point me to the documentation stating which email addresses may be used for verification (e.g. the email challenge-response to confirm ownership of the domain name).

Also, what is the status of this action item:
Also, please note that we view long-lived DV certs as problematic. I expect that within the next year the Mozilla CA Certificate Policy will be updated to limit the maximum validity of DV certs. I expect that the maximum will be quite a bit less than 5 years.
(In reply to comment #5)
VeriSign Response: Bug 484903: I updated to advise that the required updates were made in July 2010
The following article describes the acceptable e-mail aliases: 
> Thanks for the information.
> In regards to DV, please point me to the documentation stating which email
> addresses may be used for verification (e.g. the email challenge-response to
> confirm ownership of the domain name).
> Also, what is the status of this action item:
This request has been added to the queue for public discussion:

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about one to two weeks. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may be in the discussion for
several weeks. When there are not enough people contributing to the discussions
ahead of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Participating in other discussions is a great way to learn the expectations and
be prepared for the discussion of your request.

Please see:
Whiteboard: Information incomplete → Information confirmed complete
We encountered this bug today when we tried to use a newly obtained code-signing certificate for packing Firefox extensions. As of Firefox 3.6.13 this bug has not been resolved. Is there any schedule when this will be fixed ?
1) Save own certificate without parrent certificate tree.
2) Thawte send updated "Thawte Code Signing CA - G2 - Thawte Consulting cc”,
certificate that change root certificate from "thawte Primary Root CA" to
"Thawte Primary Server CA", that I add to *.db before signing XPI.

Now FF install XPI till "thawte Primary Root CA" will allows to install XPI
with out any manipulation (bug 601950).
Thank you very much Ivan. Your guidelines solved the problem !
For other people seeing this problem and reading this bug, I want to provide more detail.

I use IE to do my initial creation of the PFX file since that's what Thawte says to do.

After importing your cert into IE, export the PFX file but do NOT check the box to include all the certificates in the certification path.

Create a new cert database using

certutil -N -d .

use pk12util to import your certificate

pk12util -i {filename}.pfx -d .

Download the new thawte cert from here and save it

Then import it into the database:

certutil -t "c,c,C" -n "thawte" -A -d .< new_thawte.cer

You should now be able to sign your XPI
Attachment #485124 - Attachment is obsolete: true
I am now opening the first public discussion period for two requests from Thawte:

Bug #539257: Enable EV for the “thawte Primary Root CA - G3” root certificate.

Bug #601950: Turn on the code signing trust bit for the “thawte Primary Root CA” root certificate.

For a description of the public discussion phase, see

Public discussion will be in the newsgroup and the corresponding mailing list.

The discussion thread is called “Symantec/Thawte EV and Trust Bit Change Request”

Please actively review, respond, and contribute to the discussion.
Whiteboard: Information confirmed complete → In public discussion
The public comment period for this request is now over. 

This request has been evaluated as per Mozilla’s CA Certificate Policy at

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to turn on the code signing bit for the “thawte Primary Root CA” root certificate.

Section 4 [Technical]. I am not aware of instances where Symantec has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy].  Symantec appears to provide a service relevant to Mozilla users; it is a commercial CA serving customers worldwide, and operates various thawte-branded CAs.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main document of interest is the CPS, which is in English.


Section 7 [Validation]. Symantec/thawte appears to meet the minimum requirements for subscriber verification, as follows:

* Email: Thawte has not requested that the email trust bit be turned on for the thawte Primary Root CA.

* SSL: Thawte has two levels of verification for SSL certificates, High Assurance (both the Organization and the domain are verified) and Medium Assurance (only the domain is verified, not the organization). According to CPS Section, For High Assurance certificates, where a domain name is included in the certificate thawte authenticates the Organization’s right to use that domain name. For DV SSL certificates, thawte validates the Certificate Applicants control of a domain by requiring the person to answer an e-mail sent to the e-mail address listed or predetermined for that domain.  As outlined in CPS Appendix A1,  verification procedures for EV SSL certificates are in accordance with the EV guidelines.

* Code:  According to CPS Section Thawte confirms the identity and authority of a Certificate Applicant for Code Signing Certificate. Thawte verifies that the organization exists through the use of at least one third party identity proofing service or database, or alternatively, organizational documentation issued by or filed with the applicable government that confirms the existence of the organization. Thawte also confirms with an appropriate Organizational contact by telephone, postal mail, or a comparable procedure certain information about the organization, that the organization has authorized the Certificate Application, and that the person submitting the Certificate Application on behalf of the Organization is authorized to do so.

EV Policy OID: 2.16.840.1.113733.

Section 15 [Certificate Hierarchy]. 
The “thawte Primary Root CA” root certificate has the following internally-operated intermediate certificates, which issue end-entity certs: thawte Extended Validation SSL CA, thawte Extended Validation SSL SGC CA, Thawte SSL CA, Thawte DV SSL CA, Thawte Code Signing CA – G2

* Both CRL and OCSP are provided 
** CPS 4.4.9 CRL Issuance Frequency: For end-entity certs, the CRLs are issued “At Least Daily”
** CPS Appendix A1: For EV Certificates … (OCSP) is updated at least every four (4) days, and with a maximum expiration time of ten (10) days.

Sections 9-11 [Audit]. Thawte’s audits are performed annually by KPMG and posted on the website: 
This document contains two audit reports, one for WebTrust for CA and one for WebTrust for EV.

Based on this assessment I intend to approve this request to turn on the code signing bit for the “thawte Primary Root CA” root certificate.
Whiteboard: In public discussion → Pending Approval
To the representatives of Symantec: Thank you for your cooperation and your patience.

To all others who have commented on this bug or participated in the public discussion: Thank you for volunteering your time to assist in reviewing this CA request.

As per the summary in Comment #17, and on behalf of Mozilla I approve this request from Symantec to turn on the code signing trust bit for the “thawte Primary Root CA” root certificate.

I will file the NSS bug to effect the approved changes.
Whiteboard: Pending Approval → Approved - awaiting NSS
Depends on: 722843
I have filed bug #722843 for the actual changes in NSS.
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS → In FF16
Product: → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.