• What is OCSP?

        Oct 20 2017, 8:29 PM

        by Ankit Shah 0

        The OCSP (Online Certificate Status Protocol) is one of the two ways for obtaining the revocation status of X.509 digital certificate (e.g. SSL & code-signing certificates) and hence maintains the security of a server or other network resource. The other older mechanism, which OCSP has superseded, is known as “CRL (Certificate Revocation List).”

        OCSP overcomes the chief limitation of CRL: the fact that updates must be frequently downloaded to keep the list current at the client end. When a user attempts to access a server, the OCSP sends a request for certificate status information. The server sends back a response of "Success", “Unauthorized”, "Malformed Request” or "Try Later". The protocol specifies the syntax for communication between the server (which contains the certificate status) and the client application (which is informed of that status. OCSP responses contain less information than a CRL so it puts less burden on the network and the calling resources.

        An OCSP request is a signed message.  It consists mainly of two components: a request body, and an optional signature block.  The request body contains one or multiple certificate status requests.  The body consists of the following fields:
        Version – OCSP Request version number.  It is default to v1.
        Requestor name – optional field
        One or more requests – web server only include one certificate status request per OCSP request message.
        Extensions – This optional field to include extra information which may be communicated between the client and the OCSP server, such as the expected OCSP response message type from the client, nonce, or archive cutoff date, etc. 
        Of all these components, the most important component is the certificate status request structure.  It consists of the following:
        HashAlgorithm – this field specifies the digest algorithm, which is used to digest the CA, subject DN or CA key.
        IssuerNameHash – digest of the EE’s CA subject DN
        IssuerKeyHash – digest of the EE’s CA public key or a unique key identifier
        SerialNumber – EE certificate serial number
        The combination of the SerialNumber and the IssuerNameHash or the SerialNumber and the IssuerKeyHash uniquely identifier the EE certificate signed by the CA.

        How did Symantec improve OCSP Performance?

        Origin Server:  Symantec built a highly efficient and responsive OCSP infrastructure.

        CDN: Symantec worked with a CDN to make their EdgeServer OCSP aware and able to read the ASN.1 request and response package.

        • Handle the OCSP traffic intelligently:
          • Use the nextUpdate timestamp to determine the expiration time in cache
          • Use the CertID sequence from the OCSP Request to determine the cache key.  Specifically issueNameHash + issueKeyHash + serialNumber.
          • Check for the presence of the nonce extension (id-pkix-ocsp-nonce) and handle appropriately.
          • Provide the ability to invalidate the CDN cache based on the OCSP URI and OCSP Key for revoke case.
          • Provide reporting on overall traffic and request plus the top 50 requested URIs.
          • Provide the ability to limit the size of the edge for ACLs.
          • Provide the ability to handle OCSP requests without HTTP Host headers.

        If the response for a requested cert is found in CDN cache, it'll be returned from the cache.

        If a response can't be found in cache, a request will be sent to origin server (Symantec OCSP responder) to retrieve the response and stored in cache for later lookup.

        Symantec built an OCSP responder to handle any cache miss requests.

        What is the Net Result?

        The result of our work is that we have become the fastest within the industry. When one adds together the average speeds of our competitors you can see how fast Symantec really is.  The other thing to note is not only is there a massive difference in speed but also a difference in regularity.  Certain days will have more or less demand on the OCSP infrastructure than others, but ultimately, Symantec’s speed is far more consistent that the wild ups and downs of other CAs trying to keep pace with the demands of a modern internet.


        Do you want to go faster?

        If speed is important to your organization then why not consider using ECC SSL certificates?  The majority of SSL certificates used today are based on RSA, an aging algorithm.  ECC is the next generation; it uses tighter math and therefore runs more efficiently than RSA.  This allows a server to run more sessions with one company reporting a 46% drop in CPU utilization and a 7% improvement in server response times.  

        Please let us know what you think or if you have any questions.  You can reach out on Twitter or follow us on Facebook.

        • OCSP
        • Products
        • website security solutions
        • DigiCert Complete Website Security
        • Products and Solutions
        • Symantec Website Security
      • Superfish

        Feb 24 2015, 11:26 PM

        by Unknown 3

        A security flaw was discovered in software that was pre-installed on some Lenovo laptops. Lenovo has issued the following Press Release.  The story has been reported on multiple sites (for example, here and here). We applaud Lenovo for quickly publishing details on affected models and instructions for removing the flaw. The problem lies in the software from a company called Superfish that was pre-installed by Lenovo on certain computers. The main function of the software was to intervene when the user performed web searches in IE or Chrome browsers, and insert Superfish’s content into the search result page. Lenovo enabled this software to “help users find and discover products visually”, by incorporating relevant search results not offered by the search engine.

        Interjecting content in web pages is not new (for example, via browser add-ons), but Superfish’s approach was novel, and didn’t use a browser add-on. Instead, the software intercepted all traffic between the browser and the network external to the computer. But since most large search engines (such as, Google, Bing, and Yahoo) now serve all content over https, the Superfish software couldn’t read (and more importantly, modify) any of that encrypted traffic. To get around this, an SSL Man-in-the-Middle (MITM) was set up in the computer itself, creating fake SSL certificates with the domain name of the intended web site. These certificates were signed by or chained up to Superfish’s private root certificate. Ordinarily, browsers would display a prominent warning that such a certificate wasn’t trusted, so that was addressed that by injecting Superfish’s root certificate into the Windows trusted root store during manufacture. To make all this work, of course, the private key corresponding to that root certificate had to be pre-installed on all of these computers. Superfish took steps to encrypt that private key, but the encryption was trivial and quickly broken.

        The result is that attackers now have the private key corresponding to a root certificate that is trusted in these Lenovo computers, and that can be abused in too many ways to describe here.

        In some ways, this is similar to the recent incident with Gogo inflight wifi service. Both make use of an SSL MITM technique to insert themselves into the otherwise secure connection between a browser user and the websites they visit. See our recent blog post to learn how SSL MITM attacks work. In Gogo’s case, the MITM (the actor generating certificates on the fly) was in Gogo’s network; in Superfish’s case, the MITM is in the computer itself.

        As we’ve said before, SSL Man-in-the-Middle solutions can be justified within an enterprise, for example, to monitor employees’ web traffic. But the well-intentioned inclusion of Superfish had unintended consequences far beyond web searching, and created a potential for malicious MITM attacks. Pre-installing any root that does not belong to an audited Certificate Authority and marking it as trusted undermines the trust model created and maintained by platform vendors, browser vendors, and Certificate Authorities. Platform and browser vendors go to great lengths to validate the Certificate Authorities whose roots they include in their trusted root store. Microsoft provided the ability for an enterprise to add additional roots to the Windows trusted root store, and Google Chrome explicitly avoids performing public-key pinning checks for such added roots. As a result, Chrome users receive no warning of the MITM, as they did in the Gogo incident.

        If you think you may have an affected Lenovo computer, visit this web site to check. Uninstalling the Superfish software isn’t enough to remove the vulnerability – you must also remove the Superfish root from the Windows trust store. The instructions provided by Lenovo achieve both objectives.

        • Products
        • website security solutions
        • Symantec Website Security
        • DigiCert Code Signing
        • vulnerability
        • Products and Solutions
        • adware
        • Security
      • Website Security made simple

        Feb 19 2015, 3:20 PM

        by Melanie Pracht 2

        Website security is important for every business that has an online presence. Whether you’re in ecommerce or electricals, holiday cottages or hedge funds, your website is one of your most important business assets. It’s your 24/7 shop front, and you need to make sure it’s secure and working at its best.

        You wouldn’t leave your laptop behind when you leave a coffee shop, or your stockroom door wide open, so why would you take chances with website security?

        If your site triggers a security warning in the web browser of the visiting user or worse, it infects a customer’s computer, that customer is going to tell all their friends and colleagues and thanks to social media perhaps even the wider world. Ouch!

        And it’s not just your reputation that you have to worry about. If you have an ecommerce site, warnings and poor security will mean abandoned carts and lost customers. In a recent Symantec, online consumer study, 56 per cent of respondents go to a competitor’s website to complete their purchase and only 11 per cent go back to the first website after seeing a security warning (Symantec Online Consumer Study, March 2011).

        But website security can be a daunting topic, full of jargon and unfathomable workings. To get to grips with the why and what of website security, Symantec created an easy to read ‘How-To Guide’ for everyone who wants to learn more about website security in the world famous ‘For Dummies’ style. 


        Download the eBook here!

        “Website Security For Dummies” is your guide to understanding the risks posed by unprotected websites, the value of using SSL certificates and the what-and-how of different types of SSL certificates. You will learn how to:

        • Make the business case for website security
        • Understand the basics of SSL certificates
        • Choose and implement the right SSL certificate for your website
        • Follow best practice for maintaining a healthy and trusted website
        • Find useful sources for information on website security

        So relax, Symantec got you covered; soon you too will be an expert on website security.

        • Products
        • Malware Scan
        • Symantec Enterprise Security
        • Thought Leadership
        • Vulnerability Assessment
        • Symantec Website Security
        • DigiCert Code Signing
        • Security Community Blog
      • 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
      • The Transition from Non-FQDN Server Names

        Oct 20 2017, 9:13 PM

        by Dom SYMC 2

        The CA/Browser Forum is an unincorporated association of separate organizations that creates the guidelines that apply to all SSL certificate and browser providers. Since the effected date of 1 July 2012 Symantec has been notifying customers in regards to certificates with a SAN or Common Name (CN) field that contains a Reserved IP Address or Internal Server Name since they are being phased out due to CA/Browser Forum standards.

        This one particular standard has some customers in a bind when renewing or enrolling into a CA signed SSL certificate. Below is the Standard.

        abc123-local 400X.jpg

        9.2.1Subject Alternative Name Extension

        Certificate Field: extensions:subjectAltName

        Required/Optional: Required

        Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate.

        Wildcard FQDNs are permitted.

        As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP

        Address or Internal Name.

        (More information about the CA/B Forum Baseline Requirements can be found at

        This standard means SSL certificates can only be issued to Fully Qualified Domain Names (FQDN) and can no longer be issued to Non-Valid internal names.


        Valid FQDN’s

        Non-Valid Internal



        In response to this change customers have to take two main course of action:

        1. Change the common names and reissue their SSL certificates
        2. Move to certificates chained to a private root with two options:
          1. Develop a self-signed internal Certification Authority (CA)
          2. Use a Private CA from Symantec

        To help our customers avoid the dangers of a self-signed CA, Symantec is now offering the Private CA.

        private_CA_graphic 600X.jpg

        The Symantec Private CA ensures:

        • Compliance
        • Support
        • Reduces the time
        • Reduce hidden costs of in house solutions.

        This is offered though the Managed PKI for SSL Account. Use the same console to managed external as well as internal certificates.  Ask your account manager for more details! More detailed Information on the Symantec Private CA can be found at

        • Products
        • website security solutions
        • DigiCert Complete Website Security
        • Products and Solutions
        • Symantec Website Security
      • Information protection everywhere begins with Symantec Identity: Access Manager (SAM)

        Feb 02 2015, 8:44 AM

        by Teresa Law 0

        So information protection everywhere begins with Symantec Identity: Access Manager (SAM)?  But what is information protection everywhere?

        • It’s prevention - scanning on-premise and in cloud apps to find sensitive files that should be secured
        • It’s user friendly protection – securing identities and access with simple, smart, and secure strong authentication; and protecting data in the enterprise or the cloud, at rest and in transit
        • It’s fast detection and rapid remediation – quickly identifying suspicious or risky behavior and automating responses
        • It’s about standards so integration with vendors' products is easy
        • And it begins with SAM

        Access Manager (SAM) is the platform on which Symantec’s information protection solution will be built.  A comprehensive information protection solution that not only includes identity and access protection, but also information management, and a way to intelligently correlate unusual behavior or events identified by both.  Access Manager acts as the single access point for all cloud apps and services to ensure secure access and data integrity; similar to a Control Access Security Broker (CASB) or Cloud Access Control. 

        But why does Symantec’s information protection start with Access Manager? The single access point provided by Access Manager is necessary, not just to help ensure that legitimate users are the only ones to gain access to sensitive corporate data, but also to identify users if there is a need to take action - enabling rapid response.  Identity provides the best means to correlate disparate events and Access Manager provides the unified identity.

        The introduction of Access Manager is just the beginning of information protection everywhere. Read more about Access Manager or visit the Access Manager website

        • 2FA
        • Products
        • Identity Access Manager
        • #SSO
        • Single Sign-on
        • Identity and Authentication Services
        • Access Control
        • VIP (Validation ID Protection)
        • Products and Solutions
        • Managed PKI for SSL