• 12 Things to Look for in a Managed PKI Solution, Part 1

        Mar 28 2018, 11:26 PM

        by Lee-Lin Thye 0

        This is the first part of a four-part series covering twelve fundamentals for choosing a managed PKI solution, and questions to ask in the buying process.

        The purpose of this blog is to make you aware that not all Managed PKI providers are the same. In fact, there are some pretty significant differences between DigiCert’s offerings relative to the competition that you wouldn’t see by comparing data sheets. DigiCert’s key advantage is that the Symantec Managed PKI was designed as a service from the ground up as opposed to the competition, that have built their service from legacy on premise software. While the data sheets might look similar, over the next few weeks, we will highlight some of the fundamental advantages of Symantec Managed PKI.

        When it comes to Public Key Infrastructure (PKI), organizations have two deployment options: 1) they can opt for an in-house on-premise solution, or 2) a cloud-based service like Symantec Managed PKI*. There are many benefits to a Managed PKI Service, including faster time to deployment, lower total cost of ownership, and leveraging operational excellence.

        On Premise vs Managed PKI

        1. Shared vs. Dedicated customer PKI roots

        DigiCert performs an independent 3rd party audited Root Key Generation Ceremony (RKGC) for every customer we bring on to the service. In fact, DigiCert performs over 1000 key signing ceremonies every year; more than any other Managed PKI provider in the world. Some providers will “partition” their PKI, and host multiple customers under the same Root. The Root CA is your trust anchor; and it shouldn’t be shared.

        2. Timeliness

        One of the key benefits of a Managed Service is that your Certificate Authority (CA) can be operational much faster than trying to set one up on premise. DigiCert can bring a new customer on to our Managed Service in as few as 10 days from the processing of your Purchase Order. Under special circumstances, we can have it operational even sooner. Competing service providers are typically operational in 8-12 weeks, and don’t always meet that deadline.

        3. Access to Public trust

        In addition to your own private root of trust, DigiCert’s standard offering also provides you with access to a public root, and an Adobe Approved Trust List (AATL) , all accessible and managed from the same web based Administrative portal.  Access to these additional roots enables organizations to meet a variety of additional Enterprise use cases that require external trust. For example, trusted e-mail digital signatures, Adobe document signing, etc. Competing solutions typically only offer private roots of trust, or require you to issue publicly trusted user certificates from a separate portal.

        4. Broad revocation support

        DigiCert supports both Online Certificate Status Protocol (OCSP) and traditional Certificate Revocation Lists (CRL) as part of our standard service. Some of the competing solutions will only offer CRL based checking, and charge extra for OCSP.

        Questions to Ask

        Here are some questions to ask your potential Managed PKI service provider:

        •Do you offer you a shared “partitioned” PKI root, or do you only offer dedicated PKI roots?

        •Do you perform a root key generation ceremony for every customer you bring on to your service?

        •How quickly is the service operational from the time you process my purchase order?

        •Do you have a proven track record of meeting your stated timelines?

        •Can you offer me different roots of trust for all of my Enterprise use cases from a single Administrative portal?

        •Do you include both OCSP and CRL based revocation checking capabilities as part of your service, or is it an additional charge?

        Part 2 in this series will cover some of the DigiCert advantages around Administration and Deployment. Would you need to open a support ticket every time you make an Administrative change to the CA?  I'll cover this and two other fundamentals for choosing a PKI provider in the next post.

        *On October 31, 2017, DigiCert, Inc. acquired from Symantec Corporation the business of providing and supporting Symantec’s Website Security and PKI products and services.

        • Products
        • DigiCert Complete Website Security
        • Managed PKI
        • Products and Solutions
        • PKI
      • Information for Replacement of Symantec SSL/TLS Certificates

        Mar 29 2018, 8:58 PM

        by connect 0

        Recently, Symantec announced that DigiCert, a leading provider of scalable identity and encryption solutions for the enterprise, will acquire Symantec's Website Security and related PKI solutions.  This announcement comes at a time when it’s absolutely critical that businesses are safeguarded from the advanced cyber security threats infiltrating the web. 

        Through this acquisition, customers will benefit from a company that is solely focused on delivering the leading identity and encryption solutions they require as well as an enhanced technology platform, unparalleled support and market-leading innovations.  Symantec Website Security and DigiCert share a strong commitment to customer service, and ensuring continuity for our customers and their businesses is a top priority.

        In response to browser concerns and in preparation for this transition, Symantec Website Security is focused on maintaining your business continuity and avoiding any compatibility issues with regards to the proposed schedule by Google Chrome and Mozilla.  As such, we are proactively reaching out to any customers who may be impacted.

        Google Proposal Background

        On July 27, 2017, Google posted a time-sensitive plan regarding Symantec-issued TLS server certificates. There are critical dates that will impact your operations:

        • Effective December 1, 2017, all Symantec SSL/TLS certificates must be issued from a new PKI infrastructure in order for such certificates to be trusted in Google Chrome.

        • On or around March 15, 2018 (Chrome 66 Beta), Google Chrome will show a warning for sites secured with SSL/TLS certificates issued before June 1, 2016.Your security is not at risk and data encryption will function normally, but your site visitors will be disrupted by a warning in Chrome.

        • On or around September 13, 2018 (Chrome 70 Beta), Google Chrome will show a warning for sites secured with SSL/TLS certificates issued by Symantec’s existing PKI infrastructure.Your security is not at risk and data encryption will function normally, but your site visitors will be disrupted by a warning in Chrome.

        On August 1, 2017, Mozilla stated that it intends to follow the timeline proposed by Google and Google reconfirmed the plan above in its most recent post on September 11, 2017.

        Action to Take Now

        With these dates in mind, we are evaluating all certificates to ensure that your business will remain uninterrupted and will comply with the browser requirements.  By December 1, 2017, our Certificate Authority partner, DigiCert, will begin to provide operations on our behalf that satisfy all of the requirements of Google and Mozilla.

        For those customers with certificates issued prior to June 1, 2016, we are recommending they be replaced by March 15, 2018. We have begun outreach to affected customers and will work directly with them to make the transition as seamless as possible.

        For more information on how to find certificates purchased directly from Symantec that you can replace now, please refer to the appropriate KB Article:

        For customers who did not purchase certificates directly from Symantec, please work with your Symantec Website Security Partner to arrange replacement.

        For those customers who leverage Symantec Complete Website Security, Symantec Trust Center Enterprise, Thawte Certificate Center Enterprise, and GeoTrust Enterprise Security Center, DigiCert will be starting its pre-authentication efforts soon so that come December 1, 2017, any enterprise certificates (new as well as those needing replacement) will be instantly issued.  This pre-authentication effort will be done at no additional cost to you.

        Certificates That Should be Reissued Later

        Some customers will have certificates that should be reissued by DigiCert once it begins operations on our behalf. As we assess the implications of Google’s proposal and upcoming dates, we do not believe you need to take action on additional certificates until that time. DigiCert will begin to provide authentication services on Symantec’s behalf by December 1, 2017, which will provide time for you to reissue and prevent any potential Chrome disruption to your customers before September 2018.  DigiCert will be conducting the full validation at this stage, and upon replacement, certificates will enjoy their full validity within the guidelines of the CA/B Forum.

        We will provide a progress update as soon as we have more information, and specific recommendations on the best timing to reissue your remaining certificates.

        For customer support, please visit

        Thank you,

        Symantec Website Security

        • DigiCert SSL TLS Certificates
        • Products
        • Products and Solutions
      • A New Chapter: DigiCert to Acquire Symantec’s Website Security and Related PKI Solutions

        Mar 29 2018, 8:53 PM

        by Roxane Divol 0

        Today, Symantec announced in a press release an agreement under which DigiCert will acquire Symantec’s Website Security and related PKI solutions. At a time when it’s absolutely critical that businesses are safeguarded from the advanced cyber security threats infiltrating the web, through this acquisition customers will benefit from a company that is solely focused on delivering the leading identity and encryption solutions they require.

        DigiCert is a leading provider of scalable identity and encryption solutions for the enterprise. The fast-growing company currently has a number of high-profile enterprise and IoT customers. DigiCert enjoys a strong reputation and high customer loyalty with a focus on industry-leading customer support, innovative market solutions, and a meaningful contribution to improving industry best practices. DigiCert has earned several awards for its innovation and growth strategies, and this summer was named one of Computerworld’s Top 100 places to work in IT.

        The addition of Symantec’s website security and related PKI solutions to DigiCert’s offerings will provide customers with an enhanced technology platform, unparalleled support and market-leading innovations. DigiCert will have incredible talent and experience to lead the next generation of global website security and will gain capabilities to take advantage of opportunities in IoT and bring new approaches to the SSL market.

        Symantec Website Security and DigiCert share a strong commitment to customer service, and ensuring continuity for our customers and their businesses is a top priority. Once the transaction is complete, we will work to transition our customers to a new platform that meets all industry standards and browser requirements and provides the foundation for future innovation in the CA space.

        Importantly, we feel confident that this agreement will satisfy the needs of the browser community. DigiCert is communicating this deal and its intentions to the browser community and will continue to work closely with them during the period leading up to our closing the transaction. DigiCert appreciates and shares the browsers’ commitment to engendering trust in digital certificates and protecting all users.

        Last but not least, I’d be remiss to not personally thank each and every one of the hard-working and dedicated employees of the Website Security team. We are tremendously excited about the opportunities ahead and deeply committed to the success of this transition for the Website Security business, its employees, and our customers.

        Best Regards,

        Roxane Divol

        Executive Vice President & GM, Symantec Website Security 

        • Products
        • DigiCert Code Signing
        • DigiCert Complete Website Security
        • DigiCert SSL TLS Certificates
        • Products and Solutions
      • Symantec’s Response to Google’s subCA Proposal

        Oct 20 2017, 8:38 PM

        by connect 1

        Our primary objective has always been to minimize any potential business disruption for our customers and for browser users while also reassuring trust in Symantec certificates and our issuance practices. While we believe we achieved that balance with our original proposal to the community, the browser community (specifically, Google, Mozilla and Opera) has since converged upon a new proposal.   

        Google shared this new proposal for Symantec’s CA with the community on May 15. We have since been reviewing this proposal and weighing its merits against feedback we’ve heard from the broader community, including our CA customers. As part of our review, we’ve conducted a preliminary analysis of the engineering, contract and business development requirements needed to implement the subCA portion of the proposal outlined by Google. Additionally, we have had initial conversations with candidate partners (or “SubCAs”) to understand the potential timeline and integration constraints that would need to be factored into a successful adoption of a subCA approach. While we are waiting to receive detailed responses to a Request For Proposals (RFP) from these potential SubCAs, we wanted to share our initial feedback to Google’s current proposal.

        First, we acknowledge the mis-issuances we’ve experienced in our CA business and we take these incidents very seriously. We believe these incidents are the exception and not the rule for our CA operations. Our CA business is led and staffed by experienced individuals around the world who serve our customers while ensuring our issuance practices comply with industry and browser requirements. 

        That said, we understand that any failure of our SSL/TLS certificates to be recognized by popular browsers could disrupt the business of our customers. In that light, we appreciate that Google's current proposal does not immediately pose compatibility or interoperability challenges for the vast majority of users. Indeed, while there are significant backend changes required under Google’s latest subCA proposal, we believe it is designed to minimize impact to our CA customers and browser users. Notably, Google’s current proposal preserves the treatment of Symantec EV certificates and provides a pathway for us to continue supporting our customers with industry standard certificate validity periods. Furthermore, the current proposal allows our customers, for the most part, to have an uninterrupted and unencumbered experience.   

        However, there are some aspects of the current proposal that we believe need to be changed before we can reasonably and responsibly implement a plan that involves entrusting parts of our CA operations to a third party. 

        As the largest issuer of EV and OV certificates in the industry according to Netcraft, Symantec handles significantly larger volumes of validation workloads across more geographies than most other CA’s. To our knowledge, no other single CA operates at the scale nor offers the broad set of capabilities that Symantec offers today. In addition to the vetting required to identify suitable CA partners, we believe there may be a significant ramp up period required for any CA to augment the resources needed to accommodate our certificate issuance volumes in a robust, reliable, secure, and fully compliant way. Before a technical integration and transition can begin, Symantec would need to evaluate the capabilities of interested and qualified CAs. We would also need time to put in place the governance, business and legal structures necessary to ensure the appropriate accountability and oversight for the subCA proposal to be successful. 

        Once we enter into a partnership with one or multiple SubCAs, Symantec and the SubCA(s) will need to perform engineering work to support the subCA model. These implementations would then need to be tested extensively. 

        Given the time needed to overcome these challenges, we have proposed modifications that we ask Google, Mozilla, other browsers, relying parties and the community to consider as we work to reach a final plan. Our goal is to move to an agreed-upon action plan that we can begin to implement in a reasonable timeframe that ensures a smooth transition. Detailed in-line responses to various parts of the proposal, along with clarifying questions, are provided below.

        Google’s Original Post (May 19)

        Overview / Background

        Here's an update on the discussions about Symantec-issued certificates and the steps Chrome is proposing to move forward. Thank you to everybody who has contributed to the discussion so far.

        On May 12, members of the Chrome team met with Symantec to discuss the set of concerns and our proposed remedy for them. These discussions were an expansion on a proposal previously shared with Symantec in April, and later shared on the list.

        When the original Intent to Deprecate was posted, I proposed a plan that tried to best address issues we were aware of and provide a long-term path for comprehensive protections. We received a lot of great feedback from the Blink and wider PKI communities regarding the impact this plan would have and further issues to consider. In light of this feedback, we would like to propose a new plan that we believe ensures users are sufficiently secured while trying to minimize disruption to site operators, and providing an objective and reasonable path forward for those that have critical dependencies on certificates that chain to Symantec-operated roots.

        We want to share an overview of this plan with the broader community, with more specific, detailed requirements at the end. The high-level overview of the plan is:

        • Symantec will modernize their platform and PKI dedicated to website certificate issuance. Symantec has previously posted that this in their current roadmap, and we require that the modernized platform adheres to best practices for CAs in security, design, and process as part of that modernization process.
        • Until the modernized platform is ready and accepted into major trust stores, certificates would need to be issued through one or more independently operated third-party CAs (aka “Managed CAs”) that Symantec would partner with.

        Symantec In-Line Response: While adhering to best practices for a modernized platform is self-evident, what process do Chrome and the community foresee as appropriate to establish this trust?

        • The Managed CAs could be cross signed by an agreed upon set of existing Symantec roots, to take advantage of the existing roots' ubiquity in trust stores.
        • EV certificates can be issued by Managed CAs, provided that they meet the validation requirements.
        • Validity period of new certificates can be up to 39 months, or to the maximum allowed by Chrome for all CAs (currently specified in the Baseline Requirements and EV Guidelines), provided that a Managed CA fully revalidates the information. During a bridge period, Managed CAs can reuse existing validation information but lifetimes must be limited to 13 months.
        • Existing certificates issued on or after June 1st 2016 would still be trusted, provided they comply with the Chrome CT policy. EV certificates issued on or after this date will continue to be granted EV treatment.
        • Existing certificates issued before June 1st 2016 would go through a phased distrust based on notBefore dates.

        Symantec In-Line Response: This part of the proposal introduces a substantial additional authentication effort for SubCAs on top of an already challenging requirement to scale their processing capacity. Symantec has been logging all EV certificates to CT since Jan 1, 2015 and a large proportion of other certificates since prior to June 1, 2016. This distrust would affect over 425,000 certificates, of which ~130,000 have been logged to CT. Given that CT logging appears to be foundational, we would like to propose that ongoing trust be extended to any Symantec CT qualified certificate issued after Jan 1, 2015 as it currently is today in Chrome.

        • Chrome will offer an Enterprise Policy to allow older certificates to be trusted to help with migration to the new PKI.

        While the plan is not final, we believe it is converging on one that strikes a good balance of addressing security risk and mitigating interruption. We still welcome any feedback about it, as prior feedback has been valuable in helping shape this plan.

        Transition to a New Symantec PKI

        Chrome will require that by 2017-08-08 all new Symantec-chaining certificates be issued by independently operated third-parties (aka “Managed CAs”).

        Chrome will implement a check, on-or-after 2017-08-08, to enforce this by ensuring that the certificate chain contain a whitelist of intermediates (independently operated sub-CAs or the Managed CAs).

        Symantec In-Line Response: See date comments below.

        If a Managed CA has fully revalidated the information, the validity period of new certificates can be up to the maximum allowed by Chrome for all CAs, which is currently specified as the maximum allowed by the Baseline Requirements and EV SSL Guidelines.

        During a transition period, validation information can be reused, provided that the certificate is issued by the new infrastructure. However, the validity period of such certs must be no longer than 13 months.

        If Symantec needs this flexibility, the following deadlines apply:

        • 2017-08-08 - Certificates must be issued by the Managed CA, but can re-use existing validation information (up to the limits imposed by the Baseline Requirements).
        • 2017-11-01 - Certificates must be issued and have domains revalidated by the Managed CA, but can use re-use existing organization validation information (up to the limits imposed by the Baseline Requirements).
        • 2018-02-01 - Certificates must be issued and have all validation performed by the Managed CA.

        Symantec In-Line Response: Based on our initial research, we believe the timing laid out above is not achievable given the magnitude of the transition that would need to occur as we discussed at the beginning of this post and we propose that Google not conclude on final distrust dates for Symantec certificates at this time. We have conducted outreach to candidate partners (SubCAs) to understand the potential constraints, timelines and the integration work that might be needed. We have also formalized and issued a RFP with specific questions around timing, logistics and dependencies. We expect to have the required feedback to inform a project plan by the end of June, at which time we will come back to Google and the community regarding suggested dates that are both aggressive and achievable. In the meantime, we wanted to share some of some of the practical and constraining reasons that we believe the dates will need to be adjusted:

        • In order to ensure that the expected bar is set in terms of issuance, validation and availability, we are in the midst of a rigorous RFP process which will include detailed diligence for potential SubCAs in terms of controls and compliance performance.
        • Post-RFP, partnering requires Symantec to work with competitors and establish business relationships that are acceptable to all parties.
        • Symantec is currently the single largest issuer of OV and EV certificates, as reported by Netcraft. Potential partners (our existing competitors) may not have built out their infrastructure to handle the capacity increase they would experience with serving Symantec’s existing demand. The buildout of infrastructure and authentication capabilities will require ramp-up time. Based on conversations held so far, this ramp up time may be greater than 4 months. Additionally, Symantec serves certain international markets that require language expertise in order to perform validation tasks. Any acceptable partner would also need to service these markets. Executing on a subCA plan would therefore require us to go down one of two paths:
          • Establish several relationships with multiple CAs which would require multiple contract negotiations and multiple technical integrations.
          • Partner with a single SubCA, which would require such CA to build up the compliant and reliable capacity necessary to take over our CA operations in terms of staff and infrastructure.
        • SubCA partners would need to potentially revalidate over 200,000 organizations in full, in order to maintain full certificate validity for OV and EV certificates – this would increase the immediate capacity required for these partners and put the timing proposed by Google at risk. As an example, full review of our Latin American partners, and full revalidation of CrossCert’s active certificate issuances has been time intensive. Applying significant resources and performing the checking and revalidation for the approximately 30,000 certificates (with far fewer organizations) issued by our former SSL/TLS RA partners has taken over 4 months. The practical revalidation effort for under this proposal should not be underestimated.
        • We anticipate that designing, developing, and testing new auth/verif/issuance logic, in addition to creating an orchestration layer to interface with multiple subCAs will take an estimated 14 calendar weeks. This does not include the engineering efforts required by the subCAs, systems integration and testing with each subCA, or testing end-to-end with API integrated customers and partners, although some of this effort can occur in parallel.

        The use of existing or new validation information in a certificate should be signalled by using new OID in the Certificate Policies extension. See the Technical Details section for more information. If the managed CA is unable to validate the information by such milestones, then such certificates will not be able to be issued or trusted.

        Existing Certificates

        Chrome will continue to trust certificates issued after 2016-06-01, provided they are “CT Qualified” as defined in the Chrome CT Policy.

        Enterprise Chrome users will be given a policy to allow certificates issued before 2016-06-01. This will give enterprise administrators the ability to control Chrome behavior for their organizations. This can be specified both at device-level as well as at user-level.

        We’re proposing a phased distrust of all website certificates issued prior to 2016-06-01, which is the date in which Chrome both required and enforced Certificate Transparency. This provides a degree of assurance for site operators that certificates issued for the improper domain have a reasonable chance of being detected. With this, our goal is to attempt to minimize disruption to site operators, ensure reasonable notice of these changes, and avoid particularly sensitive holiday disruptions. These plans represent target dates, which may need to be adjusted based on interoperability or compatibility risk or additional information coming to light that may accelerate such distrust.

        • On 2017-08-31, no longer trust any certificate whose notBefore was prior to 2015-06-01. This corresponds with an expected Chrome 62 date.
        • On 2018-01-18, no longer trust any certificate whose notBefore was prior to 2016-06-01. This corresponds with an expected Chrome 65 date.

        Symantec In-Line Response: As previously mentioned, Symantec has been logging EV certificates to CT since Jan 1, 2015; and a proportion of other certificates since before June 1, 2016. Given that CT logging appears to be foundational, we propose that ongoing trust be extended to any Symantec CT Qualified certificate issued after Jan 1, 2015. Doing so would reduce the incremental re-authentication effort from over 425K certificates to ~295K – a meaningful reduction in the re-authentication effort necessary under this part of the proposal.

        In terms of specific feedback on certificate distrust dates and the associated distrust waterfall, we must consider the information that will be returned to us as part of our current RFP process before we revert to the community with suggested dates that would not cause undue disruption to our CA customers and browser users. In the meantime, we propose that Google not conclude on final distrust dates for Symantec certificates at this time.

        Technical Details


        • These sub-CAs must be operated by a non-affiliated organization that operates roots currently trusted in the Android and Chrome OS trust stores that have been trusted for a period of at least two years.
        • The non-affiliated organization must accept full responsibility for the operation of these sub-CAs and agree that any misissuance from these sub-CAs will be treated as if it was misissuance from any of the other CAs the organization operates. Similarly, any misissuance from the other CAs the organization operates will be treated as if it was misissuance from these sub-CAs. Because the basis for trust in these intermediates will be based on chaining to the existing Symantec root certificates, rather than to a different organization’s CA certificates, Symantec must also accept responsibility for the operation of these sub-CAs and agree that any misissuance from these sub-CAs will be treated as if it was misissuance from any of the other CAs that Symantec operates.

        Symantec In-Line Response: We would treat SubCAs as Delegated Third Parties and as such subject to audit under section 8 of the Baseline Requirements. However, given the possibility that multiple SubCAs may be required to accommodate the scope of our operations, it’s important to clarify that the actions of one SubCA should not automatically reflect on the operations of a separate SubCA. Can you further explain your rationale and intent on this point?

        • Symantec and its affiliates must not participate in any of the information verification roles permitted under the Baseline Requirements, such as Delegated Third Parties, including that of Enterprise RAs, or as Validation Specialists. That is, the non-affiliated organization bears full responsibility to perform all information verification controls related to the issuance of the certificates. Symantec and its affiliates may, however, seek to collect and aggregate all of the information as part of the Certificate Request process in order to expedite and simplify the verification process.

        Symantec In-Line Response: In Symantec’s current authentication model, there is a two-step process, where validation of an order is done by one person and then that work is reviewed independently by another prior to issuance. To expedite the timing of our implementation of this proposal and to offset the ramp time needed for SubCAs to increase their authentication capacity, we suggest that Google’s proposal be modified to allow Symantec to conduct the first step of the validation, subject to 100% review of 100% of the orders by the SubCA, and issuance determination made by the subCAs.

        • These sub-CAs must not be used to certify any Symantec-operated or -controlled CAs, but may themselves be certified by existing Symantec-operated or -controlled CAs. That is, they can be cross-signed by the existing infrastructure, but they must not cross-sign any of the existing infrastructure or certificates.
        • No Delegated Third Parties shall be used to perform the information verification functions of domain verification (Section of the Baseline Requirements) or IP address verification (Section of the Baseline Requirements)
        • The Certificate Policy and Certification Practice Statements (CP/CPS) for the sub-CAs may use Symantec’s domains for purposes of CAA verification, as they are operating on behalf of Symantec.

        Symantec In-Line Response: Where SubCAs use Delegated Third Parties in their existing CA operations, we propose that such SubCAs be permitted to continue to use such Delegated Third Parties with respect to performance of its responsibilities for the benefit of Symantec under this proposal. Restricting use of Delegated Third Parties by SubCAs under this proposal may limit the interest of SubCAs to partner with Symantec under this proposal and/or increase their cost to partner with Symantec under this proposal.


        • Within 90 days of the first certificate being issued by any of these sub-CAs, the operating organization shall provide a Period of Time audit report according to the “Trust Service Principles and Criteria for Certification Authorities” and the “WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network Security.” If Symantec desires for these sub-CAs to be recognized as capable of issuing EV certificates, Symantec shall also provide a “WebTrust Principles and Criteria for Certification Authorities - Extended Validation SSL.” All audits shall use the current version of the criteria appropriate for the audit engagement date. The period of time must include the moment of the Key Generation Ceremony, must not exceed 120 days in duration, and must not be less than 30 days in duration. Note that 90 days represents when the report shall be provided, not the end of the period of time.

        Symantec In-Line Response: We agree with the subsequent discussion on audit timing:

             T0: Key Generation Ceremony
             T+30-60: First server auth certificate issued
             T+90-120: End of period (not less than 60 days after the prior T+timepoint)
             T+180-210: Opinion published (not more than 90 days after end of period)

        • The audit report scope must include all Principles and Criteria and include all locations in which the key material exists. If a Principle or Criteria is excluded from the scope due to the non-performance of that function, the audit report and management’s assertion letter must attest that no organizations, including the operating organization, performed that role or function for the Period of Time under audit.
        • An unbroken sequence of such audit reports shall be posted publicly and provided to Google no more than 90 days after the conclusion of the audit period. For the first year following the issuance of the first certificate, the audit period shall not exceed 90 days. For the second year, the audit period shall not exceed 6 months. For third and subsequent years, the audit period shall not exceed 12 months.

        Symantec In-Line Response: Given that Symantec would partner with SubCAs that are established CAs, we do not believe these SubCAs should be burdened with audit requirements that exceed their requirements today. We believe it should not be necessary to force these SubCAs to provide audits with greater frequency than what they are currently required to do outside of the initial one outlined in the first audit bullet, which can be used to confirm that the transition was successful.

        • Any and all subordinate CAs certified by these sub-CAs must be covered by the same CP/CPS, management’s assertion, and audit reports as the sub-CA itself. That is, any sub-CAs beneath these sub-CAs must be part of the same infrastructure and operation of the non-affiliated organization.

        Certificate Details

        • In order to be trusted, issued certificates must be “CT Qualified”, as defined in the Certificate Transparency in Chrome Policy.
        • Each certificate must clearly identify the degree of information that has been revalidated. To accomplish this, we propose that Symantec make use of three newly-defined OIDs, to be allocated by Symantec, and to be placed within the Certificate Policies extension, with a distinct OID for each of the following scenarios:
          • Issued on new infrastructure, but reusing existing information previously validated or obtained by Symantec.
            • Certificates bearing this policy OID MUST NOT be valid for longer than 400 days.
          • Issued on new infrastructure, with domain information having been validated by the organization operating the Managed CA for Symantec, but containing and reusing organizational information validated previously by Symantec.
            • Certificates bearing this policy OID MUST NOT be valid for longer than 400 days.
            • As DV certificates do not contain organization information, no DV certificates should bear this policy OID.
          • Issued on new infrastructure, with all information contained having been validated by the organization operating the Managed CA for Symantec.
            • Certificates bearing this policy OID MUST NOT be valid for longer than the maximum time permitted by Chrome for all CAs at the time of issuance, which is currently defined within the CA/Browser Forum’s Baseline Requirements.

        Transition to New Infrastructure

        • Until such a time as Symantec’s new infrastructure has been accepted as trusted for TLS server certificate issuance in the root stores used by the Stable version of Chrome on the most recently released, generally available version of the supported OS platform Chrome is running on, the sub-CAs must continue to be operated according to the requirements outlined here.
          • At this time, this includes the root stores of Microsoft (Chrome on Windows), Apple (Chrome on macOS and Chrome on iOS), Mozilla (Chrome on Linux) and Google (Chrome on Android and Chrome on Chrome OS). And would include any future Google root store program used by Google products and services.
        • In continued collaboration with CPA Canada and the WebTrust Task Force in determining the feasibility and appropriateness of such reports, as part of the determination for acceptability of the new infrastructure, Symantec may be requested to provide a report on controls at the Certification Authority that includes a description of the auditor’s tests of controls and results, covers a period of time, and includes a description of the system. The intended users of the report must include persons who assist in decisions related to the trusted status of Certification Authorities within Chrome and Google products.

        Symantec In-Line Response: Symantec is willing to provide such reports under non-disclosure agreements where they include detailed information of a sensitive nature (similar to sharing SOC2 reports with specific customers).

        ***** End of Google's Original Post and Symantec In-Line Response*****

        NEXT STEPS

        We believe that we are on the path to reaching an agreed-upon plan that can be implemented in a reasonable timeframe and ensures minimal disruption for our customers. We will continue to pursue what we believe is the right course of action that allows for a smooth transition and reassures trust in Symantec certificates and our issuance practices. We welcome continued input from Google and the browser community as we work to reach a final agreement that serves the best interests of all stakeholders.

        • Products
        • Products and Solutions
        • DigiCert Complete Website Security
      • What is HTTP Public Key Pinning, and how can you get it right?

        Mar 30 2018, 4:19 PM

        by Rufus Connell 0

        HTTP public key pinning (or just ‘public key pinning’ or HPKP) is a security mechanism designed to improve online privacy. But like other mechanisms, such as Certificate Transparency (CT) and Certification Authority Authorization (CAA) checking, it has its drawbacks.

        In this article we’ll explain what public key pinning is, discuss its problems, and explain how you can implement it both securely and effectively. 

        The context

        First, let’s take a step back first and review the basics: client/server applications use the Transport Layer Security (TLS) protocol to communicate across a network. TLS aims to provide a level of privacy and security between client/server applications in a way that prevents eavesdropping, tampering or message forgery. It typically involves a client connecting to a server and proving that the server has a private key chained up to a root certificate in the client’s trust store.

        When TLS/SSL was first envisaged, it was considered a foolproof way to connect clients and servers without the risk of man-in-the-middle (MITM) attacks. However, over time, people realized that another entity could sit in between client and server (creating two TLS connections in place of one) without revealing itself to either end. There are legitimate uses for this, but malicious parties can do this too. This is where HPKP comes in.

        HTTP public key pinning: the how and why

        Public key pinning is a mechanism for detecting and blocking certain kinds of man-in-the-middle attacks.

        So how does it work? A domain owner pins the hash of one or more public keys in the certificate chain for their website, creating what is called a HPKP policy. This policy specifies hashes for one or more of the certificates in the website’s public key certificate chain.

        When someone visits the website, it returns the public key pins to the visitor’s browser via HTTP headers. The browser checks that at least one of the pins is valid for the certificate chain, and caches the pins for the next visit. In order to validate the chain, at least one of the certificate chain’s public keys needs to match a pinned public key.

        The whole mechanism tells an application that the certificate chain from a server must contain at least one of the pinned certificates - and to sound the alarm if it finds none. In doing so, users can be more certain there is no-one interfering with (or eavesdropping on) communication over a network, which is especially important for websites that handle sensitive information like healthcare or financial records.

        Above all, public key pinning gives domain operators the ability to reduce the risk of MITM attacks and other false-authentication problems. But it’s not a silver bullet, and it does have its drawbacks.

        Public key pinning is not foolproof

        Although public key pinning can reduce the risk of a MITM attack, it’s not a perfect defense against attackers - especially those capable of passing certificate chain validation procedures.

        In reality, public key pinning is a brittle mechanism and can be problematic by design. Here are some of the issues:

        • Pins have a set lifetime. Once set in a browser’s cache, they remain valid for a period of time and become associated with a unique cryptographic identity that your website must possess to remain in operation. If you lose these and you don’t have a backup key, you’ll effectively block clients from visiting your website.
        • It’s tricky to setup and deploy. If you ever change your configuration by, say, renewing a certificate, you need to make sure that at least one pin matches the configuration you offered to previous users. If it doesn’t match, you’ll block clients from visiting your website.
        • It can be abused by motivated attackers. If someone breaks into your server and gains control of your website, they can alter HPKP policy and serve alternate pinning instructions to your user base. If they later remove these pinning keys, your website will be ‘bricked,’ meaning that clients will be blocked from visiting.

        With great power comes great responsibility: how to get HPKP right

        Public key pinning is powerful, but it can be dangerous too - especially given that the risk of misconfigured pinning policies is quite high.

        Our advice is to avoid deploying HPKP unless you’ve studied the specifications, have a system in place for auditing your configuration (and to detect unwanted pinning) and have a strong understanding of the necessary steps. You should also be careful which certificate you pin to.

        When a Certification Authority (CA) certifies your website’s domain, they’ll give you an end entity certificate signed by an intermediate certificate that is, in turn, signed by a root certificate embedded in browsers. We recommend pinning to the end entity certificate. Why? Because this means you can update your pin whenever your end entity certificate is updated. Pinning an intermediate or root certificate is more dangerous because the CA might change them without knowing that you are using them as HPKP pins.

        Pinning your end entity certificate is a little more work than pinning to your intermediate certificate or root certificate, but you remain in control.

        • DigiCert SSL TLS Certificates
        • Products
        • Products and Solutions
      • Migrating from SHA-1 to SHA-2: what’s all the fuss about?

        Mar 29 2018, 11:00 PM

        by Rufus Connell 0

        At the beginning of 2017, SHA-1 collisions quickly became a reality. With millions of TLS certificates still relying on the SHA-1 based signature algorithm for data integrity, upgrading to SHA-2 certificates is now a critical necessity.

        Firefox and Chrome have already ended their support of SHA-1 TLS certificates, and Safari is set to follow suit this spring. For those still using the deprecated hash function, the security and reputation of your website is at greater risk.

        Symantec has long supported the move to SHA-256 signed certificates and now we are urging you to make the switch as soon as possible, if you haven’t already.

        What are SHA-1’s biggest flaws?

        While the NSA officially deprecated SHA-1 in 2011, in February 2017, Google and CWI Amsterdam exposed its theoretical vulnerabilities in practice. 

        Growing computational power is increasing the probability and affordability of these collisions. Google’s success proves two disparate data files can now obtain the same digital signature in a viable timeframe. This weakness can be abused to target vulnerable TLS and SSL certificates, allowing bad actors to certify malicious websites and code by assigning them the hash function of an authorised certificate.

        Posing as a Certificate Authority (CA), an attacker can sign their own certificates using SHA-1’s vulnerability and appear to hold the private key of a legitimate certificate. Browsers won’t flag these certificates as rogue because the hash function features in their list of trusted signatures. The attackers can then redirect users to a malicious website, maintaining the HTTPS security icons of the original.

        Since SSL and TLS certificates are synonymous with data protection, a reliance on SHA-1 could spark widespread manipulation from hackers in the near future.

        Why is SHA-256 so superior?

        SHA-256 is significantly different from SHA-1, and addresses all the vulnerabilities present in its predecessor. By switching to SHA-256, website owners can protect against the rising likelihood of an attack. While a SHA-256 collision is achievable in theory, in practice it would take today’s top-performing processors billions of years to compute.

        At a granular level, its superiority comes from its increased bit-size (256 bits compared to SHA-1’s 160). While this might not seem like a radical change, the bit-size of SHA-256 protects it against the brute force of current collision attacks.

        With browsers now ending their support for SHA-1 certificates, websites and systems that continue to use the hash algorithm will soon find their SSL/TLS certificates untrusted. Since SHA-256 shows no signs of the same vulnerabilities, replacing outdated certificates will prevent issues with user access.

        Why is now the right time to migrate?

        Despite its known weaknesses, many website owners still employ the SHA-1 has in certificate encryption. Their reluctance to upgrade stems from three factors:

        • Migration time
        • Migration cost
        • Fear of technical issues

        But these aren’t valid excuses, especially when you consider the consequences of not upgrading. By the end of spring, all major browsers will have ended their support for SHA-1. These changes affect active SSL/TLS certificates as well as expiring ones, flagging your site as untrusted when users attempt to connect. The only way to avoid this inconvenience is to make the switch to SHA-256.

        With Symantec, you can migrate in four simple steps:

        1. Inventory your certificates. Discover and manage your SSL/TLS certificates with the Symantec Certificate Intelligence Center. You can deploy this tool to check for existing SHA-1 certificates.
        2. Replace all SHA-1 certificates. Once you’ve located all SHA-1 certificates, create a new Certificate Signing Request (CRS) for each, and submit it to Symantec. While this takes time, it’s a crucial step in protecting your website’s future. We’ll renew every certificate with SHA-2 for free. 
        3. Install new certificates. The next step is to install these certificates on you network. Follow our installation advice to ensure you’re installing them correctly on your specific server vendor.
        4. Test your certificates. Use our CryptoReport tool to check for successful SSL/TLS certificate installations and remove cross-root certificates to ensure better performance and security compliance.

        Audit and secure all your defences

        SHA-1 is the most talked about vulnerability in cybersecurity right now, but you shouldn’t neglect or forget to patch other weak links in your system defences. Our Complete Website Security package includes SSL/TLS certificate assessment, DDoS protection and a Secure App Service so you can focus on converting leads and generating profit.

        • DigiCert SSL TLS Certificates
        • Products
        • Products and Solutions
      • Code signing minimum requirements: standardizing the security of digital signatures

        Mar 29 2018, 9:00 PM

        by Rufus Connell 0

        Following collaboration between the Certificate Authority Security Council (CASC) and Microsoft, a series of Minimum Requirements (MRs) are now in place for all code signing authorities. For business owners, this will help standardise security protocol. The main requirements to consider are:

        • The use of verified company names, state and locality
        • The storage of private keys
        • New timestamping procedures

        As a long-time advocate for these baseline requirements, Symantec is reconfiguring its own authentication process in order to comply with the CASC’s decision. Through widespread adoption of the MRs, signed code use will become significantly securer and more transparent.

        In this article, we’ll discuss how the new regulations will improve your business’ security.

        The Microsoft story: preventing an increase in certified malware

        The driving force behind Microsoft’s bid for code signing standardization is the rise of certified malware.

        ‘Previously, there were no standards, which meant that if one CA rejected a company’s application, that company could submit the same application to a different CA,’ said Dean J. Coclin, Senior Director, Business Development at Symantec.

        With many untrusted CAs in operation, a fraudulent company could continue applying for a certificate until they found a negligent CA willing to authenticate their submission. Incidences of stolen certificates have also increased, with thieves using compromised user keys to digitally sign their own malicious code.

        While Microsoft has been able to track and revoke many of these certificates using its SmartScreen filter, it could do little to prevent misconduct from reoccurring. However, the introduction of MRs makes it easier for CAs to identify the original code publisher and authenticate its digital signature.

        The benefits of universal code-signing regulations

        From a business perspective, the MRs will enable end users and companies to verify and use code with increased assurance. Here are four ways the CASC guidelines will improve code verification:

        1.     Stronger private key protection

        The theft and improper issuance of private keys enables the authentication of malicious code by attackers. Under the new regulations private keys must be kept in secure locations, preferably in hardware, either on-premises or in a legitimate cloud-based code-signing service, to help prevent this threat.

        If a CA generates the private key on behalf of a subscriber and transports it from a secure infrastructure, it must be encrypted with at least 128-bits of encryption strength or transferred via hardware with an equivalent activation method.

        2.     Easier certificate revocation

        If an application software supplier such as Microsoft discovers that one of its users has published malicious code (malware), it will request a certificate revocation. Exploiting keys and running malware is extremely profitable, since there has always been a window of vulnerability before a CA can discover and revoke the associated certificate.  

        The MRs now dictate that a CA has two days to revoke the certificate or launch an investigation into its use, closing this window and ensuring rogue code is caught and eliminated earlier. Businesses that register with untrusted CAs are likely to find their certificates questioned in the future, so it’s important you choose a compliant authority with a strong reputation.

        3.     Standardized Blacklisting

        A higher standard of individual authentication will make it more difficult for bad actors to obtain code signing certificates. The new MRs require CAs to check blacklists of known and suspect malware during identity verification. These are provided by anti-malware organisations and application software providers.

        CAs must also maintain an internal database of revoked code signing certificates (used to sign malicious code) and rejected certificate requests. The aim is to prevent bad actors from switching between CAs in order to get their code authenticated.

        4.     Improved timestamping

        Timestamps are important for businesses that require extended signature verification. The use of a timestamp allows code to be trusted beyond the expiration of the associated certificate. Authenticating code signatures in this way gives relying parties the ability to identify when a certificate was issued and whether it was valid at the moment the timestamp was given, even if that’s after the certificate has expired.

        Symantec offer time-stamping as part of the code signing process, ensuring your code is recognised and accepted by Microsoft software. We create digital timestamps for Windows, Adobe, Android, Java and more.

        What are my code signing options?

        As an enterprise, it’s important to know where you stand. In terms of code-signing, you have two options when it comes to key management:

        1. Local certification – you’re responsible for managing your own certificates, private keys, and code-signing processes. You must contact your chosen CA for certification.
        2. Service orientation – If your CA provides code-signing as a service, and it complies with the MRs, it will have to employ multi-factor authentication.

        Symantec’s Secure App Service (SAS) provides code-signing and time-stamping, with two-factor authentication as standard. Since February 1st 2017, we’ve introduced new measures to our SAS to improve the security of your certificates:

        1. The SAS API now requires the use of both user/password credentials and a client certificate.
        2. The SAS portal now requires both a client certificate and a One-Time Password (OTP) authentication mechanism, provided by our Symantec VIP solution.

        Because Microsoft owns more than 90 percent of the desktop OS market, we’re striving to meet the company’s MRs and ensure our customers can continue to digitally sign and use their software without constraint. 

        • Products
        • DigiCert Code Signing
        • DigiCert Complete Website Security
        • DigiCert SSL TLS Certificates
        • Products and Solutions
      • Symantec CA’s Initial Response to Google’s Revised Proposal

        Mar 29 2018, 8:38 PM

        by Roxane Divol 0

        Today, Google put forward a revised proposal regarding our CA business, which we are currently reviewing. Google’s proposal follows collaborative and constructive community discussions. Our goal has been to reach a solution that minimizes disruption for our customers and is in the best interests of the entire Internet community.

        While there remain details to be considered, we believe Google has put forth a new proposal that limits business disruption for customers as compared to prior proposals. Notably, Google’s revised proposal would not require Symantec to move to shorter-term validity certificates beyond what was approved by the CA/B forum in Ballot 193 for all CAs and Symantec’s Extended Validation certificates would remain intact. Given the potential impact of any changes that might be implemented, we are carefully reviewing this proposal and will respond shortly with feedback for the community’s consideration.

        We thank our customers and the community for their patience and participation in this important discussion.

        Best Regards,

        Roxane Divol

        Executive Vice President & GM, Symantec Website Security

        • DigiCert SSL TLS Certificates
        • Products
        • Products and Solutions
      • Symantec CA Continues the Public Dialogue

        Mar 29 2018, 8:57 PM

        by connect 0

        We believe that we have put forward a proposal [1] that provides the highest level of transparency and reassurance of trust in active SSL/TLS certificates available in the industry.  We also believe that our proposal avoids the imposition of significant compatibility and interoperability risks, as well as customer business disruption, which would result from any proposal that limits the trust of existing Symantec SSL/TLS certificates, imposes shorter validity periods on newly issued Symantec certificates, and/or removes EV recognition for our certificates in browsers. This post responds to comments about our proposal made by Ryan Sleevi in his post summarizing Google’s discussions with Symantec [2] and by Gervase Markham in his draft proposal on behalf of Mozilla [3].

             1.  We are confident in our issuance processes and in the additive protection measures already in place, which is why we are conducting extensive audits that will be made public as outlined in our proposal. We have proposed audits that go far beyond the scope of traditional WebTrust for CAs and Baseline Requirements audits.

                  a.  In the case of EV certs we will have an external auditor examine 100% of the active EV certificates issued. We are confident in our processes and a full, detailed external audit is the best mechanism we are aware of to showcase this.

                  b.  In the case of our SSL/TLS RA program, we have taken the most conservative action possible: we have shut it down. Additionally we have almost completed our revalidation of every active certificate that our former TLS RA partners have authenticated. As of May 4, 2017, the status of the revalidation or review of the active certificates authenticated by our former TLS RA partners is as follows:

                                  CA response chart.jpg

        * The certificates in the “Errors” column of the table above, which we have revoked and replaced, were due to spelling mistakes in information in the organization name, imprecise values in locality (e.g. related to the name change of Distrito Federal to Ciudad de Mexico, similar to those called out by other CAs and considered acceptable exceptions to the Baseline Requirements by Google [4] and Mozilla [5]), or instances where we did not receive sufficient documentation to substantiate subject information. In the case of Certisur, after receipt of additional substantiating information and further review, we concluded that 6 of the revoked certificates were compliant with the Baseline Requirements and satisfied Symantec policies.

                  c.  Further, we have proposed to have an external auditor revalidate all of our work described in the table above with RAs and make that report public. For clarity, we are not proposing an audit that is subject to standard audit sampling practices, but rather third party review and validation of 100% of these active, RA-validated certificates.

             In addition, we previously added extensive controls to our issuance process in response to the 2015 test certificate mis-issuance incident documented here [6]. This included an automated compliance checking engine that blocks non-compliance with the Baseline Requirements.

             Moreover, the additional transparency we are already providing by logging all certificates issued to Certificate Transparency logs – including DV and OV – is a practice that the rest of the industry has yet to adopt. This transparency effort included explicitly providing to Google for whitelisting the certificates that were issued by Symantec prior to us fully deploying CT support.

             Finally, we have proposed moving to quarterly WebTrust audits going forward to provide the community with even more frequent updates on the reliability of our processes.  

             These measures are designed to demonstrate the integrity of our active certificates and to provide timely visibility into the integrity of our future certificate issuances. A third party review of all (100%) active EV and RA-issued certificates is at the extreme end of transparency and we believe such reviews will assure the community about our issuance practices.

             2.  Mr. Sleevi has set forth a second proposal that involves Symantec outsourcing its SSL/TLS issuance to a third party. We have evaluated this sub-CA proposal and believe it is unwarranted and not proportional to the actual or perceived risk that is mitigated under our proposal. We believe our issuance processes are sound and that the transparency initiatives outlined above – specifically, published reports from our third party audits that we expect to complete by August 31, 2017 – will confirm this for the community. Until the audit results are available for public review, we think it is premature to suggest that Symantec consider any such sub-CA proposal.

             3.  While we recognize that shorter validity certificates may reduce exposure to certain security risks, we believe any such change must be consistent across the entire CA industry and be phased in over a period of time taking into consideration existing barriers to adoption. Both Mr. Sleevi (in his latest proposal) and Mr. Markham propose a 13-month validity limit for Symantec certificates. Limiting Symantec’s ability to issue longer-lived certificates while not imposing that same limit on other CAs is uniquely punitive to Symantec’s CA business and unjustified. We also do not believe that a 13-month validity limit should be imposed on the CA industry at this time – a conclusion that is reinforced by the recent CA/Browser Forum vote rejecting ballot 185, which proposed to limit the maximum validity of SSL/TLS certificates issued by all CAs to 13 months. As we have stated in our public response, many enterprises are not at the level of automation maturity necessary to practically and cost-effectively adopt shorter validity certificates. For these organizations, standardizing on shorter validity certificates would present substantial increases in their operating costs. A significant percentage of our active certificates have a validity period greater than 13 months. We have heard from many customers that they will move to another CA if a major browser limits the validity of Symantec certificates to 13 months or less to avoid the operational burden of replacing certificates more frequently – particularly when commercial alternatives exist. If this action is taken exclusively against Symantec, it will create significant disruption for hundreds of thousands of customers / users and will harm our CA business.

                  In light of the difficulty of currently operationalizing the replacement cycle of short-lived certificates for many of our customers, we have proposed 9-month domain revalidation of all of our certificates. An initial certificate validation is one level of authentication. Certificate domain revalidation post-deployment further extends the trustworthiness of the initial certificate, which is a positive extension of the CA trust model.  This 9-month domain revalidation proposal is intended to supplement our proposed expanded offering of shorter validity certificates for those customers for whom it would be a significant burden to adopt them. We’ve proposed reporting our revalidation findings externally and, working with the browser community, we believe we can establish appropriate transparency mechanisms (e.g. through an OCSP extension or a signed revalidation list) that provide an attestation to this revalidation and ensure accountability of our implementation of this action.  We’ve also proposed continuing our investments in automation to enable organizations with even the most complex infrastructure to practically and cost-effectively adopt shorter validity certificates.  

             4.  Portions of Mr. Sleevi’s sub-CA proposal were redacted and he mentioned that Symantec shared additional details with Google during our joint meetings that Symantec did not make public in its response. In our private discussions with Google, we shared key elements of our current solution roadmap, which, as a normal evolution of our business, includes enhancing our issuance platform to create a competitive advantage in the marketplace. We publicly highlighted our investments in this area in our proposal as part of our discussion of automation and supporting shorter validity certificates – specifically, “[o]ur near term investments will focus on modernizing our certificate issuance systems and workflows to enable faster issuance, and developing tools that enable customers to rapidly and securely implement their certificates and configure their systems.” We intend to keep the community informed about our progress here as part of the quarterly updates we have proposed to deliver to the community.

        In summary, we believe our proposal provides the most open and transparent posture of any CA in the industry and reassures trust in active Symantec certificates and our current issuance practices. Our proposal also mitigates the significant compatibility and interoperability risks, as well as customer burden, which would result from any proposal that limits the trust of existing Symantec SSL/TLS certificates, imposes shorter validity periods on newly issued Symantec certificates, and/or removes EV recognition for our certificates in browsers.

        We understand our role as a key player in the trust ecosystem of the Internet and take it very seriously, including the obligation to follow the compliance frameworks set forth by the CA/Browser Forum and browser root programs.  We believe the error rate of our issuances is low compared to our peers and we welcome objective third party information that puts this into context. While third party, comparative data from Netcraft supports our position that our certificate issuances are equal to or better than other CAs, we always work to do better.

        We encourage the community to consider objective, comparative results of our processes with others along with the merits of our proposal. It is important that any actions taken by Google and Mozilla don’t overreach and result in unnecessary business disruption to customers and users of sites that rely on Symantec SSL/TLS certificates. We believe careful and deliberate consideration of the strengths and weaknesses of Symantec’s proposal as compared to those proposed by Google and Mozilla requires more time than has been implied by Mr. Markham and should involve more feedback from the affected stakeholders in the Internet ecosystem than has been received to date.  To that end, we recommend that Google and Mozilla take the time to proactively reach out to the enterprises whose voice is greatly underrepresented in these forums to truly understand the customer use cases we have described and the reasoning behind our proposal.








        • DigiCert SSL TLS Certificates
        • Products
        • Products and Solutions
      • Symantec CA Response to Google Proposal and Community Feedback

        Oct 20 2017, 8:54 PM

        by connect 1

        We take our role as a key player in the trust ecosystem of the Internet very seriously. We believe that secure and compliant issuance of SSL/TLS certificates is fundamental to the security of the Internet and that we have a responsibility to collaborate with our customers and the broader community to continuously improve industry standards, and specifically our practices, for certificate issuance.

        On March 23, Google posted a blog outlining a proposal to change how Symantec’s SSL/TLS certificates are recognized in Chrome. Their proposal stemmed from prior certificate mis-issuances that occurred in our Certificate Authority (CA) business, which we have taken extensive remediation measures to correct. We have carefully reviewed Google’s proposal and sought input from the broader browser and user community on this topic, which has informed our continuous improvement planning. This post outlines important measures that we propose to implement in our CA business. We believe our proposal addresses the concerns raised by Google about our CA business without imposing undue business disruption on our customers and Chrome users that we believe would result if Google implements its proposal.

        Feedback from our Enterprise Customers

        In addition to our review of public commentary on these issues, we have also sought input and feedback from Symantec customers on the compatibility and interoperability impact of the significant changes that could result from the implementation of Google’s proposal. These customers include many of the largest financial services, critical infrastructure, retail and healthcare organizations in the world, as well as many government agencies. This cohort is an important constituency that we believe has been under-represented to date in the public commentary that has been posted to the Google and Mozilla boards since large organizations rarely authorize employees to engage in such public discussions, particularly in an area related to security. We first solicited feedback to understand the disruption that a browser-initiated trust change, like the one proposed by Google, would cause organizations that opt to replace their existing SSL/TLS certificates in order to maintain interoperability with all browsers. We learned that these organizations’ publicly facing web applications, while extensive, only represent a fraction of their dependency on publicly trusted Symantec roots. Many large organizations have complex, and potentially undocumented and little-known dependencies on their certificate infrastructure. Examples of complex dependencies on Symantec public roots that our customers have shared or we have identified include:

        • Embedded devices that are pinned to certificates issued by a Symantec public root to communicate to resources over the Internet or Intranet. Replacing these certificates would result in immediate failures and the need to recode and reimage the firmware for these devices.

        • Mobile applications that have pinned certificates. Replacing server certificates would require these applications to be recoded, recompiled and redistributed.

        • Critical infrastructure organizations that use certificates issued off of Symantec roots to validate internal and external resources. In many cases, the applications being used are pinned to Symantec certificates.

        • Some large organizations use certificates chained to Symantec public roots for nearly all internal applications and communications. Many of these organizations are under regulatory requirements to encrypt even internal communications.

        Additionally, many of these organizations estimate that just the planning process to prepare to move to a new certificate authority could take many months and in some cases years because of unknown and undocumented dependencies. Moreover, few large enterprises that we’ve received feedback from have implemented the level of certificate lifecycle automation required to enable safe and cost-effective adoption of shorter validity certificates. We believe that it is important for the broader community to understand and give more weight to these compatibility and interoperability risks, particularly given the fact that many of these organizations are prohibited from commenting publicly on these topics.

        To give a perspective of scale, Symantec secures more than 80% of the world’s ecommerce transactions through its certificate infrastructure. Additionally, Symantec is the world’s largest provider of Organization Validation (OV) and Extended Validation (EV) certificates which are primarily used by large enterprises. Many of these certificates sit inside corporate and government networks and are an important part of the trust fabric of internal communications.

        In short, our assessment based on customer feedback is that the interoperability and compatibility failures that could result from a large-scale certificate replacement or invalidation event would be significant and unpredictable.

        Our Proposal to the Community

        We understand the importance of providing transparency into our CA operations and responding to community questions and feedback to inspire trust. We propose to undertake the following actions in response to browser concerns and customer feedback as well as to increase trust and confidence in our processes and our commitment to the compliance frameworks set forth by the CA/B forum and browser root programs.

        Our EV Process

        Symantec has some of the most comprehensive Extended Validation processes in the industry. We have, on occasion, been criticized for the time it takes us to validate EV certificates while some of our competitors boast rapid (15-20 minute) validation times for EV. We believe that issuing an EV certificate represents the highest bar of certificate validation in the industry and that the process used to validate these certificates must be conducted with the appropriate care. The widespread adoption of Certificate Transparency for EV certificate issuance now makes it possible for independent third parties to compare the accuracy of these issued certificates. One such organization, Netcraft, has been evaluating EV issuance over time. Figure 1 below (source: represents their findings of Symantec EV certificate compliance compared to the rest of the industry.

        CA Blog.png

        Figure 1 - Symantec vs. Rest of Industry on EV Certificate Requirements.

        The Netcraft numbers demonstrate strong EV requirements compliance for Symantec relative to our peers. Our point-in-time and recent period-in-time audits have demonstrated that we are issuing EV certificates in accordance with industry requirements. We are confident in our EV issuance practices, which we have informally benchmarked against other CAs. We believe our EV validation processes are among the most thorough ones employed by any CA. Nevertheless, to reassure the browser community regarding our EV issuance practices we propose to undertake the following:

            1.  We will commission a third party auditor to perform a backward-looking audit of all active EV certificates that have been issued by Symantec to give comfort around the validity and integrity of our EV certificates and our EV certificate issuance practices. This action is proposed as an alternative to Chrome’s suggestion to remove EV treatment of past or future issued EV certificates, which we believe is unjustified. We believe this additional audit of our EV certificates provides full transparency into our EV certificate practices and reaffirms confidence that our active Symantec EV certificates are trustworthy. Our intention is to complete this third party audit by August 31, 2017.

        Registration Authority Authenticated and Issued Certificates

        Historically, Symantec has issued SSL/TLS certificates either directly or through Registration Authority (RA) partners who have issued such certificates on Symantec’s behalf. We want to provide assurance that all Symantec certificates are properly issued. With these issues in mind:

             2.  We will commission a third party auditor to attest to the list of active certificates that had been issued by any prior SSL/TLS RA partner, including CrossCert, Certisign, Certsuperior and Certisur. The purpose of this action is to provide transparency regarding existing certificates validated by RA personnel. We believe this action also provides additional assurance regarding the efforts we have already undertaken to revalidate all active CrossCert certificates as well as review 100% of the certificates issued by the other former RA partners. Further, we will ask our external auditors to audit 100% of the work we have done to revalidate or review and, where necessary, remediate active certificates issued by all of these former SSL/TLS RA partners. Our intention is to complete this third party audit by August 31, 2017.

        Increased Transparency 

        We recognize that an accurate understanding of our past incidents is important to enable an objective evaluation of any proposal regarding this topic. We have responded to, and will continue to review and respond to the salient questions posed on the post at the forum to provide further transparency into our past compliance incidents.

        Furthermore, we understand the importance of providing increased transparency into our CA operations. As part of our effort to do so, we will do the following:

           3.  We will conduct a six month period-in-time WebTrust audit for the period from December 1, 2016 to May 31, 2017. We will thereafter move to a cadence of quarterly WebTrust audits (in lieu of annual period-in-time audits), beginning with the period from June 1, 2017 through August 31, 2017, until such time as we receive four consecutive quarterly WebTrust audits without qualification. The purpose of this action is to provide greater transparency regarding our operations and new certificates issued by Symantec going forward.

           4.  We will publish a quarterly letter to update the community on the progress of our third party audits identified in this proposal and the progress of our continuous improvement program that incorporates the other actions in this proposal.  

           5.  We will work through the CA/B forum to recommend new (or where applicable, updated) guidelines for appropriate customer exception requests to baseline requests. While the CA/B forum has developed a process for exception requests, we believe it should consider further guidelines to assess the risk associated with these requests and determine conditions under which the CA/B forum might expeditiously approve exception requests.

           6.  We will endeavor to improve the timeliness of our responses to the browser community as well as the level of technical detail we provide in them, balancing the interest of the community to receive prompt responses to their questions with the time required to perform the investigative steps necessary to provide thorough responses to such questions.

        Move to Shorter Validity Certificates

        We support the added option of shorter validity certificates, as do several browsers and others in the ecosystem. Shorter validity certificates can reduce exposure in the case of an undetected key compromise, enable faster adoption of improvements to industry standards (e.g. move to ECDSA or SHA3), and drive more rapid remediation of potential TLS-related vulnerabilities (like Heartbleed) that can require certificate replacement.

          7.  By August 31, 2017, we will begin to broadly offer SSL/TLS certificates with three month validity periods to give our customers greater choice and flexibility in the validity periods of the certificates they purchase and deploy from Symantec. From the customer feedback we have received to date, we believe this offering may be most attractive to customers that have already enabled automation, such as customers and partners integrated with our APIs and e-commerce customers with less complex environments. In addition, we will continue our investments in automation to enable organizations with even the most complex infrastructure to practically and cost-effectively adopt shorter validity certificates. Our near term investments will focus on modernizing our certificate issuance systems and workflows to enable faster issuance, and developing tools that enable customers to rapidly and securely implement their certificates and configure their systems.

          8.  We will perform a domain revalidation of all issued certificates that have a validity period longer than nine months at the nine-month mark (at no additional cost to our customers). This approach is intended to balance the customer impact of replacing certificates, for those not ready to move to shorter validity certificates, with visibility that ensures that certificates are being used appropriately. We commit to working with the browser community regarding appropriate transparency mechanisms (e.g., an extension of CT logging, OCSP extension, signed DNS text record, or signed revalidation list) that provide an attestation to this revalidation and ensure accountability of our implementation of this action. An initial certificate validation is one level of authentication. Certificate domain revalidation post-deployment further extends the trustworthiness of the initial certificate, which is a positive extension of the CA trust model.

        Continuous Improvement of our CA Operations

        We seek to continuously improve our systems and processes around certificate issuance. With this in mind:

          9.  We are further increasing our investment in the Security and Risk function of our CA operations, with a focus on our security and compliance controls and risk assessments. As a first step, we are commissioning a third party to conduct a process and systems risk assessment of our CA operations. The scope of this assessment will include an inventory of our systems and use cases, and a review of the security controls we have in place with respect to all of our PKI services, including SSL/TLS certificates. This third party assessment will also incorporate red teaming and penetration testing of our processes and systems beyond what we do already. The purpose of this third party risk assessment, which we expect to complete by October 31, 2017, is to provide increased confidence in the risk management posture of our CA operations beyond WebTrust audit reports.

        10.  We will update our Root Program to more directly compartmentalize different certificate use cases. This update will involve creating dedicated roots and/or sub-CAs, for example, to segment customers who today use our publicly trusted hierarchies for closed ecosystems like set-top boxes, for customers who have mixed ecosystems like point-of-sale systems and ATMs which connect to the same servers as browser-based applications, for customers who choose to use longer validity certificates, or for customers who serve disproportionately large web traffic. As certificates expire, we will issue new certificates that chain to the use case-appropriate roots.

        11.  Industry analysts estimate that 50% or more of all network attacks targeting enterprises this year will take advantage of SSL/TLS encryption to bypass security controls. We believe that CAs have a necessary and critical role to play in validating whether an encrypted website is malicious. Symantec’s technology infrastructure includes a Global Intelligence Network that analyzes websites, domains, servers and web services at scale and runs both real-time and background checks on such external hosts, including over a billion previously unseen and uncategorized websites a day. Our Global Intelligence Network includes technology that categorizes websites into over 80 categories – e.g., “Financial Services,” “Education,” “Malicious Sources/Malnets” or “Suspicious” – based on linguistic analysis, inter-site relationships, host-attribute analysis and reputation and history. Modules within our Global Intelligence Network analyze site content such as images, video and embedded links and can run in-depth content analysis in over 50 languages to help categorize sites and identify potential risk. We will begin to use our Global Intelligence Network to identify encrypted websites that have an increased threat risk based on our rating categorization and take appropriate action to mitigate risk for our certificates associated with such sites.

        Even though our past mis-issuance events have not, to our knowledge, resulted in customer harm, we consider compliance with industry standards a critical responsibility of our CA business. We believe our multi-faceted proposal addresses the concerns regarding the trustworthiness of Symantec’s past and future SSL/TLS certificate issuances. We also believe our proposal appropriately balances these concerns with the significant compatibility and interoperability risks, as well as customer burden, which would result from any proposal that limits the trust of existing Symantec SSL/TLS certificates, imposes shorter validity periods on newly issued Symantec certificates and/or removes EV recognition for our certificates in browsers.

        We welcome constructive feedback to our proposal, which we understand may take time for the Internet community to fully consider. In the meantime, we will continue to solicit feedback from our customers and partners, which are important stakeholders that will be impacted by changes to our operations, whether as a result of our proposal or any other.

        • Products
        • Products and Solutions
        • DigiCert Complete Website Security
      7 pages