Verisign Root Certificates

VeriSign Universal Root Certification Authority: VeriSign Universal Root Certification Authority: RSA: 2048 bits: SHA-256: 40 1A C4 64 21 B3 13 21 03 0E BB E4 12 1A C5 1D: 23:59:59 Dec 1, 2037: 2.16.840.1.113733.1.7.23.6: 23 99 56 11 27 A5 71 25 DE 8C EF EA 61 0D DF 2F A0 78 B5 C8 06 7F 4E 82 82 90 BF B8 60 E8 4B 3C: Visa eCommerce Root: Visa. Install the missing root certificates in the physical Third-Party Trusted Root Certification Authorities store. Specifically, AAA Certificate Services, AddTrust External CA Root, GlobalSign, GlobalSign Root CA, Microsoft Code Verification Root, USERTrust RSA Certification Authority, UTN-USERFirst-Object, Verisign Class 3 Public Primary. Certificates that are signed by a CA (Certificate Authority) such as Verisign or Thawte; When an SSL-enabled Virtual Service is configured on the LoadMaster, a self-signed certificate is installed automatically. Generally, self-signed certificates should not be used for public-facing production websites. SSL certificates use a chain of trust, where each certificate is signed (trusted) by a higher, more credible certificate. At the top of the chain of trust are the root certificates, owned by Verisign and others. These certificates are typically shipped with your operating system or web browser. In Internet Explorer and Firefox. Verisign enables the security, stability and resiliency of key internet infrastructure and services, including the.com and.net domains. The domains that define the internet are Powered by Verisign. Verisign is a global provider of domain name registry services and internet infrastructure - Verisign.

To fix this issue, update the root certificates on the computer. If the computer has internet access, launch Windows Update. The download and installation of the updated root certificates occurs automatically in the background. You do not need to take additional action.

If the computer does not have internet access, use the process below to download then install the necessary files. Both certificates are required to properly validate the Symantec Endpoint Protection binaries.

Note: As of 12.1.5, if the required certificates are missing, Symantec Endpoint Protection installs the certificates during installation instead of prompting you to install them.

The Windows interface for adding certificates may look slightly different depending on your version of Windows. Symantec Technical Support does not officially support this process; these instructions are provided for your convenience.

Process to update the necessary root certificates

I. Download the necessary certificates.
II. Add the Certificate snap-in, if needed.
III. Install the Symantec Class 3 Public Primary Certification Authority - G5 certificate.
IV. Install the Symantec Class 3 Code Signing 2010 CA certificate.

I. To download the necessary root certificates

1. Download roots.zip:
   http://www.symantec.com/content/en/us/enterprise/verisign/roots/roots.zip
2. Extract all files from roots.zip file into an empty folder.
3. Download the intermediate code signing certificate:
   https://knowledge.digicert.com/content/dam/digicertknowledgebase/library/VERISIGN/ALL_OTHER/Certificates/Code2010/VeriSign_Class_3_Code_Signing_2010_CA.cer
   Please review DigiCert KB for more information about installation and support: https://knowledge.digicert.com/solution/SO19140.html
4. Using an internal network connection, or physical media such as a thumb drive, bring these files to the computer on which you need to update the root certificates.
   

II. To add the Certificate snap-in

1. Click Start > Run and then enter MMC.
   The Microsoft Windows Management Console opens.
2. Under Console Root, check for Certificates (Local Computer).
   Note: If this snap-in is already present, skip to III.
3. Click File > Add/Remove Snap-in. Under Available snap-ins, click Certificates, and then click Add.
4. In the Certificates snap-in dialogue, click Computer account, and then click Next.
5. Ensure that Local computer is selected, and then click Finish.
   

III. To install the Symantec Class 3 Public Primary Certification Authority - G5 certificate

1. While in the Microsoft Windows Management Console, click to expand Certificates (Local Computer), and then expand Trusted Root Certification Authorities.
2. Right-click Certificates, and then click All Tasks > Import.
3. In the Certificate Import Wizard dialogue, click Next.
4. Click Browse to navigate to VeriSign Class 3 Public Primary Certification Authority – G5.cer. Double-click this file, and then click Next.
   You can find this certificate in the extracted roots.zip file in the folder VeriSign Root CertificatesGeneration 5 (G5) PCA.
5. For Certificate Store, ensure you place the certificate into Trusted Root Certification Authorities, and then click Next.
6. Review the settings, and then click Finish.

The Certificate Import Wizard should report success.

IV. To install the Symantec Class 3 Code Signing 2010 CA certificate

