Ask a Question

Advanced Search

Alert ID : INFO4154

Last Modified : 05/03/2018

Symantec Certificate Problem Report March 6 , 2017 (Updated)


Full copy of Symantec's response on 1/26/2017 on the Mozilla forum

Symantec Certificate Problem Report January 26, 2017

January 26, 2017

Issue Summary

  1. We have assigned the following categories to the certificates identified by Andrew Ayer in his January 19, 2017 post for clarity in the rest of this initial investigation disclosure:
    1. Category A: 4 certificates issued on July 14, 2016 that contain CNs and SANs containing and These were all revoked on date of issue.
    2. Category B: 6 certificates with the word “test” in the CN or SAN domain name, issued on October 21, November 15, and December 15, 2016. These were all revoked on date of issue.
    3. Category C: 21 expired certificates with O=test issued between January 22, 2010 and May 23, 2012. Nineteen of the certificates were revoked within 6 weeks of issuance. One certificate issued on January 22, 2010 expired on January 22, 2011. One certificate issued on May 23, 2012 expired on May 23, 2013.
    4. Category D: 93 certificates with O=test issued between October 21, 2016 and January 18, 2017.These certificates were all revoked within 30 days of issuance, with the last revocation occurring on January 20, 2017, less than twenty-four hours after Symantec learned of the mis-issued certificates.
    5. Category E: 2 certificates issued with O=test and “crosscert” in the domain names issued on October 24, 2016.These were both revoked on date of issue.
    6. Category F: 1 certificate issued to in the domain name, issued on October 28, 2016.This certificate was revoked on November 23, 2016.
  2. All 127 certificates were issued by CrossCert, Korea Electronic Certificate Authority. Because CrossCert is a WebTrust audited Registration Authority (RA), Symantec personnel did not participate in the validation process flow for these certificates.

Immediate Response

  1. On Thursday evening PST, January 19, 2017, after becoming aware of this issue, Symantec disabled issuance privileges for all CrossCert staff. All issuance privileges remain disabled.
  2. Symantec revoked 31 still valid and active Category D certificates on the morning of January 20, 2017 that were issued between December 28, 2016 and January 18, 2017.
  3. Symantec has taken over validation and issuance for all pending and new orders submitted through CrossCert. Symantec’s authentication team is fully processing these orders independently. Symantec is not relying on any previous authentication work completed by CrossCert.
  4. Due to the severity of this matter, Symantec has disabled issuance in all CrossCert provisioned enterprise accounts. Symantec is re-validating all accounts. New issuance from these accounts is blocked until Symantec’s re-validation is complete.

Root Cause

  1. Symantec contracted with CrossCert as a Registration Authority to delegate the performance of BR Section 3.2 requirements pursuant to Section 1.3.2 of the BRs. CrossCert’s issuing staff completed Symantec’s required annual training.
  2. For the certificates issued between July 2016 and January 2017, Symantec’s compliance checks flagged these orders when they were submitted because they contained the word “test”, prohibiting CrossCert RAs from issuing these certificates without obtaining an override from CrossCert management.
  3. Our audit logs show that CrossCert management overrode the compliance failure flags. CrossCert did not consult with Symantec on the significance of the compliance failure flags or the decisions to override the flags for any of the certificates. Three of the four certificates in Category A solely included “example” and as a result were not flagged. Nonetheless, these three certificates required standard RA processing, and similar to the flagged certificates including “test”, CrossCert did not properly complete verification procedures, yet these certificates were issued anyway.
  4. CrossCert’s issuance behavior that resulted in Category D and F mis-issuance from October 21, 2016 to January 18, 2017 relates to a new documented service offer CrossCert launched for their customers. CrossCert offered certificates to allow customers to test public root ubiquity before purchasing additional certificates with the customer identity in the organization field. CrossCert has explained to Symantec that they used “test” in the “O” field to enable their customers to easily distinguish these test certificates when requesting revocation of the certificate used for testing. CrossCert did not consult with Symantec prior to introducing this new offering. CrossCert management said that the Category C certificates were also issued for customers’ internal testing, although not formalized as a documented service offer at that time.
  5. CrossCert management has indicated that the Category A, B, and E certificates, 12 total, were issued for CrossCert internal testing.
  6. No internal Symantec software testing tool (including the tool subject to management approval and requiring elevated privilege) was involved, as no partners have access to those tools.

Additional Follow-up



  1. Symantec has engaged CrossCert daily throughout this investigation. We have requested documentation for our review for all categories, with A, B, and E as highest priority.
  2. We have spoken with Ernst & Young Korea, who conducted CrossCert’s most recently published unqualified WebTrust audit. We are reviewing E&Y’s audit work, including E&Y’s detailed approach to ascertaining how CrossCert met the required control objectives. The CrossCert E&Y unqualified audit report for the period ending June 30, 2016, is published at
  3. We are reviewing all our RA partners, beyond their completed WebTrust audits, including issuance privileges and other controls. We are also highlighting this issue as Symantec communicates with our other audited RA partners that have issuance privileges to reinforce the requirements for proper authentication and issuance, explain the harm caused to the web PKI if those requirements are not followed, and to further emphasize the importance of the safeguards we have in place to prevent these failures.
  4. Our investigation of this matter continues, and includes a review of our delegated RA controls and why we did not detect this problematic behavior before it was reported to us. Our findings will feed into our continuous efforts to strengthen controls via automation and process


Update January 30th

Symantec Responses to Mis-Issuance Questions Jan 30 2017

Reference [1]: id=INFO4154



Symantec Response

1) In response to the previous incident, Symantec indicated they hold a "no compromise" bar for such breaches in the post titled "A tough day as leaders".

a) Do you believe that the steps to "reduce privileges" represent a consistent application of that standard?

We believe the steps we have taken and are taking appropriately respond to the incident and we will continue to evaluate whether other steps are necessary as our investigation continues. See also [1] Immediate Response #1.

b) If not, what additional steps are you taking, consistent with your "no compromise" standard?

