- Wiggly Wayne DDS
- Sep 11, 2010
-
|
and symantec's threw up responses on their misissuances:
Symantec Response B
quote:Issue B: 1024-bit Certificate Issued Directly From Root (Dec 2013 - Jan
2014)
The customer in question informed us of an issue in December 2013 that
threatened to seriously disrupt their primary business, and they sought our
assistance. The customer's non-browser implementation required a certificate
that was back-dated to support its boot phase, not chained through an
intermediate, and that used a 1024-bit key. This would replace a similar
certificate that was due to expire on December 31, 2013.
The BRs in effect at the time (1.1.6) allowed for issuance directly from a
root if five criteria were met, which occurred in this case. As the client
and server required a back-dated certificate during initial boot phase
communication, back-dating was a necessary action in order to prevent
serious business interruption during their peak business. While the
inclusion of our BR OID was an oversight, it was a rule violation rather
than a source of material risk and, as such, did not materially cause harm.
The lack of adequate entropy in the serial number was not a BR violation at
the time (it was a SHOULD). While this lack of adequate entropy in the
serial number was a violation of Microsoft's root policy requirements, the
manager of Microsoft's root program granted us a verbal waiver.
In order to be granted a verbal waiver by Microsoft, we engaged directly
with them to discuss this matter. However, we did not engage the broader
browser community due to the time pressure around the holiday. We seriously
weighed the security risks, and we believed that issuance of this cert
didn't impose risk on anyone but this specific customer, who was willing to
accept it. Further, it's important to understand that this action did not
threaten browser users, as the site wasn't used by browsers. We stand by our
decision to help our customer safeguard their business in this instance, in
a risk responsible manner when they needed us most.
We didn't immediately disclose the issuance due to a contractual obligation
to protect the customer's privacy, which remains in force. We discussed this
obligation with our customer. In line with our commitment to disclosing
these events to the web security community with as much transparency as
possible, we posted our announcement on a Mozilla bug report on February 1,
2014, without using our customer's name.
Symantec Response D
quote:Issue D: Test Certificate Misissuance (April 2009 - September 2015)
Symantec has provided complete investigation results for this issue. They can be found at https://www.symantec.com/page.jsp?id=test-certs-update
We would like to further clarify the following statement in this issue summary: "Some of the test certificates (including one for https://www.google.com) left Symantec's network because they were logged in CT; Symantec claims no others did."
We believe this statement is inaccurate for two reasons.
First, the action of logging certificates to CT does not necessarily mean that the certificates left Symantec's network. Beginning January 1, 2015, Symantec began logging all EV certificates in CT log servers. Given that certificates are logged in CT at the time of creation in our system, any distribution of certificates that we issue is a second, independent step.
Moreover, at the time we investigated this incident, we conducted multiple scans for domains used in test certificates. Following a thorough investigation process, we found no evidence that these certificates were used on external servers. Accordingly, we have no evidence that any of the test certificates involved in this investigation left Symantec's network.
Symantec Response E
Symantec Response F
quote:Issue F: Symantec Audit Issues 2015 (December 2014 - November 2015)
With respect to Issue F, Symantec has no additional comments regarding the perspective outlined in the summary. Please see https://www.symantec.com/about/legal/repository.jsp?tab=Tab3 for further detail on Symantec's previous commentary on this matter.
Symantec Response H
quote:Issue H: SHA-1 Issuance After Deadline (January 2016)
With respect to Issue H, Symantec has no additional comments regarding the perspective outlined in the summary. Please see https://cabforum.org/pipermail/public/2016-January/006519.html for further detail on Symantec's previous commentary on this matter.
Symantec Response J
quote:Issue J: SHA-1 Issuance After Deadline, Again (February 2016)
On February 29, 2016, a CT pre-certificate was generated using a SHA-1 hash. The system checks we had in place at the time prevented new enrollments with SHA-1; however, the enrollment associated with this particular pre-cert specified SHA-256 when it originated in our systems.
As part of our assessment of the situation, we discovered that an enterprise customer used a deprecated, enterprise-only interface that historically allowed them to change the algorithm requested from SHA-256 to SHA-1 after the initial enrollment. While this use case with the deprecated interface was missed during testing, it was promptly patched.
Specifically, we quickly removed the historic interface that allowed algorithm changes after enrollment, and conducted a review to identify any other deprecated interfaces that could cause the same or related issues.
We acknowledge that this CT pre-certificate was a BR violation. The final certificate was not generated, as it was rejected during administrator review prior to issuance.
Our prior public updates about this matter can be found here: https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/symantec$20sha1%7Csort:relevance/mozilla.dev.security.policy/siHOXppxE9k/NNwjrMJ6BAAJ
Symantec Response L
quote:Issue L: Cross-Signing the US Federal Bridge (February 2011 - July 2016)
Symantec, as well as VeriSign, has participated in the FPKI since 2006, and we take our responsibility as a participant of this program very seriously. When Symantec began participating in FPKI, FPKI rules required two-way cross-certification in a networked PKI model. In addition, FPKI rules mandated multiple assurance levels, which we mapped to our Class 1, Class 2 and Class 3 roots. Class 3 roots are the only ones that have ever been enabled for TLS server certificate issuance.
In February 2016, Eric Mill prompted discussions with Symantec and the community about why the cross-certification resulted in some FPKI certs being trusted in browsers at https://github.com/18F/fpki-testing/issues/1. That discussion highlighted that browsers didn't process certificate policy extensions content during path building, while FPKI made extensive use of policy processing. We had already engaged with FPKI personnel to address this concern, and further engaged to determine if one-way cross-certification from FPKI to Symantec was sufficient, such that we could remove the cross-certification from Symantec to FPKI. On July 5, 2016, FPKI notified Symantec that the cross-certificate, which was set to expire July 31, 2016, would not be required.
Because we have a responsibility to our customers to ensure their businesses remain uninterrupted, we knew that communication and giving them adequate time to adjust to the unscheduled change in trust was critical. In order to effect minimal disruption, we allowed the cross-certificate to expire on July 31, 2016, rather than revoking it sooner.
Symantec Response N
quote:Issue N: Premature Manual Signing Using SHA-1 (July 2016)
This matter represents the first time any CA attempted to follow the exception process which was developed over the course of weeks, beginning at the Bilbao CABF face-to-face meeting in May 2016, and with the input of our partners. Google initially proposed this exception process, which was later modified following input from other CABF members. Our internal process did not clearly specify to our PKI Operations team to stop at the point of TBS creation, which subsequently resulted in the creation of signed certificates instead of TBS Certificates. Importantly, our audit process promptly identified the error, and Symantec never released the certificates. We also promptly improved our internal process.
Symantec Response P
quote:Issue P: UniCredit Sub CA Failing To Follow BRs (April - October 2016)
We are committed to keeping our customers, partners and ecosystem informed and taking action when necessary. We recognize that there are issues we are accountable for, such as our March 2016 CA Communication response indicating we had disclosed all subordinate CAs. The omission of UniCredit was an oversight, it should have been disclosed as part of this March 2016 response. However, we were taking appropriate actions to address the underlying compliance issues.
We worked with UniCredit over a long period of time to enforce their compliance with audit requirements. In July 2016, we received an assessment that did not meet WebTrust audit standards. We then took action, helping UniCredit transition to a managed PKI solution for their certificate needs that did not require an audit. In parallel, we notified them of termination of their subordinate CA.
Because our customers are our top priority, we attempted to minimize business disruption while they transitioned by permitting UniCredit to operate only its CRL service until November 30, 2016, at which point we would revoke the UniCredit subordinate CA. In October 2016, UniCredit issued one new certificate in violation of the terms of that transition plan. Following that, Symantec promptly revoked the UniCredit subordinate CA on October 18, 2016.
Symantec Response Q
quote:Issue Q: Symantec Audit Issues 2016 (December 2015 - November 2016)
In our 2014-2015 audits, certain issues were identified that we promptly took action on, including addressing the test certificate incident. We continued these efforts until the Point in Time audit was conducted. We split the 2015-2016 audit reports in order to be fully transparent with the community about our operations after that work was completed. When viewing these sets of audits together, the community can see the steady progress we have made over the past 18 months, in line with our commitment to continually improving and enhancing our processes.
Symantec Response R
quote:Issue R: Insecure Issuance API (2013 or earlier - November 2016)
In April 2015, security consultant Chris Byrne responsibly disclosed two potential vulnerabilities related to our Quick Invite feature, which enables a reseller to invite pre-selected customers to enroll for certificates, via customized emails to the customer that contain deep links for enrollment, specific to the invitee. Consistent with Symantec's commitment to taking action when issues arise, Symantec promptly commenced an investigation following this April 2015 disclosure. As a result, both issues identified in this disclosure were remediated by May 20, 2015.
As there currently seems to be some confusion around this disclosure, we want to provide clarification. First, it is inaccurate to conflate the April 2015 disclosure and the recent RA topic [Mozilla Issue T]. The Quick Invite feature is not an issuance API, and is unrelated to the RA delegated authentication capabilities.
Second, third-party reporting on Mr. Byrne's March 24, 2017 post has suggested that private keys were potentially accessible. Not only is this inaccurate, it's technically not feasible. This is because Symantec does not have access to our customers' TLS server private keys.
The first issue identified in this disclosure only occurred in the case that an invite deep link was intentionally exposed or an attacker had control over a victim's email account, allowing the attacker to click on that link and enable submission of a CSR to the reseller as if they were the legitimate invitee. Even in this scenario, proper domain vetting still happened and the attacker would have still needed to have ownership or control of the domain in the attacker's requested cert before the cert would be issued. Importantly, we do not believe that there was any danger of a cert being issued without proper demonstration of ownership or control of the domain. Nevertheless, as a result of this April 2015 disclosure, and consistent with our effort to continually improve our processes, policies and controls, we now require manual approval in cases where data reuse rules would have previously enabled us to issue based on prior approvals.
The second April 2015 issue was related to the TTL (Time-To-Live) of deep links associated with certificate lifecycle management for our resellers' customers. In this case, if the deep link was somehow exposed or the email account was compromised, an attacker could perform lifecycle operations on that certificate. While our resellers control the TTL of the Quick Invite deep link, which can be set to as little as one day, Symantec controls the TTL of the certificate lifecycle management deep links, which are only sent to the email address associated with the certificate. We proactively changed the TTL of these deep links from five days to two hours in order to reduce the window of exposure in the event the deep links are inappropriately exposed. In both situations, Symantec responded quickly and decisively to remediate the issues at hand and to enhance our overall security measures.
Symantec Response T
quote:Issue T: RA Program Misissuances (January 2010 - January 2017)
Program Background:
Symantec has operated an RA program designed to deliver a superior customer experience in global markets where language skills, understanding of local business requirements, and physical local presence are necessary. RA partners have supported various certificate types, including those for publicly trusted SSL/TLS.
The RA program for publicly trusted SSL/TLS authorized appropriately trained personnel at select RA partners to complete all steps for authentication, review, and certificate issuance.
In 2011, prior to ratification of the CA/Browser Forum Baseline Requirements, Symantec scaled back the scope of the RA program for publicly trusted SSL/TLS to support only those partners whose scale of business and investment in the future success of that business warranted the additional cost associated with supporting the then-new BRs. Since 2013, there have been only 4 RA partners still capable of processing and issuing publicly trusted SSL/TLS certificates: CrossCert, Certisign, Certsuperior, and Certisur.
Symantec has had multiple controls in place to ensure these RAs' compliance with the BRs:
Documentation:
1. Symantec operates an internal Knowledge Base ("KB") for its authentication staff and 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 clearing procedures.
Training & Exams:
1. Topics include BR changes, CPS changes, process changes resulting from 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 changes.
Technology During Authentication:
1. Each request is screened for trade compliance, high-risk names, potential phishing (strings used in scam domains, high-profile brands), and other potentially risky content such as "test". Potential failures are flagged, preventing RA issuance, until and unless further review and analysis is completed.
2. Risk flags require manual override by authentication personnel - internal or RA personal as appropriate - for certificate issuance to proceed. Flag clearing privileges are only granted to personnel who are have completed the requisite training and passed appropriate exams.
Technology Pre- and Post- Issuance:
1. Each request is screened to ensure elements outside of the subject information are BR compliant (e.g. SAN fields are complete, proper validity limits are in place, 2048 bit or higher key lengths are used, etc.). This scan is done after Authentication personnel approve the request and before it is issued. These checks cannot be overridden.
2. Daily, we rescan all certificates issued on the prior day using these same checks.
Audit:
1. We requested independent WebTrust audit reports from RAs and assessed them for material findings pursuant to BR 8.4 regarding WebTrust audited Delegated Third Parties. See issue V addressing audits.
Customer-Facing Controls:
1. Symantec supports Certification Authority Authorization, putting control of authorized CAs in the hands of customers.
2. Symantec logs publicly trusted certificates to Certificate Transparency Logs and offers a CT monitor to provide visibility for all customers to enable detection of suspect certificates.
CrossCert Test Certificate Issue:
On January 19, 2017, Andrew Ayer, an independent researcher posted the results of an analysis of public Certificate Transparency logs through which he identified roughly 270 instances of suspicious certificates issued by multiple CAs, including Symantec, containing the words "test" or "example" in the subject information.
Symantec determined that 127 of these certificates were issued from Symantec operated CAs and that all 127 had been issued by the RA CrossCert. All but 31 had already expired or been revoked.
Immediate Response
Andrew Ayer's report was a certificate problem report under BR 4.9.5 which required us to begin an investigation within 24 hours, which we did. We determined that 127 certificates were in scope of the problem report.
1. On January 19, 2017, after becoming aware of this issue, Symantec disabled issuance privileges for all CrossCert staff.
2. On January 20, 2017, Symantec revoked the 31 still valid and active certificates. These certificates had been issued between December 28, 2016 and January 18, 2017.
3. Symantec promptly took over validation and issuance for all pending and new orders submitted through CrossCert. Since then, Symantec's authentication team has continued to fully process these orders independently, without relying on any previous authentication work completed by CrossCert.
4. Symantec disabled customer issuance from enterprise accounts originally authenticated by CrossCert. New issuance from these accounts was blocked until the accounts were re-validated by Symantec personnel.
Root Cause
Following discussions with CrossCert and review of their audit logs, Symantec confirmed that all 127 certificates were issued as part of either internal or customer-specific testing. In mid-2016, CrossCert created a customer-focused feature with good intent to help customers with testing, but they did so without following the proper guidelines.
CrossCert personnel had completed the Symantec-required training mandating that only fully validated certificates be issued. At no point was CrossCert authorized to perform less vetting on certificates for their own internal use or for customer testing. The personnel at CrossCert had also completed exams designed to verify comprehension of this training. Nonetheless, CrossCert management authorized overrides for certificates being used for internal and customer-specific testing, and CrossCert authentication personnel complied with that authorization.
Audit logs confirm that our controls to flag these certificates for compliance failures worked appropriately but CrossCert management overrode those flags. CrossCert did not consult with Symantec on the significance of the compliance failure flags or their decisions to override the flags for any of the certificates. Our flagging process is extensive and a normal part of every business day. For example, our process catches popular domains/trademarks and variants using fuzzy logic that might otherwise be issued by a CA that doesn't test or block trademark abuse. Our flag/hold rate is conservative - as a result, the false positive rate is high and, following manual analysis, most flags are cleared. We appreciate the suggestion that additional flag monitoring and trend analysis would provide greater insight and increase the opportunity to catch issues like this more quickly in the future.
Review of the 127 certificates showed that all issuances occurred in two time frames: Before June, 2012 or after June, 2016. Symantec received unqualified WebTrust for CAs and WebTrust for CAs Baseline and Network Security audits from Ernst & Young KR for the period July 1, 2015-June 30, 2016. Each of the 127 certificates issued for testing purposes were issued either years before these audits or after these most recent audits and so not detectable as part of these independent audits.
Subsequent Investigation
As part of investigating this incident, Symantec began a direct review of the authentication practices at CrossCert and their engagement with Ernst & Young KR. Through that investigation, Symantec identified two additional issues:
1. There were deficiencies in CrossCert's documentation of the validation step in the authentication process, failing to meet both Symantec and Baseline requirements.
2. The CrossCert 2015-2016 audit did not include in its scope all of the CAs from which CrossCert was authorized to issue certificates. E&Y KR stated that CrossCert provided a list of all their issuing CAs but reduced the list of issuing CAs in scope for sampling for budgetary reasons. E&Y KR did not call out this known limit in its report.
These additional findings caused Symantec to seriously question not only CrossCert, but also the adequacy of E&Y KR's WebTrust for CAs Baseline and Network Security audits. This episode also reinforced that we need to more closely monitor and review the scope, methodology, and practices of external auditors.
Remediation
1. Symantec fully terminated CrossCert as an RA partner. They no longer participate in the authentication process or issuance of publicly trusted SSL/TLS certificates.
2. Symantec has hired a team of Korean speaking authentication personnel who have completed the requisite training and now independently process all new orders from this market.
3. Symantec is in the process of fully and independently revalidating active SSL/TLS certificates previously approved by CrossCert, and if necessary, revoking and replacing certificates if we detect any errors. As we posted in response to the assertion about reusing RA validation in m.d.s.policy, we reiterate that we are not doing this. For CrossCert, we are validating each existing certificate as if it was a new request.
4. Symantec announced the decision to wind down the RA program for publicly trusted SSL/TLS.
5. Symantec is in the process of reviewing 100% of the authentication records for the active SSL/TLS certificates approved and issued by Certisign, Certsuperior, and Certisur. If we become aware of a certificate that is misleading, we follow the Baseline Requirements regarding revocation.
It has been suggested that the issues identified above and those associated with Issue V warrant immediate revocation of all certificates issued by each of these RAs. Symantec disagrees with that assessment. Revocation by a CA of certificates, outside of a customer request, can be materially disruptive to the individuals and the organizations that rely on them, and so should be reserved for cases where there are clear security risks.
In the case of CrossCert, Symantec immediately revoked the clearly problematic certificates mis-issued for testing. With respect to individual certificates, the key additional issue identified with CrossCert related to proper record-keeping. Accordingly, using a risk-informed approach, Symantec is fully re-validating these certificates.
In the cases of Certisign, Certsuperior, and Certisur, we relied on at least one unqualified audit for their operations. With respect to their individual certificates, there was no evidence of any problems with the certificates they approved and issued. Accordingly, and again using a risk-informed approach, Symantec is reviewing all of these certificates, which amounts to conducting an audit with 100% sampling.
Symantec will provide updates to the community regarding our revalidation of active CrossCert-issued SSL/TLS certificates and our review of the other RA partners.
Symantec Response V
quote:Issue V: RA Program Audit Issues (2013 or earlier - January 2017)
Symantec has had two different programs that involve delegated third parties associated with publicly trusted TLS and subject to third-party audits: our GeoRoot program and our RA/Affiliate program.
GeoRoot refers to our program under which intermediate CAs have been created for the sole use and independent operation by specific customers at premises under their control. RA/Affiliate for publicly trusted SSL/TLS refers to our program under which we authorize appropriately trained personnel at select RA partners to complete all steps of authentication, review and certificate issuance.
We refer to the following section of Issue V of the Mozilla post:
"Symantec's RAs appear to have had a history of poor compliance with the BRs and other audit requirements, facts which were known to Symantec but not disclosed to Mozilla or dealt with in appropriately comprehensive ways.
Over multiple years (2013-12-01 to 2014-11-30, 2014-12-01 to 2015-11-30), Symantec's "GeoTrust" audits were qualified to say that they did not have proper audit information for some of these RAs. This information was in their management assertions, and repeated in the audit findings. So the poor audit situation was ongoing and known. Also, other audit reports, despite being in hierarchies accessible for issuance by the same RAs, did not have similar qualifications (Symantec Trust Network, 2014-12-01 to 2015-11-30)."
The audit findings referred to above are specifically related to audits under our GeoRoot program, not our RA program. Because GeoRoot only operates under GeoTrust roots and the associated CPS, the Symantec Trust Network and Thawte audits are fairly stated.
In the GeoTrust WebTrust BR 2015-2016 period in time audit, there were five references to external partners' subordinate CAs, including: Intel, Aetna, UniCredit, Google, and Apple.
Intel: https://crt.sh/?sha1=924b357fc7b9d8c9d26e41d4af4dc6c4babe90e5
Aetna: https://crt.sh/?id=33549
UniCredit: https://crt.sh/?CN=UniCredit+Subordinate+External
Google: https://crt.sh/?CN=Google+Internet+Authority+G2
Apple: https://crt.sh/?CN=Apple+IST+CA%25
Separately, Symantec operates two subordinate CAs solely for NTT DoCoMo in an enterprise PKI application. These subordinate CAs had been considered part of the "GeoRoot" program as well, and we had therefore excluded them (similar to the above externally operated ones) from the list of Symantec CAs in our audits. After reviewing our approach, our compliance team determined that they should be included going forward. As such, for the 2016-2017 Period in Time, these subordinate CAs are included in the GeoTrust WebTrust for CA and BR audits.
For the organizations that externally operate subordinate CAs, the previous audit issues centered on Intel, Aetna, and UniCredit. Intel's subordinate CA, which expired in 2016, was not subject to audits either contractually or by previous agreements with both Mozilla and Microsoft given its limited use. Symantec encountered challenges in getting audits for Aetna and UniCredit, as identified in our 2015-2016 Period in Time audit. After receiving a qualified audit for Aetna, dated May 11, 2016, and an assessment dated March 9, 2016 rather than a WebTrust or ETSI audit for UniCredit, we held discussions with both companies regarding termination of their issuance privileges for new certificates and complete termination of all use as of November 30, 2016. UniCredit violated the requirements that Symantec placed on it for transition and Symantec thereafter promptly revoked its subordinate CA. Aetna's subordinate CA was revoked on November 30, 2016 because they complied with the terms of their CRL-only wind down period.
Symantec provided the letter quoted below to Google, Mozilla, Microsoft, and Apple when we shared the Point in Time Audits on September 6, 2016 to specifically address the GeoRoot audit status and remediation plan. That cover letter outlined the plan to wind down the Aetna and UniCredit subordinate CAs. Symantec received no reponse to our letter to the browser firms and subsequently executed the plan. This activity, along with the final wind down in 2016 of the Intel subordinate CA, were in the scope of our latest audits.
"Dear Browser Community:
The WebTrust Point in Time audit reports have now been issued by KPMG, which had no material findings. The Point In Time is as of June 15, 2016. You can find electronic copies of the reports here: https://www.symantec.com/about/legal/repository.jsp?tab=Tab3.
Please note that the last WebTrust Period in Time audit that covered December 1, 2014 through November 30, 2015, identified two audit reports for partner subordinate CAs signed by the GeoTrust Global CA that were received but were not in accordance with permitted audit schemes. The actions to address these audit reports from the partner subordinate CAs were in progress before the point in time audit started. Symantec has begun the process to terminate the agreements with both partners. One partner has ceased issuance of new certificates and the other will stop as of September 30, 2016. In both cases, Symantec will permit continued use of the subordinate CAs solely for the purpose of signing CRLs through November 30, 2016.
Please reach out to Steve Medin <Steve...@symantec.com> for any questions."
We do not believe we received feedback from the browsers listed above on this approach until March 31, 2017, more than seven months later.
We refer to the following section of Issue V of the Mozilla post:
"We currently know of four RAs who were in Symantec's program - CrossCert, Certisign, Certsuperior, and Certisur..."
CrossCert, Certisign, Certsuperior and Certisur were the RA partners authorized to authenticate and issue SSL/TLS certificates. The collection of their audits was incomplete.
All of Certisign's audits are both WebTrust for CAs and SSL Baseline and were unqualified.
Certsuperior's audits state that their scope was WebTrust for SSL Baseline but do not state WebTrust for CAs. Prior to 2016, Certsuperior provided WebTrust SSL Baseline audits from an unlicensed auditor. Symantec's compliance organization identified the issue in 2016. For 2016, Certsuperior provided a qualified audit by Deloitte, a WebTrust licensed auditor in Mexico. Certsuperior's audit led to immediate sanction to solve the issues detected within 90 days and to provide a Point in Time audit. They provided such audit and it was unqualified. Further, Deloitte is required to examine certificate issuance as a normal part of the WebTrust program and they did not cite any problems with Certsuperior's validation work in either audit. Accordingly, we believe certificate issuance was inspected. Symantec's compliance organization has requested that Certsuperior's next audit explicitly include the criteria in both WebTrust for CAs and WebTrust Baseline.
Certisur's audits were WebTrust for CAs only. Symantec's compliance organization identified the issue and has requested that Certisur's next audit for calendar year 2016 explicitly include the criteria in both WebTrust for CAs and WebTrust Baseline. All audits received were unqualified and performed by a licensed WebTrust auditor.
CrossCert's audits were WebTrust for CAs only through 2015. For 2015-2016 CrossCert provided both WebTrust for CAs and WebTrust BR audits. These audits were all unqualified and all performed by a licensed WebTrust auditor. We subsequently identified an issue with the scope of the 2015-2016 audits which is discussed in our response to issue T.
Symantec Response X
quote:Issue X: Incomplete RA Program Remediation (February - March 2017)
The only Symantec RAs capable of authorizing and issuing publicly trusted SSL/TLS certificates are: CrossCert, Certisign, Certsuperior and Certisur. Symantec continues to maintain a partner program for non-TLS certificates. E-Sign SA and MSC Trustgate are amongst these partners.
|
#
?
Apr 10, 2017 02:42
