• Transitioning from SHA-1 TLS Certificates

        Oct 20 2017, 9:02 PM

        by Unknown 4

        Since its founding, Symantec has been dedicated to security.  That is our raison d’etre. As such, we continually collaborate across the industry to update standards, making them more secure and harder to hack or fake. That is why the CA/Browser Forum determined that Certification Authorities must not issue public SHA-1 TLS certificates after December 31, 2015. While this directive is an important step in making the Internet safer and more secure, the transition process also needs to support companies with legacy systems and devices so they are not left behind or saddled with insurmountable IT costs.

        We liken this to when the US government determined that the use of lead paint was unsafe and should stop being used. That directive was absolutely the right thing to do moving forward, but to require that every house and building in the US remove all lead paint by a certain deadline would have created financial and logistical impossibilities for consumers and businesses.  While it is correct to strive for the perfect ideal, the real-world implications are often a bit messy.

        In the same vein, the shift to the SHA-256 standard severely impacts legacy systems and applications.  We heard from some of our customers that they could not switch out every certificate in every application and device, not only because of the time and cost involved, but also because many of the systems and some older browsers simply don’t support SHA-256.  While we fully support and encourage the transition to SHA-256 from a security purist standpoint, we also believe it is unreasonable to force our customers to absorb significant business and financial hardships that could severely impact their viability and operations, as well as that of their end users. 

        Therefore, we were left with a choice: either force customers to completely cease support of all those legacy systems, applications, devices and browsers that cannot support SHA-256, or try and identify ways to help ease the transition for customers to SHA-256 while minimizing the risk of continued SHA-1 support for those customers who still need it.

        In an effort to help these customers, Symantec, along with other CAs and Microsoft, proposed a CA/Browser Forum ballot to allow continued issuance of SHA-1 TLS certificates into 2016, as long as those certificates expired by the end of 2016 – providing additional transition time for those who needed it. During the ballot debate, researchers unveiled new attacks against SHA-1, revealing the algorithm to be weaker than originally thought. As a result, the ballot was withdrawn.

        Throughout 2015, Symantec and other CAs issued fewer and fewer SHA-1 TLS certificates as we transitioned to certificates signed with the newer, stronger SHA-256 hash algorithm. That was as expected, since the industry has been working for several years to manage this algorithm transition.

        We’re now beyond December 31, 2015 - the SHA-1 issuance deadline set by the CA/Browser Forum Baseline Requirements. And as we look back over the last three months of 2015, it’s clear that customers had planned around this deadline as we experienced a last-minute surge in customer orders for SHA-1 certificates in December:







        Many customers clearly chose to enroll for and to obtain SHA-1 certificates as close as possible to the end-of-2015 issuance deadline, something even recommended by one of the browser members of the CA/Browser Forum.

        But we have customers for whom even all of 2016 is not enough time to transition. For these customers, we have identified another way to help – to use our legacy public roots for specific use cases (such as with legacy feature phones) while instructing browsers, and all other clients that can, to stop trusting these roots for general applications.  Given the nature of the attacks on SHA-1 and other hashing algorithms, the best defense is really in the hands of the browsers and other clients to remove support for SHA-1 altogether.

        With that goal in mind, we reached out to browser vendors in November 2015 to formally advise them to remove or “un-trust” our legacy PCA3-G1 root if they had not already done so (some had removed the root earlier in 2015). With browsers discontinuing support for SHA-1 and our PCA3-G1 root specifically, the general risk of a SHA-1 attack is substantially reduced.  This multi-prong approach strikes the hard-sought balance between our intent for stronger security and our intent for a practical transition for all involved. Even this approach is proving more difficult than expected, as it created issues for some clients, such as those with older Android devices and for some code-signing customers on Windows. Given additional transition time potentially needed by these clients, we will continue to include our legacy PCA3-G1 root in our annual WebTrust for CAs Audit so anyone still supporting these roots can be confident that certificates issued from these roots are issued in line with our public Certificate Policy and Certificate Practices Statement.

        While moving to a private CA root can help those customers with incompatible systems, Symantec has repeatedly directed all of our customers who can to make the transition to SHA-256 as quickly as possible.  The guide we issued on moving from SHA-1 to SHA-256 certificates can be found in our Knowledge Base

        Symantec fully supports the deprecation of SHA-1, but we are also acutely aware of the difficulty this transition poses for many enterprise customers and technology providers across the ecosystem. We have put in place measures that we hope balances the very real business needs of our customers with the goal of creating a more secure web environment. As a founding member of the CA/Browser Forum, we wanted to be open and transparent about how we have tackled this transition and why we made the decisions we did to both advance adoption of the latest security standards while finding practical ways to support our customers who are struggling with very tangible issues.

        • Products
        • migration
        • Symantec Website Security
        • SHA-1
        • DigiCert Code Signing
        • DigiCert Complete Website Security
        • certificate
        • SHA-2
        • Products and Solutions
        • Root
      • Raising the Bar for Security and Trust on the Web

        Sep 11 2015, 7:38 PM

        by Brook Chelmo 1

        Recently, Symantec updated its certificate issuance controls to pay special attention to domains flagged for excessive abuse, malware, spam, and other suspicious activity.  We recently received intelligence that .PW domains had a history of suspicious and abusive behavior.  After further analysis, we decided to place a hold on issuing minimally-authenticated Domain Validated SSL/TLS certificates and are instituting a policy of only offering the stronger authenticated Organization and Extended Validation SSL/TLS certificates to .PW domains.  Part of this change included the revocation of a small number of domain validated SSL/TLS certificates previously issued for these domains.  Additionally, we have engaged with the registry that controls .PW to identify ways that can improve the safety of this top level domain for consumers.  Several other country-code and generic top level domains are also special targets for attackers, which we will continue to evaluate on an on-going basis as well.

        In contrast, forward looking, security minded registries, such as fTLD Registry Services, the owner of the .bank and .insurance top level domains are raising the bar for security for all of its customers. Considered a best practice, before authorizing a domain sale, these registries ensure that only valid, qualified entities operate on these domains and thereby protect the reputation of these spaces. As the original Certification Authority and the market leader for website security solutions, Symantec believes that verifying identity is critical for establishing trust and for ensuring the security of both consumers and the organizations they connect with online.

        Symantec works with the general public to help identify fraudulent websites.  If you would like to report SSL/TLS misuse, please log it here

        • domains
        • DigiCert Code Signing
        • certificate
        • Products
        • TLS
        • website security solutions
        • issue
        • Symantec Website Security
        • .pw
        • SSL
        • revoke
        • Products and Solutions
        • Security
      • SSL; More than Encryption

        Mar 29 2018, 8:34 PM

        by Brook Chelmo 1

        While doing an online search for “SSL Certificates” and one of the ads said “$4.99, Why Pay More?”  Without clicking on the ad I know what they are going to offer me; a simple domain validated (DV) SSL certificate.  This certificate will encrypt my site’s traffic at a basic level but this isn’t 1997; the business climate and threat landscape have changed and so have our requirements for security.  SSL is more than encryption.  We have to consider trust, security, service, certificate management & reliability.  While many Certification Authorities are cutting corners to compete with each other on price, Symantec is working around the clock to continually deliver best-in-class solutions.  At Symantec we believe in these core factors as does 91% of the fortune 500 and 94 of the top 100 financial institutions in the world.  Here’s why:

        1. Increased End-Consumer Trust

        • Trust Seal -- Trust seals suggest that websites are safe to interact with.  The Norton Secured Seal has been shown through independent research to be the most recognized trust seal on the Internet.  Offered only by Symantec, it is seen about 4 billion times per month on websites all around the world.  The seal ensures visitors that they are communicating with organizations that not only encrypt their traffic but also are legitimate organizations that have gone through Symantec’s strong authentication screening as well.
        • Visual Cue -- The “Green Bar” also represent that a site is trustworthy.   With Symantec EV Certificates, browsers will change the color of the address bar to green, serving as a cue for safe interaction.  DV certificates won’t provide for a visual cue to website visitors

        2. Stronger Business Authentication and Website Security

        • Authentication -- With every Symantec certificate, Symantec performs strong authentication to ensure that a website visitor can trust who they are communicating with.  Security-minded organizations realize that encryption alone is not enough and require, as a matter of policy, that all certificates issued for their organization have strong authentication.  On the other hand, domain validated certificates, like those that Let’s Encrypt intends to offer, will only provide encryption of data.   Thus, they will not prevent a credit card number or password from going to an encrypted website that may be fraudulent.
        • Scanning and Alerts -- Symantec products also secure customer websites with scanning for critical vulnerabilities and active malware.  Symantec proactively notifies customers about security risks within a customer’s unique environment and provides guidance to ensure that such issues are quickly and easily resolved. 

        3. Simplified Certificate Management and Live Worldwide Support

        • Management Tools -- Symantec enables customers to track and manage large volumes of certificates with a wide range of tools.  Organizations are often burdened with the complexity of managing a variety of SSL certificates that may include of self-signed, client certificates or SSL certificates that chain up to public roots.
        • Accessible Technical Support -- Symantec provides 24/7/365 support worldwide to ensure that customers’ sites stay up and running and secure, with an optional premium support that include SLA’s on problem escalation and resolution.  This is a critical component for organizations that need to ensure that their website operations remain.  A free offering like Let’s Encrypt rarely comes with any form of live support.

        4. Powerful Technical Capabilities and Advanced Options

        • Client Ubiquity -- As the longest operating Certification Authority, Symantec’s roots are in more clients than any other Certification Authority.  Organizations that want to support Always on SSL and connectivity with the greatest number of users choose Symantec to secure their transactions.
        • Advanced Certificate Options -- Symantec Secure Site Pro products include both RSA 2048 bit certificates and ECC 256 bit certificates which are optimal within Perfect Forward Secrecy.  These high security, high performance certificates are the future of SSL/TLS encryption and Symantec’s ECC roots are in more clients than any other Certification Authority.
        • Best in Class Revocation -- Symantec provides revocation information to clients through both the Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRLs).  Both of these services are updated continually to communicate certificate revocation activity to clients worldwide.  The services are tuned to provide the fastest response times possible.   In the case of websites, OCSP response times can impact page load times and Symantec has invested in its infrastructure to provide OCSP responses in about 50 milliseconds for almost every major region in the world.  

        5. Reliable Security and Business  Assurances

        • Warranties -- Symantec offers the highest warranties of any Certification Authority.  These warranties can cover customers for losses of up to $1,750,000 from incorrect information contained on Symantec certificates.
        • Military-Grade Data Centers -- Symantec’s roots and signing services are protected by the most stringent physical, network, and logical security and process controls.   The hardened facilities provide our customers with confidence that certificate issuance for their domains will not be compromised.  With ten years of continuous uptime, Symantec’s robust continuity practices are the best in the industry.
        • Contractual Commitments -- Symantec customers have a contractual commitment from Symantec to maintain their products for the term of their contract.  Let’s Encrypt, as a non-profit, open-source Certification Authority, it will be difficult to offer such contractual guarantees, given the significant expenses associated with operating a publicly audited Certification Authority.
        • Focused investment – As the world’s largest security company, Symantec has both the resources and the motivation to ensure that the our SSL products are uncompromised.  Vulnerabilities like Heartbleed have clearly demonstrated that, despite the good intentions of OpenSSL, a non-profit organization with limited resources will be challenged to keep up with the rapidly-changing security threat landscape.

        Modern Security for Modern Needs

        Companies that know security understand they need to use modern-day security solutions in today’s environment and that SSL is more than just simple encryption.Please keep all of these factors in mind as you are building out your webserver security plans.For more information on Symantec SSL, please visit our website.

        • SSL Encryption
        • SSL certificate
        • DV cert
        • Go Daddy
        • certificate
        • symantec
        • Products
        • website security solutions
        • Norton Secured Seal
        • Symantec Website Security
        • SSL
        • DigiCert SSL TLS Certificates
        • Products and Solutions
      • How does SSL work? What is an SSL handshake?

        Sep 15 2014, 10:24 AM

        by Robert Lin 0

        A special request was made today: "How does SSL work? What is an SSL handshake?"

        Here are some quick info.

        SSL/TLS are protocols used for encrypting information between two points. It is usually between server and client, but there are times when server to server and client to client encryption are needed. For the purpose of this blog, I will focus only on the negotiation between server and client.

        For SSL/TLS negotiation to take place, the system administrator must prepare the minimum of 2 files: Private Key and Certificate. When requesting from a Certificate Authority such as Symantec Trust Services, an additional file must be created. This file is called Certificate Signing Request, generated from the Private Key. The process for generating the files are dependent on the software that will be using the files for encryption.

        For a list of the server softwares Symantec has, have a look at: Symantec CSR Generation

        Note that although certifcates requested from Certificate Authorities such as Symantec are inherently trusted by most clients, additional certificates called Intermediate Certificate Authority Certificates and Certificate Authority Root Certificates may need to be installed on the server. This is again server software dependent. There is usually no need to install the Intermediate and Root CA files on the client applications or browsers.

        Once the files are ready and correctly installed, just start the SSL/TLS negotiation by using the secured protocol.  On browser applications it is usually

        Remember to use your secured website address. Above is just a sample address.

        That will start the SSL/TLS negotiation:

        Keys and Secrets during RSA SSL negotiation

        The following is a standard SSL handshake when RSA key exchange algorithm is used:

        1. Client Hello
          - Information that the server needs to communicate with the client using SSL.
          - Including SSL version number, cipher settings, session-specific data.
        2. Server Hello
          - Information that the client needs to communicate with the server using SSL.
          - Including SSL version number, cipher settings, session-specific data.
          - Including Server’s Certificate (Public Key)
        3. Authentication and Pre-Master Secret
          - Client authenticates the server certificate. (e.g. Common Name / Date / Issuer)
          - Client (depending on the cipher) creates the pre-master secret for the session,
          - Encrypts with the server's public key and sends the encrypted pre-master secret to the server.
        4. Decryption and Master Secret
          - Server uses its private key to decrypt the pre-master secret,
          - Both Server and Client perform steps to generate the master secret with the agreed cipher.
        5. Generate Session Keys
          - Both the client and the server use the master secret to generate the session keys,  which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session
        6. Encryption with Session Key
          - Both client and server exchange messages to inform that future messages will be encrypted.

        (Wikipedia: Transport Layer Security)

        Tools such as OpenSSL can be used check the SSL/TLS negotiations:

        OpenSSL s_client -connect -state -ssl3
        Loading 'screen' into random state - done
        SSL_connect:before/connect initialization
        SSL_connect:SSLv3 write client hello A
        SSL_connect:SSLv3 read server hello A
        depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5

        SSL_connect:SSLv3 read server certificate A
        SSL_connect:SSLv3 read server done A
        SSL_connect:SSLv3 write client key exchange A
        SSL_connect:SSLv3 write change cipher spec A
        SSL_connect:SSLv3 write finished A
        SSL_connect:SSLv3 flush data
        SSL_connect:SSLv3 read finished A
        Certificate chain
         0 s:/ Organization/serialNumber=2158113/C=US/postalCode=94043/ST=California/L=Mountain View/street=350 Ellis Street/O=Symantec Corporation/OU=Corp Mktg & Comms - Online Exp/

        There it is. SSL and SSL Negotiation summarized. Mission complete.

        Now! Do Not Forget To Back Up Your Private Key and Certificate in a Secure place in case of system issues!

        • Public Key Infrastructure (PKI)
        • DigiCert Code Signing
        • certificate
        • Security Community Blog
        • Products
        • SSL Negotiation
        • TLS
        • Symantec Enterprise Security
        • Thought Leadership
        • Symantec Website Security
        • SSL
        • private key
        • #CSR
        • Trust Services
      • SSL Ciphers - Beyond Private key and Certificate

        Oct 20 2017, 8:35 PM

        by Robert Lin 2

        Today SSL is an integral part of online businesses and any secured communication. It is however not an area that many system administrators or security experts are comfortable with. For most administrators the correct installation of the private key and its corresponding certificate is sufficient. As long as the green bar, the padlock, or https:// can be seen during the SSL/TLS negotiation, both the administrators and their clients trust that the connectivity is secure.

        However many security flaws and vulnerabilities have been discovered in the recent years. From the server side there is the infamous Heartbleed bug or CCS injection - CVE-2014-0224, side-channel attacks such as Beast, Lucky 13, Crime or BREACH, and others (SSL Attack Survey).  It is not sufficient to just have a correct installation of the private key and certificate pair on the server. Beside patching up server libraries and client applications, additional control to SSL/TLS negotiations need to be applied. One of those control mechanisms is selecting the right cipher suite.

        The strength of an SSL/TLS negotiation depends not only the size of the private key or certificate. As of 2014, the recommended minimium key pair size is 2048 bit, however this does not guarantee maximum encryption sessions. During SSL/TLS handshakes, the agreement of what cipher suite to use determines if the negotiation will be using SSL or TLS protocols. It also determines the key exchange and encryption algorithms. If the agreed encryption level between the client and the server is low, the SSL/TLS session will still be vulnerable. For a system to be truly secure, strong cipher suites are required.

        To address this issue, a project was initiated. The result, "SSL/ TLS Cipher Suite Analysis and strong Cipher Enablement" is included in this blog.

        The purpose of this research is to provide an implementation process to set up a strongly secured SSL/TLS system by viewing the available cipher suites present in a system, recognizing the strength and weakness of the different ciphers and choosing the most applicable cipher suite.

        Note:  The configuration examples given in this document do not represent the complete or best set of strong ciphers to use. Depending on the various security policies and business requirements, the examples given in the document may not apply .

        • Products
        • Symantec Enterprise Security
        • Thought Leadership
        • ciphersecurity
        • Symantec Website Security
        • SSL
        • encryption
        • private key
        • DigiCert SSL TLS Certificates
        • certificate
        • cipher
        • Security Community Blog