We disabled CrossCert issuance privileges. We revoked 31 certificates within 24 hours of notice. We have taken over issuance internally. We disabled access to enterprise accounts provisioned by CrossCert. See also [1] Immediate Response #1-4.



2) In response to the previous incident, Symantec indicated that the use of any privileged test tool would require senior leader justification from both QA and Production Operations teams and approvals from the heads of Engineering and Policy Compliance.

a) Did Symantec mean that this was limited to validations performed by Symantec, and not that of Registration Authorities fulfilling the duties pursuant to Section 1.3.2 of the Baseline Requirements?

The privileged test tools referred to in our previous disclosure were only accessible to internal Symantec personnel, not to RA partners. [1] Root Cause #6.

b) At the time Symantec made this statement, did Symantec have any Registration Authorities fulfilling the duties pursuant to Section 1.3.2 of the Baseline Requirements?

Yes, but no RA partners had access to these privileged test tools.

c) If such a statement was meant to be limited to Symantec, and not that of Registration Authorities, why did Symantec not feel it was appropriate to highlight that it did not extend to activities performed by Registration Authorities?

RA Partners do not have access to these tools. [1] Root Cause #6.

d) If such a statement was not meant to be limited to Symantec, was such a justification provided, and approvals granted, for the tool that allowed such Registration Authorities to issue these certificates?

Not Applicable.



3) In response to the previous incident, Symantec indicated a comprehensive review of issuance privileges was conducted to ensure only authorized personnel have the ability to issue certificates, and that a quarterly access review would be conducted to ensure this.

a) Did such comprehensive review include that of Registration Authorities?


b) If not, why did Symantec not disclose that Registration Authorities were excluded?

Not Applicable.

c) Is Symantec currently performing access reviews of Registration Authorities?

Yes, they are included as part of our audited monthly access review process.

d) If so, when does Symantec expect this to be completed?

Not Applicable.



4) In response to the previous incident, Symantec indicated it updated its internal policies and procedures for test certificates as used for commercial certificates. Further, it indicated that QA engineers and authentication personnel were trained on updated practices for test certificates.

a) Did Symantec include Registration Authorities in the scope of that training?

We did not train partners on an issue that pertained to a tool they could not access.

b) If not, why did Symantec not disclose that Registration Authorities were excluded?

The training referred to in our previous disclosure was delivered to Symantec QA and Authentication teams guiding them to eliminate non-standard testing procedures for obtaining public certificates. Our delegated RA partners do not perform a QA function. Our delegated RA partners are trained to always issue only fully validated certificates. At no point were RA partners authorized to perform less vetting on certificates for their own internal use.

c) If so, why did Symantec's corrective actions for the previous
mis-issuance fail to prevent this continued mis-issuance?

Not Applicable.



5) You have indicated that you have at least one WebTrust audited partner capable of causing issuance using Symantec-operated CAs.

a) Please provide a link to the audit results for each of these WebTrust audited partners.

CrossCert (Korea Electronic Certificate Authority):

Certisign Certificatadora Digital:

See attachments posted at

Certsuperior S. de R. L. de C.V.:

See attachments posted at

Certisur S.A..:

b) Have you suspended the capabilities of these partners until Symantec completes its investigation?

Only CrossCert.

c) If not, why not, and when do you expect to do so?

Our ongoing investigation includes activities of our other delegated RAs. At this time we do not have evidence that warrants suspension of privileges granted to any other RA besides CrossCert.



6) Does Symantec allow is Registration Authorities to deviate from the policies and standards set forth by its CP, CPS, and internal policies and controls?

a) If not, why did Symantec fail to detect that its Registration
Authorities were deviating from its policies for this long?

RAs are required to follow the same policies as set forth in Symantec’s CP and CPS documents. Internal procedures at an RA are subject to their WebTrust audits to ensure conformity with the associated policies.

  • Our investigation is proceeding, but to our knowledge only CrossCert is involved.
  • We evaluate independent WebTrust audit reports for material findings. In the case of CrossCert, their last audit report was unqualified by E&Y South Korea and the problem certs identified in category A, B, D, E, and F were all issued subsequent to that last audit. Category C concluded prior to that last audit’s review period.
  • Based on these findings, we intend to implement additional direct monitoring and audit of RA activity to supplement the independent WebTrust reports, with the objective of quickly detecting and blocking similar cases in the future.

b) If so, where does Symantec disclose this deviation within its CP and/or CPS?

Not Applicable.



7) When do you expect to provide the next update as to the ongoing investigation? If it is not within the next three days, why?

Published on Jan 26, 2017.



It's not clear what the problem is with the issuance in category F. I don't see any mention of "" in Andrew's initial report. Can you explain (and provide a link)?

This certificate contains “test” in four DN attributes including Organization. It is isolated from Category D because the common name is not a registered domain, is. The omitted dot separator after “dev” repeats in the SAN extension. This is a domain validation error.



Root Cause, bullet 2 refers to "certificates issued between July 2016 and January 2017"; is it correct that this corresponds to categories A (one of four certificates), B, D, E and F?




What processes, other than requiring and inspecting a WebTrust report, does Symantec have in place to ensure that its RAs behave in accordance with the CP and CPS of the Symantec-owned roots under which they are issuing? (Perhaps this will be covered in the report you will issue after the "additional follow-up" steps are completed?)


  1. Each certificate request is screened for BR compliance failure. Failures are flagged, preventing RA issuance until the flag is cleared.
  2. Each request is screened, for example, using a list of risk words such as “test”, strings used in scam domains, and high-profile brands. String matches are flagged for risk. Risk flags require manual override by RA personnel who have passed their exams and who are granted validation and flag clearing privileges by Symantec administrators and can refer to our knowledge base for flag reason explanations to understand the purpose and severity of the flag. See [1] Root Cause 2-3.
  3. Each request is screened for BR compliance again when the RA approves the request and before it is issued.
  4. Daily, we rescan all certificates issued on the prior day.


  1. Topics include BR changes, CPS changes, process changes as a result of industry incidents regardless of the CA involved, and a review of Symantec’s procedures that extend the Baseline Requirements.
  2. Exams are modified and retaken annually as criteria to renew individual access certificates or after significant internal or external process change.


  1. Symantec operates an internal knowledge base accessible by RA partners that contains detailed step by step procedures for performing each of the tasks required to validate the identity asserted in a certificate request.
  2. The KB reinforces acceptable and unacceptable sources of validation information and processes using a subset of the information in the BRs.
  3. The KB explains request flagging, flag reasons, and flag clear procedures.


  1. We evaluate the RA’s independent WebTrust audit reports for material findings pursuant to BR 8.4 regarding WebTrust audited Delegated Third Parties.



