Blogs

    Publish
     
      • Certificate Authority Authorization Checking: What is it, and why should you care?

        Aug 30 2017, 6:12 PM

        by Lee-Lin Thye 0

        Certificate Authority Authorization checking: what is it, and why should you care?

        The Public Key Infrastructure (PKI) ecosystem relies on root certificates issued by various certification authorities (CAs) like Symantec. This is what browsers use to decide which websites can be trusted, and which ones are not trusted.

        Up to now, any CA can issue a TLS certificate for any domain. That’s how the system works, and it’s good in the sense that it gives website owners and operators options to change CAs at their discretion. The downside to this is that certificate issuance can happen without the knowledge of website operators, either by mistake or intentionally by malicious actors.

        A number of technologies have been created in an attempt to highlight instances of “unknown” issuance, such as Certificate Transparency. These have been effective in making the internet a safer, more trustworthy place but they are reactionary measures – only .allowing website operators to address the issue after it’s happened.

        But is it possible to prevent certificates from being mistakenly or inappropriately issued? Yes. Enter: Certification Authority Authorization (CAA).

        CAA prevents unknown certificate issuance by:

        1.Allowing domain owners to specify which CAs are authorized to issue certificates for their domains; and

        2.Giving CAs the ability to check this authorization before issuing a certificate.

        In this article, we’ll explain how CAA works, and why making CAA checking mandatory is a good move for both customers and CAs.

        What is Certification Authority Authorization?

        A Certification Authority Authorization (CAA) record is a DNS Resource Record which allows a domain owner to specify which CAs are authorized to issue certificates for their domain(s) and, by implication, which aren’t.

        The idea is that a CA will check the CAA record(s) for a domain before issuing a certificate. If it finds that a domain has no CAA record, then it’s free to issue a certificate for it if all other authentication checks succeed. However, if it does encounter one or more CAA records, then the CA can only issue a certificate if it’s named in one of the records, indicating that it is authorized to issue a certificate for that domain. The whole process is designed to prevent CAs from unauthorized certificate issuance requests by unauthorized parties or bad actors.

        Sounds great. Why isn’t everyone doing this?

        Symantec has been checking CAA records for years, but it’s not a common practice. There are two reasons why CAA checking isn’t widely practiced:

        1.Many domains don’t have a CAA Resource Record; and

        2.Checking CAA records is not mandatory.

        Because it may take some work to create a CAA record, it’s a matter of customers or website operators consciously opting-in, not opting-out. Many domain owners use a DNS hosting provider and CAA is not yet supported in some DNS implementations.

        This is why CAA records are expected to be used by most high-value domains. These enterprises keep CAA records for their domains because they limit inappropriate (or malicious) certificate requests, and makes it easier to enforce company policies i.e. only using a particular set of CAs.

        The limitations of CAA checking

        Of course, CAA checking has its limitations.

        First, a newly-issued CAA record does not invalidate any previously-issued certificates that may have been issued by a different CA than the one named by the domain owner. Second, it doesn’t flag whether a certificate presented by a web server is a legitimate certificate for that domain.

        Furthermore, in order for CAA checking to be effective, all CAs need to be doing it; it doesn’t work if only one or two CAs are checking CAA records as matter of process. CAA checking must be widely adopted if it is to serve its purpose, but the good news is that more than ninety percent of CAs (who are members of the CA/Browser Forum) are in favor of it.

        The times are changing: CAA checking will become mandatory

        In February 2017, the CA/Browser Forum passed a ballot (on which Symantec voted in favor) requiring all CAs (even those who aren’t a member of the Forum) to check for a CAA record as part of the certificate issuance process for each domain. In accordance with RFC 6844, CAs can no longer issue a certificate for a domain unless:

        1.The CA does not find any CAA records for the domain

        2.The certificate request is consistent with the applicable CAA Resource Record(s)

        The rule is effective as of 8 September 2017. You can read the ballot in full here.

        A good outcome for all companies

        Mandatory CAA record checking requires CAs to abide by the rules set out in specific CAA records, giving domain owners more control over certificate issuance. This makes it easier for companies (especially larger ones) to enforce a certificate issuance policy across business units. With CAA records applicable to every domain, a company can specify a set number of CAs, knowing no other CA can issue a certificate to its domains.  This will help reduce the risks of certificate issuance by unauthorized CAs and help create a more secure and transparent online ecosystem.

        For more information on CAA with Symantec Certificates go to Symantec Knowledge Center

        • Products
        • Certificate Authority
        • TLS
        • Thought Leadership
        • CA
        • Symantec Website Security
        • SSL
        • DigiCert Code Signing
        • certificates
      • 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
      • Chrome 53 Bug Affecting Symantec SSL/TLS Certificates

        Oct 20 2017, 8:48 PM

        by Unknown 1

        We’ve been made aware of a bug in Chrome version 53 that affects some Symantec, GeoTrust, and Thawte SSL/TLS certificates resulting in an error display when visiting affected websites.  There are no issues with the affected certificates and websites, and replacing these certificates will not help. Symantec is a strong supporter of Google Chrome and its Certificate Transparency (CT) policies. This is entirely a bug with Certificate Transparency handling that is only present in Chrome 53.  

        The recommended solution is to upgrade to Chrome 54 while Google is working on a patch to resolve this issue. Other browsers (i.e., Safari, Microsoft IE, Edge, Firefox, etc.) are unaffected by this bug.

        This blog has been updated here.

        • Products
        • TLS certificate
        • SSL
        • CT
        • chrome
        • DigiCert SSL TLS Certificates
        • Products and Solutions
      • 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
      • Microsoft’s launch of Certificate Reputation

        Apr 17 2015, 9:51 PM

        by Dean Coclin 0

        A few weeks ago, Microsoft launched a new addition to their Bing Webmaster Tools which allows website operators to monitor their web domains to help insure there are no improperly issued SSL certificates.

        This is a great benefit to those owners because:

        1. It’s easy to use and Microsoft monitors this for free

        2. The Certificate Authorities do not need to do anything special. Certificates are automatically monitored by Microsoft

        3. It’s integrated into the Bing Webmaster toolset. There is no need to sign up separately for the service

        4. It works for all types of SSL certificates, not just EV

        However, there are a few limitations today:

        1. This is currently a “preview” and only collects data from users on Windows 10 which itself is currently only in a preview release. Hence the data is limited. However, this will improve with the formal release of Windows 10.

        2. The data that Microsoft is gathering is not made public which prevents the public at large from also seeing the certificates. However, the need being addressed is that of website owners.

        More details are in this Microsoft blog.

        Trust continues to be enhanced in the Browser/Certificate Authority ecosystem (as discussed in this prior blog) and Certificate Reputation is another tool (along with Certificate Authority Authorization-CAA, Certificate Transparency-CT, and Public Key Pinning) along this path.

        • Products
        • Symantec Enterprise Security
        • Thought Leadership
        • Symantec Website Security
        • SSL
        • Identity and Authentication Services
        • DigiCert Code Signing
        • certificates
        • Security Community Blog
      • DV SSL Certificates and Ecommerce don't mix

        Mar 29 2018, 10:31 PM

        by Dean Coclin 0

        Symantec’s just released Internet Security Threat Report shows that cybercriminals have been busier than ever. And social engineered attacks are one vector that continue to see growth due to the likelihood of success. Although the attacks come in different forms, one approach fools unsuspecting users to click a link which takes them to a “look-a-like” website. That imitation site is typically a highly-phished domain, (i.e. Apple ID or a popular bank or credit card site). But now, to prove their legitimacy, phishers obtain Domain Validated (DV) SSL certificates because they know that consumers have been trained to look for the padlock or “https” in the browser URL window. The appearance of this lock further legitimizes the attack and tricks consumers into disclosing their credentials or banking/credit card details.

        There are three types of SSL certificates, each requiring a different level of authentication: DV, OV and EV. Understanding the differences among each SSL certificate type is important to help prevent falling victim to scammers. For example, DV certificates are quick and easy to procure and don’t require any type of information indicating the person trying to get the DV certificate actually represents a legitimate business. Fraudsters often use DV certificates to lure consumers to phishing websites that look authentic but are designed to steal sensitive information. For this reason, doing any type of ecommerce transaction on a DV-only site poses risk. While there are appropriate use cases for DV certificates, it’s important to know how cybercriminals are taking advantage of DV certificates to conduct phishing scams and how to protect against these types of cybercriminal attacks.

        Online shopping isn’t going away. Until the industry requires an OV or EV certificate for e-commerce sites or an easier way to identify the types of certificates, consumers will have to bear some of the burden of combatting cyber risks. Knowing the risks ahead of time, however, is half the battle. 

        • Products
        • Public Key Infrastructure (PKI)
        • Symantec Enterprise Security
        • Thought Leadership
        • SSL
        • Identity and Authentication Services
        • DigiCert SSL TLS Certificates
        • Security Community Blog
      • Enhancing Trust in the CA/Browser System

        Apr 13 2015, 5:40 PM

        by Dean Coclin 0

        Stop Hand.jpg

        Browsers and Certificate Authorities are in the news again over the reported mis-issuance of an SSL server certificate to google.com domains. Discovered by Google most likely via technology known as key pinning and discussed by Google’s Adam Langley in this blog, a Chinese certificate authority, CNNIC (Chinese Internet Network Information Center), apparently issued an intermediate certificate to an Egyptian company called MCS Holdings. Because the CNNIC root certificate is included in the root store of most major browsers, users would not see any warnings on sites that have certificates issued by CNNIC or MCS Holdings. When MCS installed their intermediate into a Man in the Middle (MITM) proxy device, that device could then issue certificates for sites which users connected via that proxy would visit.

        There are several violations of the CA/B Forum Baseline Requirements and Mozilla Root Program Requirements here. First, Mozilla specifically prohibits using public roots for MITM applications. (While there may be legitimate corporate use cases for these proxy devices, using public root certificates as part of the implementation is prohibited and is a violation of public trust). Second, any sub CA certificates (issued from the Root) must be publicly disclosed and audited or be technically constrained(using the technology known as “name constraints” which limits the domains which the CA can issue to. Neither appears to be the case here. Third, indications are that the key was not generated and stored in a proper Hardware Security Module (HSM). There are several other mistakes as well but these are the major ones.

        CNNIC documents show that the sub CA certificate was only issued for a short duration and was to be used for test purposes only. While this may be the case, it ignores the reality that the misuse of such a certificate can cause great harm to end users. Users can be deceived to go to a fraudulent website and have their credentials stolen. The fact that bogus certificates found their way onto the public Internet due to this “test” makes it clear that improper controls were in place at both CNNIC and MCS Holdings as well as a limited understanding of the rules surrounding public CAs.

        The major browsers quickly moved to un-trust the MCS Holdings certificate to protect their users from potential fraud. MCS sent a report to Mozilla with their assessment of the situation. Google has announced that they are taking action to distrust the CNNIC root certificates.  Google will “whitelist” all existing CNNIC certificates and has provided a path for re-inclusion into their browser by insisting all future certificates use Certificate Transparency.  Firefox will be updated to distrust any CNNIC certificate with a notBefore date of April 1, 2015. The current CNNIC root will remain in the Mozilla root store to validate current certificates and CNNIC can reapply for full inclusion but may be subject to additional scrutiny and controls during the process. This is essentially a punishment for violating the Baseline Requirements and the Mozilla root program rules.  Microsoft is still evaluating whether to take further action than just distrusting the MCS Holdings Intermediate certificate. No word from Apple so far.

        Three recently introduced technologies and controls namely Certificate Authority Authorization (CAA) and Certificate Key Pinning (HPKP), which are designed to prevent mis-issuance, and Certificate Transparency (CT) which is designed to detect mis-issuance, significantly raise the level of security of the CA/Browser cryptography system. CT and HPKP are being implemented by some browsers and CAA is a function that CAs will have to deploy.

        What is the lesson learned here? Not all CAs are created equal. Clearly CNNIC broke the rules and got caught. Whether it was intentional or not is being debated in the public. It doesn’t appear from the evidence that this was intentionally malicious. Symantec and all the SSL issuing CAs are held to high standards with regard to the ecosystem rules including CA/B Forum Baseline Requirements, Network Security controls, and Mozilla, Microsoft, Google, Apple and other root program requirements. We have strict controls in place to insure sub CA certificates are either disclosed or constrained, have strong and knowledgeable vetting and authorization teams, obtain regular audits from accredited WebTrust auditors and work closely with the major browser vendors in the CA/B Forum. While we do issue sub CA certificates to third parties, we are well aware of the strict rules surrounding this practice and the need to remain vigilant. Symantec supports the use of CT, CAA, and HPKP technologies and urges adoption by all participants in the ecosystem.  In the end, it matters which CA you choose so pick one that has a long track record and invests in its infrastructure to insure its customers are protected.

        • Products
        • Public Key Infrastructure (PKI)
        • Symantec Enterprise Security
        • Thought Leadership
        • SSL
        • Identity and Authentication Services
        • Security Community Blog
        • Managed PKI for SSL
      • The New 39-Month SSL Certificate Maximum Validity

        Oct 20 2017, 8:42 PM

        by Brook Chelmo 1

        The past few years within the SSL certificate industry have been busy with changes.  1024-bit RSA certificates are long gone, using public SSL certificates on servers with internal domain names is starting to disappear, and the SHA-1 hash algorithm is starting to see its final days.  So what is next?

        Starting 1 April 2015, Certification Authorities (CAs) are not permitted to issue SSL certificates (issued from a public root) with a validity period greater than 39 months.  SSL certificates have limited validity periods so that the certificate’s holder identity information is re-authenticated more frequently. Plus it’s a best practice to limit the amount of time that any key is used, to allow less time to attack it.

        In line with the latest Certification Authority/Browser Forum Baseline Requirements, CAs will stop issuing 4 and 5-year SSL certificates in the near future.  Symantec plans on eliminating these options in late February 2015 on all SSL management consoles.  Extended Validation (EV) SSL certificates still have a max validity period of 27 months but Organizational Validated (OV) and Domain Validated (DV) certificates (DV not offered by Symantec) will have this new 39-month lifespan.

        So how will this affect those who install SSL certificates?  The average person installing certificates in a large enterprise will have to go through the enrollment process a little more often.  If the organization on that level and scale finds this detracts from employee productivity they may want to look at leveraging Symantec Certificate Intelligence Center Automation.  To someone in a small organization who only issues SSL certificates on a very infrequent basis, they may find themselves looking for SSL installation instructions a little more often.  To help you, Symantec has always offered a wealth of information online via our Knowledge Base (the preceding site will be migrating to this location in the near future) and offers amazing support by phone.

        Hourglass 350x350.jpg

        Please let us know what you think below in the comment section.

        • CA BF
        • SSL certificate
        • DigiCert Code Signing
        • Validity
        • Products
        • website security solutions
        • 39-month
        • Symantec Website Security
        • SSL
        • SSL Cert
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • Certification Authority Browser Forum
      • Gogo Inflight Internet is Intentionally Issuing Fake SSL Certificates

        Oct 20 2017, 8:53 PM

        by Unknown 7

        It was recently disclosed that Gogo, a provider of Wi-Fi Internet services on commercial aircraft, has been issuing spoofed SSL certificates for Google sites that were viewed by customers of Gogo’s service. It appears that Gogo Inflight Internet was acting as an SSL Man-in-the-middle (MITM), a technique used within some enterprises to allow themselves to inspect and control all web traffic, even traffic to secure web sites.  To understand what this means, let me explain MITM in a bit more detail.

        While not very common, there are enterprises that use SSL MITM technology to protect their employees and assets. For example, the enterprise can see when their employees visit sites that attempt to deliver malware to eventually block it. Some enterprises might want to ensure that their employees don’t visit inappropriate web sites using company equipment. The enterprise may also deploy a Data Loss Prevention (DLP) solution to guard against company secrets being divulged on public web sites. These uses are justified since the enterprise has an interest in securing its employees and their assets (laptops, desktops, corporate data, etc.)

        yellow-puzzle-piece.jpg

        Here’s how an SSL MITM works: a browser user tries to open an SSL connection to a web server. The connection attempt is intercepted by the SSL MITM, which opens its own SSL connection to the intended web server. When that web server returns its SSL certificate, the SSL MITM crafts a copy of the certificate using its own public-private key pair and signed by the SSL MITM’s private root certificate. It returns that copy of the certificate to the browser user, who sees a certificate containing the name of the intended web server. Essentially, two SSL connections are set up: one between the browser user and the SSL MITM, the other between the SSL MITM and the web server. The SSL MITM copies traffic back and forth between the parties so they are generally unaware of the SSL MITM. All SSL traffic is encrypted on the wire, but unencrypted in the SSL MITM. This allows the SSL MITM to see everything and even modify traffic in either direction.

        It’s surprising to see a company use an SSL MITM with its customers. When used within an enterprise, the root certificate used by the SSL MITM can be installed and trusted in employee computers because the enterprise has complete control over those devices.  But this can’t be done with the enterprise’s customers, who control their own devices.  As a result, these customers will receive a warning when they visit a secure site intercepted by an SSL MITM. It’s clear from the screen shot in the articles related to this issue that the user’s browser warned them that the site’s certificate was signed by an untrusted issuer.

        What’s not clear is if Gogo performed a man-in-the-middle interception only for YouTube, or only for Google web properties, or for all web properties secured by SSL. There’s no reason to expect that Gogo intercepted only YouTube traffic. If done for all SSL traffic, it’s likely that a Gogo customer visiting their bank online, for example, would be subject to the same SSL MITM. This would be worrisome, because Gogo would then be able to collect usernames and passwords used on all such sites. Gogo’s CTO said “Gogo takes our customer’s privacy very seriously”, but Gogo’s actions raise a red flag. They could possibly have access to customer data that has nothing to do with Gogo or its services, and Internet users in a post-Snowden era are less willing to trust third parties with their personal information.

        Gogo has a legitimate interest in limiting or blocking video streaming, but the way they’ve done it is far overreaching. Perhaps they hoped that customers would avoid using YouTube when they saw a scary security warning. Sadly, an unintended side effect might be to train users to ignore and to click through those warnings, which is counterproductive to the industry’s push for better end-user practices. Ultimately this would devalue all legitimate SSL certificates, and weaken the Certificate Authority/Browser trust model that Certificate Authorities and browser vendors have built and strengthened over the past 15+ years.

        We urge Gogo to reconsider their actions and deploy bandwidth limiting solutions that do not involve the use of spoofed SSL certificates.

        • Products
        • website security solutions
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • SSL
      • 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.
          ssl-encryption-blog-1.jpg
        • 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
          ssl-encryption-blog-2.jpg

        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.
          ssl-encryption-blog-3.png
        • 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.  
          ssl-encryption-blog-4.jpg

        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.
          ssl-encryption-blog-5.jpg
        • 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
      2 pages