7.5 Public Key Infrastructure Flashcards
What is the lifecycle of an encryption key?
What is the role of a certificate authority (CA)?
What are the types of certificates?
Which standard defines the format of certificates?
Which trust model would be used to connect the CAs of two organization’s?
Public key infrastructure
(PKI)
PKI is an environment in which public encryption keys can be created and managed throughout the key lifecycle.
Certificate authorities
Certificate authorities are reputable organizations that are responsible for issuing public certificates to companies or organizations that want to securely communicate over the internet.
X.509 or OCSP
The standard that defines the format of certificates. This is called the Online Certificate Status Protocol, or OCSP.
Certificate chaining
Certificate authorities are usually setup in a hierarchy of multiple CAs to increase security. This structure is known as certificate chaining or the chain of trust.
Trust model
A PKI uses a trust model to establish trust between two communicating entities. Depending on the number of CAs being implemented and the use, there are a few configurations that can be used to setup certificate authorities.
7.5.1 Public Key Infrastructure
Public Key Infrastructure (PKI) 0:00-0:53
When we encrypt data over the internet, we generally utilize asymmetric encryption methods that involve sending a user’s public key to provide confidentiality and trust. Because these keys are public, we need a way to manage and protect them.
Key management covers these keys’ whole life cycle. During this cycle, we must keep keys safe because we need to be sure that the public key we’re using really does belong to the organization it’s associated with. Public key infrastructure, or PKI, handles this for us.
A PKI provides an environment where public encryption keys can be created and managed. At the heart of a PKI are Certificate Authorities, which are responsible for issuing, validating, and revoking certificates. In this lesson, I’ll go over the concept of Certificate Authorities, or CAs, and the process they use to verify a certificate with all of its different attributes.
Certificate Authorities 0:54-1:28
A PKI relies on certificates that validate organizations. This creates a web of trust across the internet, allowing us to perform transactions confidently with websites around the globe. A PKI requires several elements to be effective.
The first element is the CA. CAs need to be reputable organizations that are respected enough to issue public certificates to organizations that want to communicate securely over the internet.
To increase security, CAs operate in a hierarchy of multiple CAs. This is done so that if one CA is compromised, only the certificates it issued need to be revalidated.
Root CA 1:29-1:34
The first CA is the Root CA. This is a self-signed certificate that’s used to validate additional CAs.
Intermediate CAs 1:35-1:55
These Subordinate CAs are also known as Intermediate CAs. We can have multiple Intermediate CAs based on their policies and regulations. The Intermediate CAs validate the Issuing certificate authorities, and the Issuing CA is the one that hands out the certificates.
Now that we understand the certificate authorities’ hierarchy, let’s look at how an organization can obtain their very own certificate.
Certificate Process 1:56-2:12
To obtain a certificate, an organization needs to first send in a certificate signing request, or CSR, to a Certificate Authority. The CSR should contain the organization’s public key, domain name, and digital signature. Then the CA verifies this information and issues the certificate.
Common Name 2:13-2:26
When filling out the CSR, the organization provides their Common Name, or CN, which is more commonly referred to as the Fully Qualified Domain Name. For example, here you see that TestOut’s Common Name would be www.testout.com.
Subject Alternative Name (SAN) 2:27-2:48
The organization can also apply for a Subject Alternative Name, or SAN. This allows one certificate to apply to multiple host names. For example, TestOut could apply for a SAN that would cover site1.testout.com and site2.testout.com.
Once the CA has received the CSR, they verify the information and provide the certificate to the requesting organization.
Registration Authority 2:49-3:07
Sometimes the CA relies on a third party to perform the validation. These third parties are called Registration Authorities. An RA is certified by a Root CA and is authorized to issue certificates for specific uses only. No matter who issues the certificates, each one has specific attributes for specific purposes.
Certificate Attributes 3:08-3:53
Each CA’s responsibility is to maintain a database that contains information on each certificate they’ve issued. This information is mainly their certificates’ attributes.
These attributes contain everything from the serial number and signature algorithm to the public key and expiration date. CAs use the X.509 standard to define these attributes.
Each certificate has an expiration date. Before the certificate expires, the organization must revalidate the information and renew their certificate. If they don’t, it’s no longer valid.
Aside from expiration, there are other reasons a CA might invalidate or revoke a certificate. For example, if the organization is found to no longer exist, if the private key is compromised, or if the certificate was discovered to be fake, the CA should immediately revoke the certificate.
Certificate Revocation List (CRL) 3:54-4:07
When a CA does revoke a certificate, it’s added to a Certificate Revocation List, or CRL. This is a type of certificate blacklist. CAs maintain the CRL as part of their databases, and these should be updated quite often.
Online Certificate Status Protocol (OCSP) 4:08-4:52
The X.509 standard also defines an internet protocol that can be used to determine a certificate’s current state. This is called the Online Certificate Status Protocol, or OCSP.
The way OCSP works is your browser sends a status request to an OCSP responder and receives a response as to whether a certificate is valid or has been revoked.
Using the OCSP provides a few benefits. These include providing more timely information on a certificate’s status, better bandwidth management because the client doesn’t need to download the CRL, and a grace period for expired certificates.
If we follow the guidelines set in the X.509 standard, we can be assured that internet certificates are valid and have been checked appropriately by reputable Certificate Authorities.
Summary 4:53-5:08
That’s it for this lesson. In this lesson, we covered Certificate Authorities and the hierarchical structure they’re set up in. We also looked at the process an organization goes through to request a certificate for themselves. Finally, we looked at some certificate attributes and how CAs use them to validate certificates or put them on a Certificate Revocation List.
7.5.3 Certificate Types
Certificate Types 0:00-0:26
Depending on your purpose, there are different types of public key infrastructure certificates, or PKI certificates. These certificates are used to verify an organization’s identity and ownership of the public key. In this lesson, I’ll cover these types of certificates and how you can use them. I’ll also go over some different validation levels used for SSL certificates.
Root Certificates 0:27-0:47
A root certificate is the first certificate that a Certificate Authority, or CA, creates. This certificate is self-signed and is used to sign lower-level certificates, such as intermediate certificates. These certificates go through different processes to be approved, and the process depends on the certificate and organization.
Subject Alternative Name (SAN) Certificates 0:48-1:06
Subject Alternative Name certificates, or SAN certificates, allow an organization to cover multiple domains. For example, TestOut could cover testout.com, testout.net, or even labsim.com with the same certificate.
Wildcard certificates are like SAN certificates.
Wildcard Certificates 1:04-1:20
Wildcard certificates allow an organization to cover unlimited subdomains. For example, TestOut could cover any site that ended in testout.com with the same wildcard certificate.
Code-Signing Certificates 1:21-1:34
Code-signing certificates are used by app developers to prove that an application is legitimate and hasn’t been altered or compromised. When the user installs a program and there’s no certificate, they receive a warning that they shouldn’t trust the app.
Self-Signed Certificates 1:35-1:54
Self-signed certificates are certificates that haven’t been validated and signed by a CA. These certificates are easy and free to make, but they don’t provide the same protection and security as a CA-validated certificate. If a website uses a self-signed certificate, the user sees a warning when visiting the site.
Email Certificates 1:55-2:15
Secure, encrypted emails are generally sent using the S/MIME Protocol. When you send secure emails, you need to know the recipient’s public key, which you find in email certificates. These certificates are usually used within an organization that uses its own CA, but some public CAs also provide email certificates.
User and Computer Certificates 2:16-2:28
You can use certificates to identify and validate individual users and computers. You generally see these kinds of certificates in a network environment where they’re used to validate a computer or user to the server.
Validation Levels 2:29-3:51
The most common use for certificates is for websites that use SSL or TLS. These certificates validate that the website is authentic and secure so that users feel safe.
When a site wants to purchase a certificate, there are three different validation levels a CA can offer. These are domain validation, organization validation, and extended validation.
Domain validation is the lowest level and isn’t very secure. A CA issues a domain-validated certificate to anyone who’s listed as the domain administrator in the WHOIS record. The CA usually validates this with a simple phone call or email, which isn’t hard to spoof. These certificates can be issued usually within a matter of minutes.
An organization validation requires the certificate purchaser to not only prove that they’re a domain administrator, but also that the organization is real. This process varies with each CA, but it’s more in-depth than a domain validation. These certificates may take 1 to 3 days to be issued.
Extended validation is the highest level of trust. An extended validation requires the purchaser to prove that they’re the domain administrator and also requires a much more thorough vetting of the organization itself. These certificates may take 1 to 5 days to be issued.
Summary 3:52-4:01
That’s it for this lesson. In this lesson, we discussed the different types of PKI certificates and how CAs implement them. We also looked at the three validation levels for SSL certificates and how each level differs.