Do such processes include regular, occasional or any review of the audit logs which show the overriding of compliance failure flags?

No. We intend to implement flag clear reporting, review the reports for unusual patterns, and investigate when appropriate. See also [1] Additional Follow-up #4.



Were the web identities (DNS names etc.) in the category C, D, E and F certificates properly vetted as per the CP/CPS etc., the certificates simply replaced the vetted organization name with "test" in the X.500 distinguished name?  Or were some of those issued for insufficiently (or actually incorrect) web identities?

CrossCert has stated that vetting was performed properly for identity information in its certificates. We are currently validating that claim. Symantec has requested all proof of right documentation from CrossCert for the 127 certificates. We are analyzing all certificates issued by CrossCert and will request documentation for a random sample of certificates. If our analysis finds suspicious certificates, we will request documentation.


Our auditors, KPMG, completed a scan of CrossCert certificates to detect potential mis-issuance and presented 12 suspicious certificates. We treated this as a certificate problem report under the BRs and began an investigation. We released a disclosure that described what we found that led to revocations.





Update February 12

Symantec Second Response to Mis-Issuance Questions – February 12, 2017

Based on our investigation of CrossCert, we have concerns due to (1) demonstrated non-compliance with processes and controls, (2) assertions of third party auditors that need far greater oversight than we previously expected, and (3) the fact that these issues have enabled cases of certificate mis-issuance. As a result, we have made the decision to terminate our partner RA program. We will continue to work with select partners that have local market contacts and expertise to facilitate an interface with customers and collection of relevant documentation, however Symantec personnel will validate 100% of all asserted identity data and control certificate issuance going forward. We have communicated this change to each of our RA partners, we are finalizing a transition plan, and intend to implement that transition quickly. In addition, to alleviate any concern by customers or relying parties on the integrity of the certificates issued by these RA partners, Symantec will review the validation work of 100% of issued certificates and revalidate any where we identify any deficiency. Certificates issued with deficient validation will be replaced and revoked. Our work will be included in scope of our next WebTrust audits.


Symantec Response



  • You say that one of your WebTrust audited partners issued these certificates. Is this partner Korea Electronic Certification Authority, Inc. (”CrossCert”)?
  • If yes, according to the audit report here this partner is allowed to use the following three issuing certificates from Symantec:
    • VeriSign Class 3 Secure Server CA - G3
    • VeriSign Class 3 International Server CA -G3
    • Symantec Class 3 Secure Server CA - G4
  • However when I look at all the "test" certificates I find these issuers: 
    • 4 issuer= /C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
    • 99 issuer= /C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
    • 11 issuer= /C=US/O=thawte, Inc./CN=thawte SSL CA - G2
  • Symantec authorized CrossCert to issue certificates from each of the identified CAs.
  • The list of CAs in the audit was produced by CrossCert and given to E&Y KR as the scope to audit. It was not given to E&Y by Symantec.
  • E&Y KR initially stated that CrossCert did not fully disclose the list of CAs. E&Y KR later stated that CrossCert provided a list of all their issuing CAs but reduced the list of issuing CAs in scope of sampling for budgetary reasons.
  • Due to these conflicting statements and further discoveries explained below, Symantec will no longer accept audits from E&Y KR.
  • Symantec is terminating RA delegation to CrossCert. Symantec’s Authentication team has taken over validation since January 19, 2017 and will continue as the only RA responsible for verification work resulting in issuance of new and replacement certificates to CrossCert customers.



The six "false positive" certificates appear unremarkable except for the coincidence of including the word "test". If CrossCert can't produce documentation to show these were validated properly, it seems likely that many or even all certificates which Symantec had believed were validated by CrossCert in fact lack such documentation. Is that not so?

  • We have confirmed that there are deficiencies in the documentation and audit trails for validation performed by CrossCert. We are terminating RA delegation to CrossCert. Further, Symantec’s Authentication team is re-validating 100% of certificates issued by CrossCert using local language expertise. The timing of this is dependent on staffing Korean speakers, following our strict onboarding procedures, and completing the re-validation of all currently valid certificates. Our work will be included in the scope of our next WebTrust audits.



It had been my assumption, based on the CPS and other documents, that CrossCert was restricted in their use of Symantec's issuance function to C=KR, this is cold comfort for practical purposes in the Web PKI, but it would at least help us to scope any damage. The existence of certificates with C=BD in this list shows my assumption was wrong. How (if at all) can an outsider determine if in fact CrossCert caused issuance of a Symantec certificate? Prior to Andrew's report what _mechanical_ constraints on CrossCert's issuance were in place, in particular any beyond those which were applied to Symantec's own issuances? For example, would it have been possible for them to cause issuance of a 5-year cert? A SHA-1 certificate? To choose specific serial numbers?


  • CrossCert’s CPS at table 5 in section 3.1.1 at states that Country will contain “KR” or not be used (in usages other than TLS Server Authentication).
  • We have confirmed that CrossCert has issued certificates that contain a country code other than KR.
  • CrossCert does not operate a subordinate CA that externally distinguishes their issuance.
  • Our first question response document described our compliance checks prior to and after issuance. The 39 month limit, SHA256 requirements, and other technical conformity checks are enforced prior to issuance and checked post-issuance. These checks cannot be overridden. These checks are replaced by multiple engineering and compliance team checks in the case of manual key ceremony signing events. Serial numbers are generated automatically after the RA causes issuance of the certificate using a CSPRNG with appropriate entropy.



