• 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
      • 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
      • Website Identity- The Key to Safety in E-Commerce

        Oct 20 2017, 9:17 PM

        by Dean Coclin 0

        Website identity is important for user safety. While encryption is important, knowing who you are encrypting to is paramount when conducting online transactions. While many users can identify the green bar/lettering associated with an Extended Validation (EV) certificate, recent user interface (UI) changes by browsers make it more difficult to differentiate these certificates from low value, domain validated certificates. This makes it a challenge to figure out the true owner of the website.

        For example, Chrome recently changed the certificate UI for Domain Validated (DV) certificates to show a green padlock. With an increase of DV certificates used by fraudsters for phishing (see:, it is becoming more and more difficult for users to determine if a site is legitimate. DV certificates don’t identify the entity behind the website. You just know you are connected to There is no ownership information vetted about Organizationally Validated (OV) and EV certificates provide ownership information allowing a user to know who the site belongs to. But unfortunately, browsers do not distinguish sites with these types of certificates.

        This chart from the CA Security Council (CASC) shows the confusing UIs that are in current browsers: It’s no wonder that users have trouble understanding the differences in the various certificates. And they are constantly changing.  

        A proposal from the CASC for a common, easy to understand, user display for website identity is shown below:


        The members of the CASC which include the 7 largest SSL issuers in the world, are endorsing a paper on Website Identity Principles, which was presented at the RSA Conference on February 15, 2017. There are three main principles that summarize the intent of this paper:

        1.  Website identity is important for user safety.

        2. Different TLS certificate types that are used to secure websites – Extended Validation (EV), Organization Validated (OV), and Domain Validated (DV) certificates – should each receive a separate, clearly-defined browser UI security indicator to tell users when a website’s identity has been independently confirmed.

        3.  Browsers should adopt a common set of browser UI security indicators for different certificate types, and should educate users on the differences among these indicators for user safety.

        More information on these principles is available on the CASC website (

        • Products
        • DigiCert Code Signing
        • DigiCert Complete Website Security
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • Symantec Website Security
      • Combat Advanced Malware With Security and Threat Protection Designed for the Cloud Generation

        Oct 21 2017, 12:02 AM

        by Gerry Grealish 1

        Hackers continue to show endless ingenuity in penetrating corporate networks. In fact, some recent malware attacks made headlines by crippling corporations, robbing shareholders, and damaging the credit of thousands of consumers. These attacks make it clear that cybercriminals continue to evolve, creating threats that can bypass the security defenses of many organizations. Some advanced malware can even sense threat defenses and mutate like a biological virus.

        Determined hackers, coupled with the expanding adoption of cloud applications and the explosion of mobile workforce devices means that enterprises must find new ways to protect themselves from increasingly sophisticated, malicious attacks. It’s a daunting challenge; where can organizations find a solution to combat threats defined by devices, applications, and users everywhere? The answer can’t be found by looking to the stars. However, if you cast your line of sight toward the clouds, you’ll have a clue as to where you should look for a more innovative enterprise security solution.

        The Issue: Evolving Nature of Threats

        As network security advances, so does malware. It is more aware and adaptive than ever, looking for new delivery channels and mutating to evade behavior detection. A few examples include:

        Virtual machine awareness—An increasing number of attackers are creating malware that can detect when it’s operating in a virtual sandbox environment and can execute techniques to disguise itself.

        Polymorphic files and URLs—Malware files can morph and mutate like an infectious virus to escape signature-based detection. Using automated systems, hackers continually change the look of their files and flood these files toward your defenses, hoping one of them will penetrate and begin to operate. Attackers can do similar things with URLs by using domain-generating algorithms (DGAs) to mathematically compute new domains, making it difficult for techniques such as blacklisting to keep pace.

        Multistage, multivector attacks—Sophisticated cybercriminals stage multiphase attacks to get through corporate defenses. Hackers select web-based, email, and file-based intrusions, coordinating them to achieve desired results.

        Encrypted communication—Because most network security systems are unable to scan encrypted data to detect malware, hackers find it effective to use SSL to build communication tunnels between embedded malware and remote command and control (C&C) servers.

        Misleading file types—Malware may masquerade as harmless files. For example, some malware files may pretend to be JPEGs but actually have executable files inside of them. Another malware file can later change itself into an executable (.exe) to unleash the malware inside your network.

        User interaction triggers—Malware may pretend to be legitimate, displaying a friendly or familiar looking dialog box that asks users to install some software. When the user allows the installation, the malware goes into operation.   

        Unique and targeted malware—Some malware can be incorporated into a targeted “spearfishing” attack. If it’s aimed at you, it will trick you into opening a file by using information specific to you. Once opened, the hackers go after the specific assets they’re looking for.

        Enter: the Cloud (or Cloud-Delivered Security) 

        Threat defense needs to be reimagined to address not only the sophisticated nature of the threats just described, but also to ensure it aligns with the realities of how organizations are accessing the web and corporate applications. If your workforce is increasingly distributed, with laptops and mobile devices going directly to the internet to access to SaaS applications, cloud-delivered security and threat protection needs to be on your radar. Cloud-delivered security can be easily provisioned to tackle the security and threat protection needs of all of your web traffic. And the benefit of a subscription-based service is that it can easily scaled up or down to meet changing needs. In addition to ease of deployment, you need to make sure it can deliver the top-notch threat prevention you require. A deeper look at Symantec cloud-delivered security service will help you understand why customers consider our solution to be truly enterprise-class. 

        The Solution: Symantec Cloud-Delivered Security, Malware Analysis Services  

        Symantec Research and Development organization has been busy working to ensure we have strong capabilities to address evolving new attack techniques. We developed a multitiered system that includes advanced analysis techniques to identify and neutralize malware designed to evade detection technology. These techniques block known threats, analyze anything new and unknown, and combat evolved attacks. The entire system is designed to make sure that you get enterprise-class protection while ensuring that false-positives remain extremely low (so precious security and incident response personnel are not wasting time chasing false alarms).


        Web Security Service Leverages the Symantec Global Intelligence Network

        Symantec cloud-delivered Web Security Service (WSS) is fed by our global intelligence network (GIN), the world’s premier civilian cyber defense threat intelligence service. The GIN gives your enterprise the ability to filter URLs into granular categories with defined risk scores. The network uses threat information and telemetry data from 15,000 enterprises and 175 million consumer and enterprise endpoints to categorize and analyze threats posed by more than a billion previously unseen and uncategorized websites each day and more than two billion daily emails sent/received by our customers. Symantec’s unique expertise and analytics uses this information to define the “known bad” files and locations your organization should avoid. Web and file access control policies set in the Symantec WSS ensure that the “known bads” stop at your doorstep and don’t harm your company. The Symantec WSS also leverages content analysis capabilities that perform further analysis on risky files using dual malware engines, as well as comparisons against blacklist/whitelist files. 

        Symantec Malware Analysis Service

        Because it’s extremely difficult for malware authors to evade both virtual and emulative environments, the Symantec Malware Analysis Service works with Symantec WSS to add behavior analysis and sandboxing capabilities for advanced threat detection and prevention. The service uses a powerful combination of emulation and virtualization to identify malicious code. Virtualization takes place in a virtual machine that is a fully licensed version of Windows in which the user can install any application  (Office, Adobe, Quicken, or custom applications). We call it Intelligent VM (iVM). The emulative sandbox environment is not Windows software; it’s a fully recreated computing environment based on a Windows-like API. In this completely controlled artificial space, users can make the malware think it’s interacting with a real computer.

        The Cloud Makes it Easy—Give it a Try

        The Symantec WSS, along with the integrated Symantec Malware Analysis Service, is designed to give you the protection you need to deal with the rapidly evolving advanced threats that are attacking your network each and every day. Contact us to learn how to use our subscription service can help your enterprise protect your corporate assets. Use Symantec to help you enable your enterprise by reliably passing the “known good” and protect your enterprise by reliably blocking the “known bad” and accurately analyzing the “unknown.” 

        Learn more at

        • Products
        • DigiCert Code Signing
        • DigiCert Complete Website Security
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • Symantec Website Security
      • Update on Chrome 53 Bug Affecting Symantec SSL/TLS Certificates

        Oct 20 2017, 8:31 PM

        by Unknown 1

        As mentioned on November 10, 2016, we were made aware of a bug in Chrome version 53 that affects some Symantec, GeoTrust, and Thawte SSL/TLS certificates resulting in an untrusted error displaying when visiting affected websites.  There were no issues with the certificates used on the affected websites, but rather, the issue is entirely a Google bug with specific versions of Chrome, Chromium, Chrome Custom Tabs and WebView.

        Since my initial post, we’ve gained more insight into the scope of impacted platforms and releases for this bug, and although the majority of them have been patched, there is an outstanding issue with Android apps that leverage the WebView version 53. To remedy this problem, end users of affected applications will need to update to the most recent version of WebView (currently, that's version 54) and the forthcoming Chrome version 55 (or later versions). Developers using Android Open Source Platform (AOSP) will need to review their own apps to ensure compatibility.

        Other Chrome-based applications and platforms have been patched by Google including Chrome Mac, Chrome Windows, Chrome Linux, Chrome Android, Chrome iOS, Chromium, Chromium-based browsers, and Chrome Custom Tabs. All of these will operate normally on Chrome version 54 for the time being, and are fully patched in Chrome version 55 (or later versions). We expect no adverse issues on these platforms at this time, and no action should be required by users leveraging typical update mechanisms.

        Update, February 15, 2017: Google reports that bug fixes have been made available across all platforms. However, in some locations those fixes are not automatically deployed to affected customers. Those customers must manually update their applications to take advantage of the bug fix.

        • Products
        • Google Chrome
        • TLS certificate
        • Symantec Website Security
        • SSL
        • DigiCert Code Signing
        • DigiCert SSL TLS Certificates
        • Products and Solutions
      5 pages