1. While in the Microsoft Windows Management Console, click to expand Intermediate Certification Authorities.
2. Right-click Certificates, and then click All Tasks > Import.
3. Click Browse to navigate to VeriSign_Class_3_Code_Signing_2010_CA.cer. Double-click this file, and then click Next.
4. For Certificate Store, ensure you are placing the certificate into Intermediate Certification Authorities, and then click Next.
5. Review the settings, and then click Finish.

The Certificate Import Wizard should report success.

It may also be necessary to delete one or more Symantec/Verisign certificates in the 'Untrusted Certificates' folder that display the following error upon review of the actual root certificate 'This certificate has been revoked by its certification authority' before following the steps above. When you discover that one of the certificates shows up as 'revoked' even though Symantec/Versign did not revoke the certificates, it typically means that the certificate was either moved or copied to the 'Untrusted Certificates' store on the local machine.

A digital certificate binds a user, computer, or service’s identity to a public key by providing information about the subject of the certificate, the validity of the certificate, and applications and services that can use the certificate. Certificates issued in PKIs are structured to meet these objectives based on standards established by the Public-Key Infrastructure (X.509) Working Group (PKIX) of the Internet Engineering Tasks Force (IETF).

What is inside a Digital Certificate?

The following figure shows the contents of X.509 version 3 certificatesX.509 Version 3 certificates support the following fields that have been supported since X.509 version 1:

• Subject: Provides the name of the computer, user, network device, or service that the CA issues the certificate to. The subject name is commonly represented by using an X.500 or Lightweight Directory Access Protocol (LDAP) format.
• Serial Number: Provides a unique identifier for each certificate that a CA issues.
• Issuer: Provides a distinguished name for the CA that issued the certificate. The issuer name is commonly represented by using an X.500 or LDAP format.
• Valid From: Provides the date and time when the certificate becomes valid.
• Valid To: Provides the date and time when the certificate is no longer considered valid. The date when an application or service evaluates the certificate must fall between the Valid From and Valid To fields of the certificate for the certificate to be considered valid.
• Public Key: Contains the public key of the key pair that is associated with the certificate.
• Signature Algorithm: The algorithm used to sign the certificate.
• Signature Value: Bit string containing the digital signature.

In addition to the version 1 fields, X.509 version 3 certificates include extensions that provide additional functionality and features to the certificate. These extensions are optional and are not necessarily included in each certificate that the CA issues:

• Subject alternative name: A subject can be presented in many different formats. For example, if the certificate must include a user’s account name in the format of an LDAP distinguished name, e-mail name, and a user principal name (UPN), you can include the e-mail name or UPN in a certificate by adding a subject alternative name extension that includes these additional name formats.
• CRL distribution points (CDP): When a user, service, or computer presents a certificate, an application or service must determine whether the certificate has been revoked before its validity period has expired. The CDP extension provides one or more URLs where the application or service can retrieve the certificate revocation list (CRL) from.
• Authority Information Access (AIA): After an application or service validates a certificate, the certificate of the CA that issued the certificate — also referred to as the parent CA — must also be evaluated for revocation and validity. The AIA extension provides one or more URLs from where an application or service can retrieve the issuing CA certificate.
• Enhanced Key Usage (EKU): This attribute includes an object identifier (OID) for each application or service a certificate can be used for. Each OID is a unique sequence of numbers from a worldwide registry.
• Certificate policies: Describes what measures an organization takes to validate the identity of a certificate requestor before it issues a certificate. An OID is used to represent the validation process and can include a policy-qualified URL that fully describes the measures taken to validate the identity.

Classification

Commercial CAs uses the concept of classes for different types of digital certificates. For example VeriSign has the following classification

• Class 1 for individuals, intended for email.
• Class 2 for organizations, for which proof of identity is required.
• Class 3 for servers and software signing, for which independent verification and checking of identity and authority is done by the issuing certificate authority.
• Class 4 for online business transactions between companies.
• Class 5 for private organizations or governmental security.

Other vendors may choose to use different classes or no classes at all as this is not specified in the specification, though, most do opt to use classes in some form.

Certificate Format and Encoding

The X.509 Digital certificate formats are defined using ASN.1 or Abstract Syntax Notation One, is an International Standards Organization (ISO) data representation format used to achieve interoperability between platforms.

The current structure of a X.509 v3 digital certificate looks as follows. This basically defines how a certificate contents should be written. You can check the details here.

You can think of it as a Java class or an XML schema. It does define how certificate contents should be encoded to store in files. Two commonly used encoding schemas are used to store X.509 certificates in files, DER and PEM, as described in next sections. The encoded form of such an ASN.1 definition can be compared to a .class file in Java.