Since we have every reason to imagine that some (or even all) of the affected certificates were issued in good faith to legitimate subscribers, it would have been nice for Symantec to alert the subscribers when their certificates were revoked. Did Symantec do this? If not does Symantec have the capability to contact these subscribers itself (e.g. email addresses, phone numbers)? If not, does Symantec contractually require of RA partners that they provide a capability for Symantec to contact their subscribers, or relay a message chosen by Symantec on their behalf?

  • Yes, these customers were notified.
  • CrossCert was alerted that we intended to comply with the 24 hour revocation requirements of the BRs.
  • In places where we rely on the local language skills and business relationships of our RA partners, we communicate to our partner and they notify their customers.



Although BR 5.4.1 says that these records are to be kept by the CA and each Delegated Third Party the obligation is on the CA (here, Symantec) to make the records available to their auditors. Is it in fact the case that this investigation is the first time Symantec has asked Crosscert for such records? Wasn't Symantec concerned that KPMG (in a routine audit) might ask to see these records but they didn't have them? Might not other RA partners be affected similarly?

  • CrossCert is a WebTrust audited delegated third party required to make their delegated record keeping available to their auditor.
  • Symantec complies with BR 5.4.1 by delegating CrossCert to perform 2(c) for the certificates they issue. All other 5.4.1 event recording is performed by Symantec’s software, hardware, or Trusted Role personnel using software, hardware, document, or paper-based methods.
  • Symantec relied upon CrossCert’s unqualified WebTrust audit as a statement of compliance, and upon E&Y Korea’s opinion as meeting WebTrust objectives.



As Symantec will know from its own experience, audits have not proved to be sufficient for detecting systematic non-compliance by CAs. What measures _beyond_ the Webtrust audit did Symantec have in place to detect non-compliance by an RA partner?

  • To the extent that we relied on RAs for authentication and verification, we relied on their independent WebTrust audits to detect non-compliance.
  • We employ automated compliance checking prior to and after issuance. Further, we have deployed support for, and honor Certification Authority Authorization across all systems to put control of authorized CA’s in the hands of customers, we log all publicly trusted certificates to Certificate Transparency Logs, and we have created a monitor to put visibility in place for all customers to enable detection of suspect certificates.



Did Symantec do any additional training for RAs regarding the issuance of test certificates after the last incident? If not, why not?

Did Symantec believe that it was very unlikely for RA personnel to make the same mistakes or have the same misunderstandings of what was appropriate as Symantec's personnel?

We did not do additional training for RAs regarding the issuance of test certificates. However, we put in place a programmatic control to identify and flag likely test certificates by screening all certificates, including those processed by RAs. In the case of CrossCert, our audit logs show that CrossCert overrode the compliance failure flags. CrossCert did not consult with Symantec on the significance of the compliance failure flags or the decisions to override the flags for any of the certificates.




Is your understanding that, when WebTrust audits are sampling, they sample only certificates issued during the review period? Or should they be sampling certificates issued during the entire period covered by the audit? If the latter, did their sampling (3%, isn't it?) hit any Category C certificates? How many certificates were in the sample pool?

Symantec’s experience and expectation is that WebTrust audits include a representative sample of certificates issued during the audit period of time. Symantec relies on WebTrust audits to confirm that proper controls were in place governing certificate issuance during a specific period in time. The last E&Y KR audit did not include verification of the issuance of the Category C certificates since they were issued in an earlier period. We recently learned that E&Y’s recent sample size was 25 of the certificates issued in the last audit period. The 3% review is related to internal self-audit under BR 8.7.



To be totally clear: would it be correct to say that up until this point, examining WebTrust audits was the only mechanism that Symantec used to _check_ the conformance of their RAs to Symantec's CP/CPS and other requirements? (I see you give them software, and docs, and training, but was this the only _checking_ mechanism?)

To the extent that we rely on RAs for authentication and verification, we relied on their independent WebTrust audits to detect non-compliance. Technical requirements such as ensuring minimum key lengths, blocking SHA1, and other areas of technical conformity are subject to several additional controls.




Is there any reliable programmatic way of determining, looking only at the contents of the certificate or certificate chain, that a certificate was issued by CrossCert personnel using their processes, as opposed to by Symantec personnel or by another RA?

No. The most viable check would be to examine certificates with a KR country code, however while CrossCert was the only Symantec RA in KR, they have not been the exclusive source of enrollments in KR. Such a search would not distinguish KR certificates validated by CrossCert from those that Symantec processes directly. In any event, we are revalidating every valid certificate issued by CrossCert.



Given the many issues very clear from CrossCert's CP/CPS, and the many audit issues disclosed in CertSuperior's report, I'd like to request that you also disclose the CP/CPS for these CAs. For example, CertiSign's CP/CPS is not immediately obvious to me as to what Symantec was relying on EY to audit.





To echo Gerv's remarks, the statement Symantec issued for the previous misissuance [1] stated: "Symantec has updated its internal policies and procedures to strongly reinforce that all test certificates must follow the same fulsome authentication procedures as commercial certificates."


Section 9.8 of the Baseline Requirements, v1.4.2 states

"For delegated tasks, the CA and any Delegated Third Party MAY allocate liability between themselves contractually

as they determine, but the CA SHALL remain fully responsible for the performance of all parties in accordance with

these Requirements, as if the tasks had not been delegated. "


1) Does Symantec believe that the original statement is sufficiently clear that it was limited solely to Symantec's role in validating, and did not extend to that of Delegated Third Parties?

There were no limits to the spirit of the statement we made. Practically, as stated previously, in 2015 we identified internal Symantec procedures for handling certificates used for internal testing purposes, we changed those procedures, and we retrained the individuals who had used those procedures. Separately, we continued the existing practice of requiring training of our RA partners – that training never justified publicly trusted certificates used for testing. We believed that this training was clear to all partners.



