Asymmetric encryption methods, which use a public key to provide confidentiality and trust, are generally used to
encrypt data transmitted over the internet. Proper management and safety of these keys is important. Public key
infrastructure (PKI) provides an environment in which public encryption keys can be created and managed. At the
heart of PKI are certificate authorities (CAs) who are responsible for issuing, validating, and revoking certificates.
This lesson covers the following topics:

Certificate authorities.

Certificate process.

Certificate attributes.
Certificate Authorities
Certificate authorities are reputable organizations, responsible for issuing public certificates to other companies
or organizations for secure communication over the internet. Certificate authorities are generally set up in a
hierarchy of multiple CAs to increase security. This is also known as certificate chaining. CAs are usually set up as
follows:

The first CA created is the root CA. The root CA has a self-signed certificate which is used to validate
additional subordinate CAs.

The subordinate CAs are known as intermediate CAs. These CAs validate issuing CAs.

Issuing CAs validate and distribute the certificates.
The follow graphics depicts the CA hierarchy.
This structure is commonly used to protect the root CA. If the root CA is ever compromised, all issued certificates
must be replaced. By implementing certificate chaining, only certificates issued by the compromised CA need to
be replaced.
Certificate Process
For an organization to get a certificate, it submits a certificate signing request (CSR). This request generally
includes the following information:
CSR Information
Common name
Description
The fully qualified domain name (FQDN) of the website.
Example: www.testout.com
Subject alternative
name
(SAN)
Organization
An optional field. The SAN allows the organization to have multiple host names covered in
one certificate.
Example: site1.testout.com and site2.testout.com
The legal name of the organization. The name cannot be abbreviated and any suffixes,
such as LLC, must be included.
Example: TestOut Corporation
Organizational unit
City/locality
State/county/region
This is the division that is handling the certificate.
Example: IT Department
City where the organization is located.
Example: Pleasant Grove
State where the organization is located. This should not be abbreviated.
Example: Utah
The two-letter code for the country where the organization is located.
Country
Example: US
Email address
Public key
The email address for the person managing the certificate in the organization.
Example: sysadmin@testout.com
Before filling out the CSR, the organization needs to generate a key pair. The public key
will be included here.
Once the CSR has been submitted to the certificate authority, the certificate authority validates the information
and issues the certificate.
Sometimes, the certificate authority may rely on a third party to perform the validation. These third parties are
called registration authorities (RA). The RA is certified by a root certificate authority and is authorized to issue
certificates for specific uses only.
Certificate Attributes
Each CA has the responsibility of maintaining a database that contains the information, or attributes, of each
certificate. The attributes that can be included are:

Version - The X.509 version used for the certificate.

Serial Number - A unique identifier for each certificate.

Signature algorithm - The algorithm used to sign the certificate (SHA-2, RSA, etc.).

Issuer - The CA that issues the certificate.

Valid From and Valid To - The two fields that show the validity period of the certificate.

Subject - The field that contains the name and location information of the organization.

Public Key - The algorithm used to create the key and the public key information.
Depending on the organization, there may also be additional optional fields called extensions in the certificate.
One of the key attributes is the Valid To field. If a certificate is not renewed by this date, it will expire and no
longer be valid. Aside from expiration, some other reasons a certificate might be invalidated are:

The organization no longer exists.

The private key has been compromised.

The issued certificate is discovered to be fake.
If a certificate is invalidated for these or other reasons, it will be added to a certificate revocation list (CRL). The
CRL is a blacklist of certificates. CAs must maintain and constantly update the CRLs as part of their databases.
Web browsers automatically download updated CRLs at set intervals.
The X.509 standard also defines an internet protocol which can be used to determine the validity or state of a
certificate. This is called the Online Certificate Status Protocol (OCSP). OCSP can be used to simplify the process
of checking whether or not a certificate is valid.
OCSP is designed to replace CRLs. Instead of a CA maintaining the CRL, an OCSP server called a responder
maintains the lists of any revoked certificate. When the browser connects to a site, the browser sends a request to
the OCSP responder to check the validity of the certificate. OCSP provides the following benefits:

Timely information on the status of a certificate.

Better bandwidth management because the client does not download the entire CRL.

A grace period for expired certificates.
PKI certificates are used to verify an organization’s identity and ownership of a public key. When an organization
requests a certificate, they must choose which type they need. The Certificate Authority needs to validate the
organization before issuing the certificate. The level of validation depends on the certificate type being
requested.
Certificate Types
Depending on the use and situation, there are different types of public key infrastructure (PKI) certificates. The
following table explains what these certificate types are and how they can be used:
Certificate Type
Description
A root certificate is the first certificate that a Certificate Authority creates. Root certificates
are:
Root Certificate

Self-signed certificates. These certificates go through a different validation process
which varies depending on the certificate and organization.

Used to sign lower-level certificates such as intermediate certificates.
SAN certificates allow an organization to cover multiple domains with one certificate. For
example, TestOut could cover the following domains in a single SAN certificate:
Subject
Alternative Name
(SAN)
Wildcard

TestOut.com

TestOut.net

LabSim.com
Wildcard certificates are similar to SAN certificates. But instead of covering multiple domains,
the organization can cover one domain and multiple subdomains. For example, TestOut could
Certificate
Code Signing
Certificate
cover the following in one certificate:

quiz.testout.com

labs.testout.com

videos.testout.com
Code-signing certificates are used by app developers to prove that their application is
legitimate.
If a user tries to run an app that does not have a certificate, they will receive an error stating
that the app cannot be trusted. The user can decide to close the app or run it.
Self-signed certificates are certificates that have not been validated or signed by a CA.
Self-Signed
Certificate

Self-signed certificates are easy and free to make.

Self-signed certificates do not provide the same protection and security as a CAvalidated certificate.

When a user visits a website using a self-signed certificate, they see a warning that the
certificate is not trusted.
Secure, encrypted emails are sent using the S/MIME Protocol.

Senders need to know the recipient's public key when sending a secure email. The
public key is found in email certificates.

Email certificates are mainly used in an organization that uses its own CA. But some
public CAs provide email certificates as well.
Email Certificate
User and
Computer
Certificate
User and computer certificates are used in a network environment to identify and validate
specific users or computers.
When a user or computers logs into a network, their certificate is sent to the server for
validation. This provides extra security to the network.
SSL Validation Levels
The most common use of certificates is for websites using SSL or TLS. These certificates prove to the user that the
site is legitimate and trustworthy. When a user visits a website that has been issued a certificate, they see a lock
icon in the address bar. The user can click that lock to view the certificate information.
When a website purchases a certificate, there are three different levels of validation a CA can offer. The following
table shows each level and how they are validated and used:
Validation Level
Description
Domain validation is the lowest level of validation. With domain validation:
Domain
Validation

A CA issues a domain-validated certificate to anyone listed as an administrator on the
WHOIS record.

Validation generally consists of a phone call or email.

Certificates are usually issued within minutes.
The organization validation is one step up from the domain validation. With organization
validation:
Organization
Validation

The purchaser needs to prove they are a domain administrator and also prove the
organization is legitimate.

The validation process includes proving the organization is real and some basic
information. But it is not as in depth as the extended validation.

These certificates can be issued in 1-3 days.
Extended validation is the highest level of validation offered by a CA. With extended
validation:
Extended
Validation

The purchaser needs to prove they are a domain administrator and the CA will also
validate all information on the organization.

The CA will validate using a thorough and standardized identity verification process.
This process includes proving:

o
Exclusive rights to the domain
o
The organization's legal, physical, and operational existence
o
The organization has authorized the issuance of the certificate
These certificate can take up to 5 days to be issued.
Extended Validation (EV)
The most common use of certificates is for websites using Secure Socket Layer (SSL) or Transport Layer Security
(TLS). These certificates prove to the user that the site is legitimate and trustworthy. When visiting a website that
has been issued a certificate, the user sees a lock icon in the address bar. The user can click the lock to view the
certificate information.
The highest level of these certificates is the Extended Validation certificate. The CA conducts a thorough and
standardized identity verification process before issuing an Extended Validation certificate. This process includes
the applicant proving:

Exclusive rights to the domain.

The organization's legal, physical, and operational existence.

The organization's authorization for the issuance of the certificate.
Extended validation certificates can take up to 5 days to be issued.
Certificate Formats
The X.509 standard defines the format for SSL certificates. The following table shows the more common formats:
Certificate X.509
Format
Description
Distinguished
Distinguished encoding rules (DER) is one of the older formats used. DER characteristics are:
Encoding Rules

DER is a set of rules that defines how data must be encoded in a file.

DER is defined by the ASN.1 standard.

DER is a binary (non-text) encoding format.

DER is mainly used in Windows systems.

DER certificates usually have a .der or .cer file extension.
PEM certificates are the most common certificates in use. PEM was originally created to
securely encode emails, but S/MIME and PGP quickly replaced it. The format PEM uses is
perfect for encoding certificates.

PEM certificates are base64 DER formatted. This means the binary information is
encoded into ASCII text.

The ASCII text is sandwiched between a header and footer that identify the data type.
Common identifiers are:
Privacy-Enhanced
Email (PEM)
o
CERTIFICATE
o
CERTIFICATE REQUEST
o
PRIVATE KEY
o
X509 CRL

A single PEM certificate can contain the intermediate certificate, root certificate, and
private key.

PEM certificates can have a .pem, .crt, .cer, or .key file extension.
Public Key Cryptography Standards PKCS)
PKCS is a group of standards published by RSA Security. These standards were published to promote the use of the
cryptography techniques, such as the RSA algorithm, and several others.
Standard
Description
The PKCS #7 standard is used to format certificates and has the following
characteristics:
Public Key Cryptography
Standards #7
(PKCS #7)
Public Key Cryptography
Standards #12
(PKCS #12)

Is also known as the Cryptographic Message Syntax (CMS) standard.

Is based on the PEM standard.

Can contain only the intermediate certificate and root certificate, but
not the private key.

Is mainly used with digital signatures.

Uses a file extension of .p7b or .p7c.
The PKCS #12 standard is also used to format certificates. It has the following
characteristics:

Is also known as the Personal Information Exchange Syntax Standard.

Is based on the PEM standard.

Holds certificate chains and the private key.

Protects certificates and private keys with a password.

Uses a file extension of .pfx or .p12.
Using digital certificates to share public keys and validate organizations is a critical component of doing business
over the internet. Certificate authorities (CAs) are the trusted organizations that validate and administer digital
certificates.
Certificate Chaining
Certificate authorities are generally setup in a hierarchy of multiple CAs to increase security.

The first CA created is the root CA. The certificate is self-signed and is used to validate additional
subordinate CAs.

The subordinate CAs are known as intermediate CAs. These CAs validate issuing CAs

Issuing CAs validate and distribute the certificates.
This structure is known as certificate chaining or the Chain of Trust. It is commonly used to protect the root CA.
For example, if the root CA is compromised, then all the certificates issued by that CA would need to be replaced.
By implementing certificate chaining, if a CA is compromised, only the certificates issued by that CA would need
to be replace.
Another common method of protecting the root CA is to bring it online only when it needs to authorize a new
intermediate CA. Being offline means the root CA is isolated from all network access and is usually turned off.
Certificate Revocation List Management
A certificate revocation list contains a list of digital certificates that have been revoked by the issuing certificate
authority before their scheduled expiration date and should no longer be trusted. If the root CA is taken offline, it
can no longer maintain the CRL.
The following table describes other methods that can be used to keep track of these revoked certificates:
CRL Management Description
Intermediate CA
An organization can choose to setup and configure an intermediate CA whose sole purpose is to
maintain and update the CRL.
The Online Certificate Status Protocol (OCSP) is a protocol that web browsers can use to quickly
check the status of a certificate. The purpose of OCSP is to replace the need for the CRL. OCSP
is commonly implemented using:
Online Certificate
Status Protocol
(OCSP)

OCSP Stapling
o
OCSP stapling can be used to help with performance. Stapling means that the
server holding the certificate also provides revocation information. This
server sends a query to the OCSP responder at set intervals to verify the
status of it's certificate. The server will attach, or staple, the response to it's
certificate.
o

During the initial SSL or TLS handshake between the server and a user's web
browser, the OCSP validation is sent along with the certificate removing the
need for the browser to send a separate request for the certificate status.
Certificate pinning
o
Certificate pinning is when an application, such as a web browser, has a
server's certificate hard coded into it. When the application connects to the
server, it downloads and checks the certificate. If the two certificates don't
match, the application takes appropriate action including blocking the
connection.
o
Certificate pinning was never truly adopted by web browsers and is mostly
used in organizations that have their own CA setup.
Trust Models
Trust models are configurations you can use to setup certificate authorities. The trust model you choose depends
on the number of certificate authorities being implemented and their use. The following table explains each of
these models:
Trust model
Description
All CAs start with a single trust model. This is the simplest model to setup. The single trust model
has the following characteristics:
Single trust
model

There is only one CA that issues and distributes certificates.

All users trust the CA and there are no trusts established with other CAs.

This model works properly only in a small organization.

If the CA is compromised, all certificates must be replaced.
A hierarchical model looks like a tree.
Hierarchical
model

The first CA created is the root CA. It is a self-signed certificate and is used to validate
additional subordinate CAs.

The subordinate CAs are known as intermediate CAs. The intermediate CAs validate
issuing CAs.

Issuing CAs validate and distribute the certificates.
In the mesh model, multiple CAs are setup to issue certificates to each other. No CAs are
configured in a subordinate relationship.
Mesh model

If a CA is compromised, certificates can still be trusted because multiple CAs have
authenticated them.

This model is difficult and expensive to expand on a large scale.
The bridge model is a hybrid model that connects the hierarchical models of two organizations.
Bridge model

Clients in both organizations will trust certificates issued by CAs of either organization.

Trusts can be setup further down the tree for deeper customization and security.
Web of trust
A web of trust is typically used with Pretty Good Privacy encryption (PGP). Instead of
implementing a CA, everyone is considered a trusted authority. For example, if User1 trusts User2
and User2 trusts User3, User1 will also trust User3.
Private Key Safety
To ensure data can always be recovered, you should create a backup of the private keys. It is important to have a
backup and equally important that the backup is kept safe. The following table shows two main methods to backup
private keys:
Key Backup
Description
Method
Key
archival
In key archival, the key is backed up by the CA. To do this, the user sends the private key in a secure
transmission to the CA to back it up. This method is often used in an organization that manages its
own CA.
If keys are lost, they will be readily available and easily accessed. However, if the CA is breached, all
private keys will be compromised.
Key escrow is a common method of key archival. With this method, keys are sent to a trusted 3rd
Key escrow party instead of a CA. This is often done for security and legal purposes. Legal action might be
required to access the keys. This is done by design to ensure security and safety of the keys.
Once an SSL client has identified a CA as trusted, it uses the CA's public key to validate the CA's digital signature
on the server certificate. If the digital signature can be verified, the client accepts the server certificate as a valid
certificate issued by a trusted CA.
SSL clients verify a server's identity using the following steps:
1.
The client checks the server's certificate validity period. The authentication process stops if the current
date and time fall outside of the validity period.
2.
The client verifies that the issuing certificate authority is on its list of trusted CAs.
3.
The client uses the CA's public key to validate the CA's digital signature on the server certificate. If the
digital signature can be verified, the client accepts the server certificate as a valid certificate issued by a
trusted CA.
4.
To protect against man-in-the-middle attacks, the client compares the actual DNS name of the server to
the DNS name on the certificate.
The registration authority (RA) processes all requests for digital certificates. Registration and authentication
requirements vary based on the class of certificate requested. Once the RA has successfully authenticated the
requesting party, the request is forwarded to the certificate authority (CA) for certificate generation.
The standard for certificates that is most widely used is X.509. This standard defines the key elements that must
exist within a certificate. This standard is used by public key infrastructure (PKI), SSL, IPsec, DES, and many other
infrastructure components and technologies.
Key escrow backs up private keys to a third-party organization outside of the company. If the private key is lost,
you can recover the key from escrow.