PEM (Privacy Enhanced Mail) Encoding

The most commonly used encoding schema for X.509 certificate files is the PEM (Privacy Enhanced Mail) encoding. The full specification of PEM is in RFC 1421. But the idea of PEM encoding on X.509 certificates is very simple:
Encode the content with Base64 encoding.
Enclose the Base64 encoding output between two lines: '-----BEGIN CERTIFICATE-----' and '-----END CERTIFICATE-----'
Here is a structural sample of a PEM encoded X.509 certificate:

PEM encoded certificate files are supported by almost all applications and the extension of the certificate is .pem

DER (Distinguished Encoding Rules) Encoding

DER (Distinguished Encoding Rules) is another popular encoding used to store X.509 certificate files. The Distinguished Encoding Rules of ASN.1 is an International Standard drawn from the constraints placed on BER encodings by X.509. DER encodings are valid BER encodings. DER is the same thing as BER with all but one sender's options removed. For example, in BER a boolean value of true can be encoded in 255 ways, while in DER there is only one way to encode a boolean value of true. The full specification of DER is in RFC 1421.
X.509 certificate files encode in DER are binary files, which can not be view with text editors. DER encoded certificate files are supported by almost all applications. The file extensions for DER encoded certificates are .cer, .der, .crt

PKCS Formats

PKCS refers to a group of public-key cryptography standards devised and published by RSA Security. As such, RSA Security and its research division, RSA Labs, had an interest in promoting and facilitating the use of public-key techniques. To that end, they developed (from the early 1990s onwards) the PKCS standards. They retained control over them, announcing that they would make changes/improvements as they deemed necessary, and so the PKCS standards were not, in a significant sense, actual industry standards, despite the name. Some, but not all, have in recent years begun to move into standards organizations like the IETF PKIX working group.
The file extensions in this case are .p7b, .p7c, .p12, .pfx etc.

Real Examples

Let us check a real certificate, its details and its chain. Thank god there are certificate viewer tools that read those archaic encoding formats and show the certificates nicely! You can actually check any https url in any browser to check a X.509 digital certificate. Here we are going to check internet banking site of State Bank of India in Internet Explorer (IE).

Go to https://www.onlinesbi.com/ and click on the view certificate link as shown below.

Once you click on the view certificate link, Windows certificate viewer tool will open and show the certificate owned by State Bank of India. This certificate, as you can see in 'Issued by' field is issued by VeriSign Class 3 Extended Validation SSL SGC CA.

Certificate viewer also shows the details of a certificate. There are many fields and the 'Show' dropdown filters them for better viewing. The below image is showing some of the basic fields which are called version 1 fields. Here on the left you are seeing the subject, SBI, and its detail Distinguished Name (DN). On the right issuer's DN.

Verisign Root Certificates

Select the 'Extensions Only' from the show dropdown. Please note extensions are optional but they are very common now a days. On the left you are seeing CRL Distribution point and on the right AIA location.

You can click on http://EVIntl-crl.verisign.com/EVIntl2006.crl to download the CRL. The following image shows how CRL looks like. Every certificate normally points to a CRL given by its issuer.
Click on the 'Certificate Path' tab to see the certificate chain. Certificate viewer allows you see other certificates in the chain by highlighting a certificate and click on the 'View Certificate' button as shown on the right below. Here the chain also shows that VeriSign is a two tier CA, where VeriSign is the Root and 'VeriSign Class 3 Extended Validation SSL SGC CA' is a Issuing CA.

Click on the View Certificate button to see Issuer CA's certificate. Also you can clink on the AIA link, i.e. http://EVIntl-aia.verisign.com/EVIntl2006.cer to get the same certificate.
The issuer CA's certificate is as follows.

Verisign Root And Intermediate Certificates Download

Similarly you can see the root certificate as well. Please note that for root certificate the 'Issued to' or 'Subject' and 'Issued by' or 'Issuer' fields are same. So this is a self signed certificate.
You can also see the certificates using Chrome and Firefox. Chrome uses IE's certificate viewer but FF uses its own certificate viewer.

Certificate Validation Process

Before it trusts certificates, Browsers/applications perform a validation check to ensure that certificates are valid and that they have a valid certification path. The status of a public key certificate is determined through three distinct, but interrelated, processes. But this may vary slightly based on implementations.

Certificate Discovery or Chain Building