2) Did Symantec management believe it was not necessary to notify and inform its Delegated Third Parties about the need and significance to conform to Symantec's CP and CPS, and of the necessity of ensuring that all issued certificates - regardless of mechanism - must follow the same fulsome authentication procedures?

Software controls, training, documentation and annual exams reinforce these concepts. Audits we have received document disclosure of the RA’s CPS. Each RA’s CPS operates under the STN CP and is audited for conformity to CABF BR.



3) The most recent version of Certisign's CP/CPS that I'm able to publicly confirm is , which is dated 2012. Is this the correct CP/CPS?

Yes, that is the correct CPS and it implements the STN CP.



4) Can Symantec confirm that this is the CP/CPS that was audited?

Yes, that is the correct CPS. This CPS implements the STN CP.



5) Does Symantec believe that this CP/CPS is consistent with Symantec's update CP and CPS documents updated in response to the previous misissuance?

Changes to internal procedures did not extend to the STN CP and CPS.



6) Does Symantec believe that the audit letter, indicated in [2], which clearly indicates that the effective criteria were based on "SSL Baseline Requirements Audit Criteria, Version 1.1", available at [3], represents a sufficient demonstration of conformance to Symantec's CP/CPS?

No. E&Y BR produced two deficient letters regarding the 2014 and 2015 Certisign audits. Initially we received a letter that stated a January 1, 2014 to December 31, 2014 audit period in its introduction and a January 1, 2014 to December 31, 2015 audit period in its conclusion. The letter appeared to cover a two year period. We asked for clarification multiple times. That clarifying letter stated a 2015 audit period.


E&Y BR does not meet our requirements for RA audit quality, timeliness, and responsiveness to our demands. Symantec will no longer accept audits from E&Y BR should we have a future need for in-market audit support.



7) Does Symantec believe that the audit letter, indicated in [2], conducted by Ernst and Young Brazil, conforms with the professional obligations with respect to WebTrust licensing, and Symantec's obligation to ensure said compliance as part of its Delegated Third Party conformance to the Baseline Requirements' audit standards? Specifically, the requirement to use "WebTrust for CA - SSL Baseline with Network Security 2.0" for all audits whose periods begin after 1-Jul-14, which EY Brazil demonstrably did not follow?

No. E&Y BR’s letter incorrectly specified v1.1 due to the date range error above. The updated audit letter documents failure to use the proper audit specifications for calendar year 2015.



Regarding Certsuperior:

Symantec has indicated that the 2016 audit of Certsuperior was qualified, as demonstrated in [4]. During Symantec's previous misissuance event, Symantec noted that:

"We have also enhanced our compliance function by consolidating all compliance activities into a single group reporting directly to the head of our Website Security business unit. This change was made in January 2016; this new compliance structure includes enhanced identification, tracking, prioritization and resolution of compliance-related updates, which will help ensure that CA/Browser Forum rule changes are effectively implemented."


8) Was Symantec's compliance group involved in reviewing the qualified audit report findings?

Yes. Upon receipt of the qualified Certsuperior audit Symantec’s Compliance team required successful execution of a 90 day action plan to remedy all findings and a point in time audit proving all remedies were effective.



9) Did Symantec's management or compliance group disclose this qualification to Mozilla?

No. If Certsuperior had not remedied their qualified opinion, Symantec’s period of time audit would have reflected that and would have been disclosed to Mozilla.



10) Did Symantec's management or compliance group make its determination of Certsuperior's compliance to Symantec's CP/CPS using Certsuperior's publicly available CP/CPS, which Certsuperior's auditor, Deloitte, noted in [4] that "The policies, procedures, and agreements are not available for consultation." and that "The CPS published is illegible"?

We did not evaluate compliance until a successful point in time audit including assessment of the CPS, was completed.



11) If not, what CP/CPS did Symantec use, and how did Symantec ensure it was appropriately audited?

We used the STN CP, the Certsuperior CPS referenced above, and the Deloitte point in time audit letter stating that all findings were remedied. The Deloitte letter is posted to the Bugzilla tracking this discussion.



12) If so, how did you do so, when the auditors themselves were not able to?

Not Applicable.



13) Given Symantec's previous statements regarding "holding ourselves to a 'no compromise' bar" [5], and the numerous issues identified in [4], including an audit finding of "We noted roles of users that are not Trusted Roles with access to validation requests at the web application", a "lack of network segmentation for distinguishing between equipment with access to applications and that which are not part of the validation process", and that Certsuperior's network scans were "not performed with sufficient periodicity and had only ever been executed over the website" and "were executed by personnel without technical skill, ethics code, or independence", why does Symantec still have an RA relationship with Certsuperior?

Symantec immediately required a 90-day action plan and point in time audit at 90 days to demonstrate resolution of Deloitte’s qualified opinion. Certsuperior complied with the action plan as demonstrated by Deloitte’s opinion that the prior findings were proven to be remedied on the date of their point in time audit.


Nonetheless, for the broader reasons stated earlier, we have made the decision to terminate our partner RA program.



14) Does Certsuperior pay Symantec to engage as a Registration Authority?

No, RA Partners, like all reseller partners, pay Symantec for sales of Symantec products; there is no fee to engage as an RA.



15) If so, what does Symantec believe should be the reasonable interpretation relative to the continued trustworthiness of Symantec and Symantec's management of the fact that Symantec terminated employees for cause for being involved in misissuance, but has continued to engage in a business relationship with entities who have performed demonstrably worse, but which pay Symantec for that privilege?

Not applicable.



Regarding CrossCert:

The audit report indicated in [6] directly states that the audited CP/CPS version of CrossCert is version 3.8.8, available at [7]. This version indicates it was "Published Date: June 29, 2012". This audit was performed by Ernst and Young, Korea.


16) Similar to Q3, is this the correct CPS?




