What are the main features of a digital certificate?

The certificate purpose defines the intended primary use of the certificate. The certificate purpose can be one of four settings:

• Encryption. A certificate with this purpose will contain cryptographic keys for encryption and decryption.
  
• Signature. A certificate with this purpose will contain cryptographic keys for signing data only.
  
• Signature and encryption. A certificate with this purpose covers all primary uses of a certificate’s cryptographic key, including encryption of data, decryption of data, initial logon, or digitally signing data.
  
• Signature and smartcard logon. A certificate with this purpose allows for initial logon with a smart card, and digitally signing data; it cannot be used for data encryption.

SSL is probably the first protocol to use digital certificates. Now a days they are widely used where ever there is a need for signing and encryption.

---

A Certificate Authority (CA) issues digital certificates that contain a public key and the identity of the owner. The matching private key is not made available publicly, but kept secret by the end user who generated the key pair. The certificate is also a confirmation or validation by the CA that the public key contained in the certificate belongs to the person, organization, server or other entity noted in the certificate. A CA's obligation in such schemes is to verify an applicant's credentials, so that users and relying parties can trust the information in the CA's certificates. CAs use a variety of standards and tests to do so. In essence, the Certificate Authority is responsible for saying "yes, this person is who they say they are, and we, the CA, verify that".

If the user trusts the CA and can verify the CA's signature, then he can also verify that a certain public key does indeed belong to whoever is identified in the certificate. Browsers maintain list of well known CAs root certificates.  Aside from commercial CAs, some providers issue digital certificates to the public at no cost. Large institutions or government entities may have their own CAs.

CA Hierarchy

CAs are hierarchical in structure. There are generally three types of hierarchies, and they are denoted by the number of tiers.

Single/One Tier Hierarchy

A single tier Hierarchy consists of one CA. The single CA is both a Root CA and an Issuing CA. A Root CA is the term for the trust anchor of the PKI. Any applications, users, or computers that trust the Root CA trust any certificates issued by the CA hierarchy. The Issuing CA is a CA that issues certificates to end entities. For security reasons, these two roles are normally separated. When using a single tier hierarchy they are combined. 

Two Tier Hierarchy

A two tier hierarchy is most common. In some ways it is a compromise between the One and Three Tier hierarchies. In this design there is a Root CA that is offline, and a subordinate issuing CA that is online. The level of security is increased because the Root CA and Issuing CA roles are separated. But more importantly the Root CA is offline, and so the private key of the Root CA is better protected from compromise. It also increases scalability and flexibility. This is due to the fact that there can be multiple Issuing CA’s that are subordinate to the Root CA. This allows you to have CA’s in different geographical location, as well as with different security levels. 

Three Tier Hierarchy

Specifically the difference between a Two Tier Hierarchy is that second tier is placed between the Root CA and the issuing CA. The placement of this CA can be for a couple different reasons. The first reason would be to use the second tier CA as a Policy CA. In other words the Policy CA is configured to issue certificates to the Issuing CA that is restricted in what type of certificates it issues. The Policy CA can also just be used as an administrative boundary. In other words, you only issue certain certificates from subordinates of the Policy CA, and perform a certain level of verification before issuing certificates, but the policy is only enforced from an administrative not technical perspective.

The other reason to have the second tier added is so that if you need to revoke a number of CAs due to a key compromise, you can perform it at the Second Tier level, leaving other “branches from the root” available. It should be noted that Second Tier CAs in this hierarchy can, like the Root, be kept offline.

Obtaining a Certificate From CA

You can obtain a certificate for your business from commercial CAs. The Issuing entities of commercial CAs provide certificate with a cost.
User can directly approach to a issuing CA, in this case issuing CA will generate a Key pair on user's behalf. Hand over the private key to the user and provide the certificate containing the public key with Issuing CA's signature after all necessary validations as per CA's policy.

User can also generate a Key pair of its own using some tool like Keytool in Java and generate a Certificate Signing Request (CSR) using some tool again, e.g. Keytool and then send the CSR to Issuing CA for a certificate. CSR contains the public key of the user and user identity information in a format that issuing CAs would normally expect.

User must keep the private key secret. If private key is compromised or lost then issuing CA must be informed. This is similar to loosing a credit card. CAs keep the certificates in Certificate Revocation List whose private keys believed to have been compromised or lost.

You can yourself be a CA and issue your own certificates, these are called self signed certificates but for commercial purpose your self signed certificated will not be trusted.  Only established and well known CAs self signed certificates are trusted. Root certificate of a CA is always self signed.

Certificate Chain or Certificate Path

When you get a certificate for your public key from a commercial CA then your certificate is associated with a chain of certificates or sometimes called chain of trust. The number of certificates in the chain depends on the CA's hierarchical structure. The following image shows a certificate chain for a two tier CA. The owners/users certificate is signed by a Issuing CA and issuing CA's certificate is signed by the Root CA. Root CA's certificate is self signed.

During a User's certificate validation by a browser or a program, browser needs to validate the signature by finding the public key of the next issuing CA or intermediate CA. The process will continue until the root certificate is reached. Root CA is self signed and must be trusted by the browser at the end. Browsers keep all well known CAs root certificates in their trust store.

AIA Locations

When a client or application is validating a certificate it needs to not only validate the certificate that is being used but also the entire chain of the certificate. In other words, the application or client needs a certificate from each CA in the chain beginning with the issuing CA and ending with the Root CA. If the application or client does not have access to the certificates in the chain locally the application or client needs a place from which to obtain the certificates. This location is called the Authority Information Access or AIA. The AIA location is the repository where the CA certificate is stored so that it can be downloaded by clients or applications validating a certificate. The AIA location is included in the AIA extension of a certificate.

CDP Locations

A CRL Distribution Point (CDP) is where clients or applications that are validating a certificate download the certificate revocation list (CRL) to obtain revocation status. CA’s periodically publish CRLs to allow clients and applications to determine if a certificate has been revoked. CRLs contain the serial number of the certificate that has been revoked, a timestamp indicating when the certificate was revoked, as well as the reason for revocation.

Anatomy of a Certificate

---

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 certificates

X.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.

Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST be v3
        }
AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }
.... More definitions will follow for CertificateSerialNumber, Name, Validity etc ...

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:

-----BEGIN CERTIFICATE-----
MIIDODCCAvagAwIBAgIERqplETALBgcqhkjOOAQDBQAwfzELMAkGA1UE
...
...
Cgfs2kXj/IQCFDC5GT5IrLTIFxAyPUo1tJo2DPkK
-----END 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.

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.

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:

• 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

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. 

What are the features of digital certificate?

What are the main features of a digital certificate quizlet?

What is the main point of a digital certificate?

What are 3 things included in a digital certificate?