The chain-building process will validate the certification path by checking each certificate in the certification path from the end certificate to the root CA’s certificate. The certificates are retrieved from the Intermediate Certification Authorities store, the Trusted Root Certification Authorities store, or from a URL specified in the AIA attribute of the certificate. If it discovers a problem with one of the certificates in the path, or if it cannot find a certificate, the certification path is discarded as a nontrusted certification path.

To improve performance, Browsers/Operating Systems may store subordinate CA certificates in the Intermediate Certification Authorities store so that future requests for the certificate can be satisfied from the store, rather than accessing the certificate through a URL.

Certificate Storage

A certificate store will often contain numerous certificates, possibly issued from a number of different CAs. In Windows systems there are separate stores known as the machine store, used by the computer, and the user store or My store used by the currently logged-on user.

In Java Environment certificates are stored in JKS files and are pointed by System Properties

-Djavax.net.ssl.keyStore=${some path}/keystore.jks
-Djavax.net.ssl.trustStore=${some path}/cacerts.jks
-Djavax.net.ssl.keyStorePassword=key-store-password

Purpose

The certificate chain engine builds all possible certificate chains. The entire graph of certificate chains is constructed and then ordered by the “quality” of the chain. The best-quality chain for a given end certificate is returned to the calling application as the default chain.

Each chain is built by using a combination of the certificates available in the certificate stores and certificates available from published URL locations. Each certificate in the chain is assigned a status code. The status code indicates whether the individual certificate is:

Verisign Root Certificate Download

• Signature-valid Is the signature valid?
  
• Time-valid Are the certificate start and expiration dates properly configured, has the start date not occurred yet, or has the certificate expired?
  
• Expired Has the certificate expired?
  
• Revoked Has the certificate been revoked?
  
• Time-nested Have any of the certificates that are higher in the PKI hierarchy expired?
  
• Any other restrictions on the certificate For example, is the certificate being used for a purpose other than has been intended?
  

Each status code has a precedence assigned to it. For example, an expired certificate has a higher precedence than a revoked certificate. This is because an expired certificate should not be checked for revocation status.

If different status codes are assigned to the certificates in a certificate chain, the status code with the highest precedence is applied to the certificate chain and propagated into the certificate chain status.

Path validation

How To Install Verisign Root Certificate

For each certificate in the chain, the certificate chain engine must select a certificate of the issuing CA. This process, known as path validation, is repeated until a self-signed certificate is reached (typically, this is a root CA certificate).

There are different processes that can be used to select the certificate for an issuing CA. The actual process that is used is based on whether the certificate currently being investigated has the Authority Key Identifier (AKI) extension defined. Inspection of the AKI extension will lead to one of three matching processes being implemented:

• Exact match If the AKI extension contains the issuer’s user name and issuer serial number, only certificates that match on user name and serial number will be chosen in the chain-building process. As a further test, the issuer name on the issued certificate must match the subject name on the issuer certificate.
  
• Key match If the AKI extension only contains public key information, only certificates that contain the indicated public key in the Subject Key Identifier (SKI) extension will be chosen as valid issuers.
  
• Name match. If no information exists in the AKI, or if the AKI does not exist in the certificate, the certificate will be marked as “name match.” In name matching, the subject name of a certificate must match the issuer name in the current certificate in order for the certificate to be chosen as a valid issuer. Because the data is stored in a binary format, the name-matching process is case-sensitive.

In all cases, even if a matching certificate is not found in the store, the current certificate will still be marked as “exact match”, “key match” or “name match,” because this describes the attempted match rather than the attained match.

Caching

To increase performance, the certificate chain engine uses a least recently used (LRU) caching scheme. This scheme creates a cache entry for each certificate it encounters as it builds the certificate chain. Each cache entry includes the status of the certificate, so the best certificate chain can be built from cached items on subsequent calls to the chaining API without having to determine the status of each certificate again. After a certificate has been added to the cache, it will not be removed until it expires or is revoked.

During the path validation process, valid cached certificates will always be selected. If valid cached certificates are not found, a store search will be performed. For issuer certificates and CRLs, URL retrieval can be required to download the certificates and CRLs from the distribution point indicated in the URL.

All certificates are stored in the cache when the certificates are selected from a store or from a URL. The only difference is the location where the cached certificates are stored.

Revocation

The certificate chain engine will check each certificate in the chain to determine whether the certificate has been revoked and the reason for the revocation. The revocation checking can take place either in conjunction with the chain building process or after the chain is built. If a revoked certificate is discovered in the chain, the chain is assigned a lower quality value.

Further Reading

• X.509 Specifications and RFCs
  
• CA Browser Forum