17) Similar to Q5, does Symantec believe this CP/CPS, dated in 2012, is consistent with Symantec's CP/CPS, which was updated in response to past misissuances?

The STN CP and the CrossCert CPS state compliance with the CABF BR and such compliance asserts fulsome authentication.


We have confirmed that there are deficiencies in the documentation and audit trails for validation performed by CrossCert. We are terminating RA delegation to CrossCert. Further, Symantec’s Authentication team is re-validating 100% of certificates issued by CrossCert.



Regarding Registration Authorities


18) Can you confirm that Symantec's response in [2] is correct and comprehensive for all brands directly and indirectly operated by Symantec, including, but not limited to, Verisign, Symantec, Thawte, GeoTrust, and RapidSSL offerings?




19) Can you confirm that Certsuperior, Certisign, CrossCert, and Certisur are the only Delegated Third Parties utilized by Symantec, across all Symantec operated CAs that are trusted by Mozilla products?

Symantec has three programs where third parties are involved in authentication and or certificate issuance activities: subordination, RA, and processing agent.


Subordination includes Google and Apple, who operate CAs that chain to our roots in their premises and submit annual WebTrust audits.


RAs include Certsuperior, Certisign, Certisur and CrossCert. This program is being terminated.


A processing agent is a delegated third party that uses local language skill to gather organizational identity proof documentation on behalf of their customer. They perform BR 3.2.5 validation of authority, and document the result of that call compliant with BR in our audit trail. The information submitted is subject to review by Symantec personnel and Symantec personnel control final decisions on certificate issuance. Xolphin B.V. is a processing agent.


As part of terminating the partner RA program, subject to meeting ongoing training and internal audit requirements, we will offer Certsuperior, Certisign and Certisur the ability to transition to processing agents. Given the findings through our investigation we will not be making this option available to CrossCert.


Separately, Symantec enables a reseller model. Resellers do not participate in authentication. Symantec’s Authentication team performs 100% of the validation and issuance for reseller orders. Subject to meeting separate ongoing legal and compliance requirements, we will continue to make this option available to Certsuperior, Certisign, Certisur, and CrossCert.





Update February 21

Symantec Third Response to Mis-Issuance Questions

Question or Comment

Symantec Response



What criteria is Symantec using to determine if a certificate has a "deficiency" that warrants re-validation?


What criteria are Symantec using to judge whether the validation of a particular certificate was deficient and needs redoing? Does this process rely on an assumption that any work logs kept by the RAs are accurate records of work actually done?

As a result of samples we have examined, we have determined that CrossCert record keeping is materially deficient and needs to be revalidated.


For each of our other three partners, we will review 100% of archived documentation and the validation methods used. If any certificate documentation has gaps, is incomplete or in any way does not equal the quality standard for our Authentication team, it will be considered deficient.


If we determine, on a partner by partner basis, that there are systemic deficiencies in the work historically performed, then we will fully revalidate all certificate details, as we are doing with CrossCert. At this stage we have not identified such deficiencies in the work completed by the other three RA partners.


Our standards are based on CABF BR, additional browser policy, guidance from our auditors and our internal knowledge base.


Only RA audit trails that match confirming information found at Reliable Data Sources will be considered accurate.



How will Symantec assess whether the domain(s) in a certificate were correctly validated?

All certificates issued using CrossCert RA validation will be revalidated, and if necessary, replaced and revoked. All new certificates issued to these organizations will be issued using Symantec Authentication team validation.


For each valid certificate issued by our other three partners, we will use software to access the server(s) named in the CN and SAN(s) to determine whether the certificate installed on those server(s) matches the serial number and issuer of the certificate we are checking. In the case of wildcards, we will attempt substitution of www as the first label of the FQDN.


Any certificate containing a CN or SAN(s) that cannot be validated via live access will queue for manual review.


For certificates that queue for manual review, Symantec will review the archived domain validation documents for certificates issued by our other three RA partners by revalidating the domains.


For any certificate, whether checked manually or by software, where we find that the documentation does not meet our detailed standards for domain validation or used a method that is not supported by the 10 finite methods that were the intent of CABF ballot 169, its successors, and the expected ballots to follow, we will revalidate within these constraints, replace the certificate, and revoke once the customer ceases use of the prior certificate.



Is any of the information gathered by processing agents used for domain validation?

No. Processing agents may only submit links to WHOIS results that are subsequently validated by Symantec’s Authentication team manually or ignored and replaced by the results from our WHOIS automation. Processing agents also cannot initiate any automated or semi-automated domain validation methods such as agreed upon changes to web content, DNS tokens, constructed and/or WHOIS contact emails, or domain authorization documents.


Prior domain validations performed by Certisur, Certsuperior and Certisign RAs will be reused for issuance of pending or future certificates only if proven to be performed and documented correctly by Symantec’s Authentication team.



When you say "Symantec authorized CrossCert to issue certificates from each of the identified CAs", do you mean all five separate certificates listed to the left of this answer in the document? Or do you mean the top list? Or the bottom list? Or something else?

We mean all five issuing CAs:



When the revalidation process is complete, will Symantec be reporting on how many certificates were unable to be revalidated?

Our revalidation will produce (1) confirmation that an existing certificate is properly authorized and the subject information is accurate, (2) replacement of valid certificates with corrected content and documentation followed by revocation or (3) revocation of the certificate without replacement.


We will report a count of certificates for cases (2) and (3).



Further to your third response, can you provide a list of the certificate fields which CrossCert did or did not have control over, and whether those fields had Symantec-side validation with compliance flagging, and whether those flags could be overridden


RA Controlled

(S)creened(2) / Can be (O)verridden




Serial number

No, generated by CSPRNG


Signature Algorithm



Issuer DN




Indirectly by date of approval



Span determined indirectly by end customer choice, can be changed by RA within the max allowed validity






S, O



S, O



S, O













RA can Add/Delete(3)

S, O

Basic Constraints



Key Usage



















No, system generated


(1): These attributes and extensions are static values configured in the certificate profile managed by a change controlled process performed by Symantec Trusted Role personnel.(2) Screened refers to scanning for presence of risk keywords.

(3) RAs cannot edit CN and SAN in individual certificates. When an RA’s enterprise customers request domains to be associated with their organization and enabled for issuance of subsequent certificates, an RA may correct errors in the domain names.



You write: "Further, we have deployed support for, and honor Certification Authority Authorization across all systems to put control of authorized CA’s in the hands of customers". This is great news :-) From what date has this been true? Can you confirm that CAA checking applies to all Symantec-owned brands?

All Symantec brands, channels and platforms enabled CAA checking on various dates ranging from August 20, 2015 to September 15, 2015. We announced support in the STN CPS effective October 1, 2015. This includes certificates issued by all Symantec and reseller-branded issuing CAs within our operations. This excludes two external subordinate CAs chaining to a GeoTrust root and operated by Google and Apple.



Further to your answer about sampling sizes, what (in Symantec's experience) normally defines the sample size an auditor will use when sampling issued certificates during an audit? Is it a fixed number, or defined by the auditor, the issuer, or a dialogue between the two, or some other method?

Sampling size is determined by the auditor using a risk model. It considers automated and manual processes, the CA’s historical performance, CA mis-issuance incidents, complexity of the applications involved and coverage of certificate brands with distinct CPS.

isign.pdf is dated 2012. BRs section 2 say that the CP and CPS need to be annually updated. Do we understand that this did not happen in the case of Certisign?


Same question for CrossCert.

Correct for both RAs, which we refer to as Affiliates in our policy documents.


As documented in the STN CP, Affiliates are bound to operate under the requirements of the STN CP. The STN CP was updated 5 times in 2016.


The STN CP, Certisign CPS, and CrossCert CPS assert: “CAs within the Symantec Trust Network hierarchy conform to the current version of the CA/Browser Forum (CABF) Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at In the event of any inconsistency between this document and those Requirement, those Requirements take precedence over this document.” 


The audit letter verifies conformity to their CPS.  Same applies for CrossCert with that clause. 



[…] in Symantec's most recently reply, [1], it seems that again, on the basis of browser questions from a simple cursory examination that such a statement was not consistent with the data - that is, that the full set of issues were not identified by Symantec in their initial investigation, and only upon prompting by Browsers with a specific deadline did Symantec later recognize the scope of the issues. In recognizing the scope, it was clear that the issues did not simply relate to the use of a particular RA or auditor, but also to the practices of RAs with respect to asserting things were correct when they were not.

Our initial disclosure was released to provide timely information and indicated that our investigation was ongoing. The matters we have reported in subsequent communication result from our own initiative.



Symantec's also stated that, in response to the past misissuance, it deployed a compliance assessment tool, which functionally serves a role similar to a Validation Specialist. However, such compliance assessment was designed in a way that it could be bypassed or overridden without following appropriate policies.

There are two different relevant system checks in place here: (1) A process that subjects all requests against high risk keywords. This keyword assessment tool is designed to enable manual override because it is non-deterministic and can generate false positives in its advice. The tool will flag high risk terms that are embedded within valid and acceptable terms. For example, will trigger the “test” risk term, alerting the RA to examine the request with the additional scrutiny called for by the BR’s definition of a High Risk Certificate Request.

(2) A process that subjects all requests, prior to issuance, against a set of technical compliance checks (e.g. SHA1). These cannot be overridden.



Further, as acknowledged in [1], even when Symantec noted that at least one of their RAs had identified specific deficiencies in practice and issuance, Symantec determined it was not appropriate to notify Root Stores or Mozilla of a "problem report".




As stated in the previous disclosure, Symantec followed what it understood to be the appropriate reporting requirements under the Mozilla policy and appropriate based on the results of the external WebTrust audits conducted.






In response to the issues identified in Question 8 of [1], Symantec noted that one of their RAs was deficient in response to its "policies and business practices change in regards to verification procedures for issuing certificates", and allowed 90 days for the RA to remediate this. However, it does not appear Symantec took any corrective action for the period under audit - a year long period - to review any issued certificates during the period of deficiency.

This excerpt does not correctly represent Symantec’s response to Question 8 in our second response document. The RA produced a qualified audit and we enforced an action plan and remediation.


Symantec was made aware of the need for corrective action at Certsuperior by the qualified audit. Pursuant to the permitted reliance on WebTrust audits in lieu of BR 8.7 self-audit, we did not review issuance nor are any members of the CABF required to review issuance when such audits are performed at least annually.



I highlight this because Mozilla's Policy [7], Item 5, requires such notification to, but Symantec acknowledges in Question 9 of [1] that it failed to do so.

No event occurred at Certsuperior that is subject to the following Mozilla policy statement:


“5. We require that all CAs whose certificates are distributed with our software products notify us when its policies and business practices change in regards to verification procedures for issuing certificates, when the ownership control of the CA’s certificate(s) changes, or when ownership control of the CA’s operations changes. To notify us of updated policies and business practices, send email to or submit a bug report into the Bugzilla system, filed against the "CA Certificates" component of the "" product. The request should include the following:


- the certificate data identifying the CA certificate(s) that are affected by the change;

- copies of (or links to) the updated Certificate Policy or Certification Practice Statement document(s) or equivalent disclosure document(s); and

- a summary of the changes that impact the verification procedures for issuing certificates.”



Symantec's proposed remediation for these issues appears to be limited to:

- Suspend the use of RAs for independent validation of domain control and organizational information

No. It includes:

  • Termination of the RA program permanently, not suspension
  • 100% revalidation of approximately 11,600 active Crosscert certificates
  • 100% automated and manual review of approximately 20,000 active certificates issued by our other three RAs, followed by revalidation as necessary.
  • Disqualification of two branch offices of E&Y for WebTrust audit opinions
  • Creation, execution and monthly review of risk flag clearing reports
  • Retraining of RA personnel to perform a limited processing agent role
  • Inclusion of all future issuance to customers of these former RAs in our 3% quarterly self-audits such that we specifically achieve the 3% threshold within each former RA’s jurisdiction of certificates
  • Submission of our remediation to our next WebTrust audit



1) Given that the Baseline Requirements require that Symantec accept full liability and responsibility for all actions by Delegated Third Parties, can Symantec please provide what were the specific steps and process Symantec's Compliance Team took in reviewing Registration Authorities prior to the detection of this misissuance? Specific example questions


  a) Did Symantec's compliance team independently assess the WebTrust licensing status of each received audit?

  b) Did Symantec's compliance team review the CP and/or CPS of each Delegated Third Party to independently assert compliance with the STN CP/CPS?

As posted earlier, in addition to relying on the results of independent WebTrust audits, for which the answers to (a) and (b) are “yes”, we also:


(i) put in place systematic controls that applied to all certificates, regardless of source, to block and require manual review of potential cases of mis-issuance based on our own experience,

(ii) continued our practice of requiring annual exams on current practices with RAs that made no distinction for test certificates,

(iii) instituted technical checks both prior and subsequent to issuance that applied to all certificates, regardless of source, to block known areas for potential violation like SHA1,

(iv) implemented CAA that applied to all certificates, regardless of source, to enable customers to define for themselves the CAs that they wanted to trust, and

(v) implemented CT logging for all certificates, regardless of source, and developed a CT monitor to enable customers to assess for themselves whether certificates issued for their domains were legitimate.



2) Given that Symantec has noted that RAs bore the capability to override the results of the compliance tool, can Symantec please provide details about every certificate Symantec has issued which has had the compliance check overridden?

Our compliance checks include BR mandates that cannot be overridden as well as high risk terms contained in the fields we explained are screened above. Term screening can produce false positives. Flag clearing does not permit a technically enforceable BR to be violated, it permits an RA to assert that the high risk word is present but validation proves the data in the field to be accurate and verifiable.


We can provide CT log links to all 30,000+ certificates. We may be willing to provide flagged orders on a limited basis, subject to NDA, but given the volume of certificates in question we will not publish this publicly as it could enable a third party to reverse engineer the flagging triggers we check for.



3) Symantec noted in [5] that "Each certificate request is screened for BR compliance failure. Failures are flagged, preventing RA issuance until the flag is cleared." Can Symantec please confirm that "RA issuance" refers to the act of Symantec signing a TBSCertificate and producing a signed certificate, as opposed to any other interpretation, such as Symantec signed the certificate, but did not provide it to the RA until the flag was cleared?

Confirmed. Certificates are not issued unless they contain zero technically enforceable BR violations, such as subject locality and state presence, and all risk word flags are cleared as false positive matches.


Further, note that the only flags that can be overridden/cleared are those raised for high risk words.



4) Was the problematic audit, highlighted in Questions 10 and 11 of [1], CertSuperior's first audit as a Symantec RA?


Stated differently, did Symantec engage in any business relationship with CertSuperior prior to the production of [8]?







5) Symantec's initial response to Mozilla, in [6], indicated that Symantec will be conducting "a review of our delegated RA controls and why we did not detect this problematic behavior before it was reported to us". What is the timeline for when this review will be completed and published?

Based on the review that we have conducted to-date, the findings from which we already published, and the decision to terminate the program and check the validation on all active certificates, we are suspending any further investigation.



6) Please provide the specific dates that Symantec engaged in a Delegated Third Party relationship with each of the RAs, so that the community can independently evaluate the 'scope of the issues' with respect to what certificates may be affected by the issues Symantec has disclosed.

Each of these relationships pre-dated the acquisition by Symantec of the VeriSign Trust Services business in 2010.



7) Are there any elements in the above comparison between the past and present misissuance that Symantec believes are factually incorrect or unsubstantiated that Symantec would like to address or correct?

There are several elements in your comparison that are factually incorrect. details three root causes and associated remediation of the previously reported mis-issuance. links to the unqualified point in time audit reports following the remediation of the previously reported issues.


To be clear, the scope of the 2015 incident involved more procedures that generated mis-issued test certificates than a single testing tool.



Questions dated February 17, 2017:

1) Was Symantec's compliance team involved in the review of Certisign's audit?


2) Does Symantec agree with the conclusion that, on the basis of this evidence, Symantec failed to uphold the Baseline Requirements, independent of any action by a Delegated Third Party?

Yes, we reviewed the calendar year 2015 audit when initially received in January, 2016 and noted a date error that EY Brazil was delinquent in correcting.


No, EY Brazil was licensed for the CY 2015 audit period:



Update March 6, 2017

Symantec Fourth Response to Mis-Issuance Questions

  1. Please provide the CP, CPS, and Audit Letter(s) used for each RA partner since the acquisition by Symantec of the VeriSign Trust Services business in 2010.

    All RA partners operate under the Symantec Trust Network CP which is updated multiple times per year. All RA partners operate under a CPS that is superseded by any differences in the CABR BR. Our RAs archive their policy documentation at the following locations:


    Contrary to our agreements with them and their obligations, RAs have not consistently updated their CPS annually.  This is one reason we decided to terminate the RA program.

    We have provided audits that cover periods beginning when audits were required by CABF BR at

    The following audit is not yet posted, it is not in our online records, we are investigating:
    Certisign: 2012 audit (note: all certificates issued during this audit period have expired)

    Certsuperior began validation of SSL/TLS certificates in 2012. Their audits covering October 2012 onward are posted. We acknowledge that SmartIT is not licensed by WebTrust to perform audits in Mexico for Certsuperior. The Symantec compliance organization detected this error and required Certsuperior to engage a licensed WebTrust auditor during review of their last audit. Certsuperior corrected this and engaged with Deloitte. The timing of that change in auditors drove Certsuperior’s change in audit anniversary date.

    The documents provided allow relying parties to examine the practice and audit of all valid certificates issued by RAs. All RAs, including CrossCert, will be required to complete final audits as we wind down the RA program.