CompTIA Security+ Full Course: Public Key Infrastructure (PKI)

Summary

This video script delves into the intricacies of Public Key Infrastructure (PKI), digital certificates, and the validation of online identities. It explains the importance of asymmetric cryptography, the role of private and public keys in encryption and digital signatures, and how PKI ensures the authenticity of public keys. The script also covers certificate authorities, the process of certificate validation, and the various types of certificates, highlighting the significance of trust and security in digital communications.

Takeaways

• 🔒 Public Key Infrastructure (PKI) is essential for validating digital identities and ensuring the trustworthiness of digital certificates.
• 🔑 Asymmetric cryptography, using a private and public key pair, is the foundation of PKI, allowing secure communication and identity verification.
• 🌐 Digital certificates are more than just public keys; they include identity information and are validated by trusted certification authorities (CAs).
• 🤔 Trust in a CA is crucial; if a CA's private key is compromised, all certificates signed by that CA may be considered invalid.
• 📜 Certificates contain several key pieces of information, including the public key, identity information, and usage purposes, which are all digitally signed by the issuing CA.
• ⛓ Certificates are often part of a hierarchy, with root, intermediate, and leaf CAs, to distribute trust and minimize the risk of a single point of failure.
• 📝 Certificate Signing Requests (CSRs) are used to request a CA to issue a certificate, containing identity information and a public key that the CA must verify.
• 🔄 Certificates have a lifecycle that includes creation, storage, usage, and eventual revocation or renewal, with expiration dates being a key aspect of certificate management.
• 🛡️ Certificate pinning (HBKP) is a security measure to prevent man-in-the-middle attacks by embedding expected certificate information within an application.
• 📁 Certificates can be stored in various formats, including PEM (ASCII), DER (binary), and PFX/P12 (which may include both public and private keys), each with its own use cases and security considerations.
• 🛠️ Tools like OpenSSL are vital for generating, managing, and validating certificates, offering a command-line approach to certificate creation and inspection.

Q & A

What is Public Key Infrastructure (PKI) and why is it important?

Public Key Infrastructure (PKI) is the infrastructure that enables the validation of identities within digital certificates. It's crucial because it ensures that when a digital certificate is presented, there's a reliable method to verify the information it contains, thus confirming the identity of the certificate holder.

How does asymmetric cryptography play a role in PKI?

Asymmetric cryptography is foundational to PKI as it uses a pair of keys: a private key that should be kept secure and a public key that can be freely shared. The public key is used for encryption and verification of digital signatures, while the private key is used for decryption and signing, thus connecting the keys to the unique identities of individuals.

What is a digital certificate and how does it relate to a public key?

A digital certificate is a file that contains a user's public key and identity information, such as their name and organizational details. It's essentially a container for the public key and serves as a way to validate the identity of the key's owner, ensuring that the public key is associated with a legitimate and verified identity.

Why can't anyone trust a public key simply by downloading it from the internet?

Simply downloading a public key from the internet isn't trustworthy because an attacker could intercept the key exchange and replace the original key with their own. PKI helps prevent this by using certificates that are signed by trusted entities known as Certificate Authorities (CAs), which validate the authenticity of the public key.

What is a Certificate Authority (CA) and how does it sign a digital certificate?

A Certificate Authority (CA) is a trusted entity that issues digital certificates. It signs a digital certificate by calculating a hash of the certificate's content and then encrypting that hash with the CA's private key. This digital signature can be validated using the CA's public key, which, if trusted, confirms the certificate's authenticity.

What is the purpose of a digital signature in the context of PKI?

A digital signature serves to authenticate the identity of the signer and to ensure the integrity of the message or document being signed. It involves encrypting a hash of the message with the signer's private key. Anyone with the signer's public key can decrypt the hash and verify it against the original message, thus confirming the signer's identity and that the message has not been altered.

Why are there different levels of validation for issuing web server certificates?

Different levels of validation exist to ensure the security and authenticity of web server certificates. Domain validation checks ownership of the domain, while extended validation further verifies the legal identity of the entity requesting the certificate. This helps prevent the issuance of certificates for phishing or spoofed domains.

What is a self-signed certificate and why might it be used?

A self-signed certificate is a digital certificate that is signed by the same entity whose identity it certifies, rather than by a trusted CA. It might be used in internal networks, lab environments, or proof-of-concept scenarios where a trusted third-party CA is not required or available.

What is the process of certificate revocation and why is it necessary?

Certificate revocation is the process of declaring a valid certificate no longer valid before its scheduled expiration. It is necessary when a private key is compromised, a certificate is no longer needed, or in cases where a certificate must be immediately invalidated for security reasons.

How do clients know if a certificate has been revoked?

Clients can check if a certificate has been revoked by referring to a Certificate Revocation List (CRL) provided by the issuing CA or by using the Online Certificate Status Protocol (OCSP), which allows for real-time validation of a certificate's status.

What is the purpose of certificate pinning and how does it work?

Certificate pinning, also known as HPKP (HTTP Public Key Pinning), is a security technique used to prevent man-in-the-middle attacks by associating a certain public key with a certain web server. It involves embedding the public key or hash of the key in the application code, allowing the browser to verify if the presented certificate matches the expected key.

What are the different file formats for storing certificates and what are their uses?

Certificates can be stored in various file formats such as DER (binary format), PEM (ASCII format), CRT/CER (which can be either binary or ASCII but don't specify which), PFX/P12 (for bundling a private key with a certificate), and P7B (for storing the entire certificate chain). These formats serve different purposes, from ease of transportability and readability to security and comprehensiveness in certificate chain storage.

How can one generate a self-signed certificate using OpenSSL?

A self-signed certificate can be generated using OpenSSL with a command that specifies the key pair generation and the creation of a self-signed certificate with a specified expiration date. The certificate is then outputted in a chosen format, such as PEM, which is easily readable and transportable.

Outlines

00:00

🔐 Public Key Infrastructure and Digital Certificates

The paragraph introduces the concept of Public Key Infrastructure (PKI) as a system for validating digital identities through certificates. It explains that while anyone can generate a digital certificate, PKI is essential for vouching for one's identity. The paragraph discusses asymmetric cryptography, the roles of private and public keys in encryption and digital signatures, and the importance of having a trusted authority to validate these keys. It also touches on the risks of public key interception by attackers and how PKI helps prevent such scenarios by ensuring the authenticity of public keys through certificates issued by trusted entities.

05:00

🛡️ Certificate Authorities and Trust Hierarchy

This paragraph delves into the role of Certificate Authorities (CAs) in the PKI ecosystem. It explains how CAs sign digital certificates to validate the identity of individuals or entities. The process involves CAs encrypting a hash of the certificate with their private key, allowing others to verify its authenticity using the CA's public key. The paragraph also discusses the importance of trusting CAs and the concept of a trust hierarchy, where operating systems and browsers maintain a list of trusted CAs. It further explains the potential risks if a CA's private key is compromised and the measures taken to mitigate these risks, such as the use of local CAs within enterprises.

10:02

🔄 Certificate Lifecycle and Hierarchy of Trust

The paragraph discusses the lifecycle of digital certificates, from creation to revocation. It explains the process of generating a certificate signing request (CSR) and the validation process that CAs undertake before issuing a certificate. The concept of a hierarchy of trust is further explored, with the introduction of root, intermediate, and leaf CAs, which create a chain of trust. The benefits of this model, such as taking the root CA offline for security, are highlighted. The paragraph also touches on the registration process with CAs, which involves identity verification before certificates can be issued.

15:03

📄 Certificate Contents and Validation

This paragraph provides an in-depth look at the contents of a digital certificate, including the public key, identity information, and various fields that describe the certificate's purpose and constraints. It explains the importance of the subject and subject alternative names (SANs) in identifying the entity a certificate represents. The paragraph also discusses key usage fields and extended key usage fields, which define the permitted uses of a certificate. Additionally, it covers the concepts of critical and non-critical extensions within a certificate and their implications for validation.

20:03

🌐 Domain Validation and Certificate Types

The paragraph examines the process of domain validation, which is a security measure to ensure that a certificate applicant is the legitimate owner of the domain they claim. It contrasts domain validation with extended validation for higher-profile websites. The paragraph also outlines various types of certificates, such as those for users, servers, applications, and self-signed certificates, explaining their purposes and the contexts in which they are used. It also touches on the dual authentication process for both users and machines in network access scenarios.

25:04

🔑 Key Management and Storage

This paragraph focuses on the challenges and methods of secure key management. It discusses the importance of securely storing private keys, the risks associated with key backup and storage, and the strategies to mitigate these risks, such as key escrow and segmented storage. The paragraph also covers the process of certificate renewal and revocation, highlighting the procedures followed when a certificate expires or is compromised.

30:05

🗂️ Certificate Formats and Management

The paragraph provides an overview of different certificate file formats, such as DER, PEM, CRT, CER, PFX, P12, and P7B, explaining their purposes and how they store certificate data. It also discusses the tools and commands used to manage certificates, particularly focusing on OpenSSL utilities for tasks like generating key pairs, creating self-signed certificates, and validating certificates. The paragraph concludes with examples of OpenSSL commands that can be used for certificate management.

35:06

🛡️ Certificate Security and Revocation Methods

This paragraph discusses the importance of certificate security, the process of certificate expiration, and the methods for certificate revocation. It explains the use of Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) as two primary methods for managing and validating the status of certificates. The paragraph also introduces the concept of OCSP stapling, a process that allows web servers to respond to certificate validation queries on behalf of CAs. Additionally, it touches on the security measure of certificate pinning as a defense against man-in-the-middle attacks.

Keywords

💡Public Key Infrastructure (PKI)

Public Key Infrastructure is a system that enables the secure communication and identification of entities across a network. It is central to the video's theme as it underpins the validation of digital certificates and identity verification. In the script, PKI is described as the infrastructure that allows for the validation of identity within a digital certificate, emphasizing its role in cybersecurity.

💡Digital Certificate

A digital certificate is an electronic document used to establish the identity and credentials of an individual, organization, or server. It is a key concept in the video, illustrating how entities can be authenticated in a digital space. The script mentions that anyone can generate a digital certificate, but the validation of this certificate is what truly matters, highlighting the importance of PKI.

💡Asymmetric Cryptography

Asymmetric cryptography refers to cryptographic systems that use two different keys: a public key for encryption and a private key for decryption. The video discusses this concept as the foundation for connecting keys to unique identities, with the script noting that the private key should be kept safe while the public key can be shared freely.

💡Digital Signature

A digital signature is a cryptographic mechanism used to verify the authenticity and integrity of a digital message or document. The video explains how digital signatures are created by encrypting a hash of a message with a private key, and the script provides an example of how this process helps in proving one's identity to another party.

💡Certificate Authority (CA)

A Certificate Authority is a trusted entity that issues digital certificates, validating the identity of the certificate holder. The script explains the role of CAs in the PKI hierarchy, emphasizing their importance in signing digital certificates and establishing trust among users.

💡Private Key

A private key is a secret component in asymmetric cryptography, used for decryption or for signing digital data. The video script discusses the importance of keeping the private key secure and how it is used in conjunction with the public key for secure communication and identity verification.

💡Public Key

The public key is the counterpart to the private key and can be freely distributed. It is used for encryption or to verify digital signatures. The script clarifies that while anyone can encrypt data with a public key, only the holder of the corresponding private key can decrypt it.

💡Certificate Revocation List (CRL)

A Certificate Revocation List is a record maintained by a CA that contains serial numbers of certificates that have been revoked before their scheduled expiration date. The video script describes CRL as a method used by CAs to inform users about certificates that are no longer valid.

💡Online Certificate Status Protocol (OCSP)

The Online Certificate Status Protocol is a protocol used to obtain the revocation status of a certificate. The script explains OCSP as a dynamic method for providing certificate status information, offering a more immediate response compared to CRLs.

💡Self-Signed Certificate

A self-signed certificate is a digital certificate that is signed by the same entity whose identity it certifies. The script mentions self-signed certificates as being typically used in internal networks or lab environments, where they are trusted by configuration but not inherently by clients outside the issuing domain.

💡Certificate Pinning

Certificate pinning, also known as HTTP Public Key Pinning (HPKP), is a security mechanism that helps prevent man-in-the-middle attacks by associating a certain public key with a certain web server. The script discusses this as a method to ensure that the certificate presented by a server matches a pre-agreed key, enhancing security.

Highlights

Public Key Infrastructure (PKI) is essential for validating digital identities through certificates.

Anyone can generate a digital certificate, but PKI verifies the identity behind the public key.

Asymmetric cryptography with private and public keys is the foundation of connecting keys to identities.

Public keys can be freely shared, while private keys must remain secure for digital signatures and encryption.

Digital signatures authenticate identity by encrypting hashes with the private key.

PKI protects against man-in-the-middle attacks by ensuring the validity of public keys.

Digital certificates contain more than just the public key; they include identity information and are signed by a trusted authority.

Certificate Authorities (CAs) validate and sign digital certificates, establishing trust.

Trust in CAs is hierarchical, with root, intermediate, and leaf CAs creating a chain of trust.

Operating systems and browsers have built-in lists of trusted CAs for validating certificates.

Local CAs can be used within enterprises for an internal trust network.

Certificates have a lifecycle, including creation, storage, and eventual revocation or renewal.

Secure storage of private keys is critical to prevent exposure and ensure data access.

Certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP) are methods for checking certificate validity.

HTTP Public Key Pinning (HPKP) prevents man-in-the-middle attacks by pinning certificates in application code.

Certificates are stored in various formats such as PEM, DER, CRT, CER, PFX, P12, and P7B for different uses.

OpenSSL is a utility used in Linux for generating and managing certificates.

The video provides a comprehensive overview of digital certificates, essential for understanding cybersecurity and preparing for exams.

Transcripts

[Music]

foreign

[Music]

now I did talk about a lot of stuff in

the previous video and there's no way

you can talk about certificates and

public keys and signatures and so on

without mentioning public key

infrastructure because that's the actual

infrastructure that allows us to

validate the identity within a digital

certificate because anyone can generate

a digital certificate at the end of the

day is just a public key and in a file

anyone can generate that content but

it's all about who is able to vouch for

us for our identity so that when we use

that digital certificate when we present

it to somebody else they can be sure and

they have a valid method of verifying

the information in that certificate so

pki or public key infrastructure is the

the network and all the elements that

come into play whenever we want to

validate somebody's identity okay so to

have an actual working public

infrastructure this infrastructure that

helps us validate identities we need to

find a way to to connect the keys that

we're using for all this encryption and

signing business in a way to connect

these keys to our unique identities to

us as as people in the end so in order

to do this we're going to rely on the

concept of asymmetric cryptography based

on a private key and a public key so you

already know that you should keep the

private key safe only for you you should

already know that you can freely share

the public key with anyone out there and

you know that whatever one key encrypts

the other one can decrypt the same goes

for digital signatures as well because

even with digital signatures we're

encrypting hashes of our messages

so we know that these keys can be used

in encryption for example if I want to

send some encrypted information to you I

can request your public key through a

certificate for example and I can use

that public key to encrypt data that I

know that only you can decrypt with your

private key all right that's one use

case the Second Use case is when I want

to prove my identity to someone so I

need to do something with my private key

that I can then later on show that

something to another person and they

would be able to determine that indeed I

was the one that performed that

operation using my private key so it has

to be some piece of information that was

digitally encrypted or signed by me so

I'm going to authenticate myself using a

digital signature how do we do this well

we can watch the previous video about

this but long story short we're going to

take a message we're going to Hash that

message and we're going to encrypt it

with our private key now whoever

receives that message along with the

encrypted hash is able to decrypt the

hash validate the fact that the hash

matches with the content that they

receive and they can determine this way

that that piece of data actually came

from me because I'm the only person who

is able to sign it in such a way so that

my public key can be used to validate

its identity I am the only holder and

owner of my private key and another

benefit fit of this is that absolutely

anyone up there can use the same process

to validate your identity you don't need

to set up a secure Channel you don't

need to communicate any secure

information you just really give up

anyone your public key and if they are

able to decrypt your digital signature

or any kind of content encrypted by your

private key that's how your identity is

being proven now the problem we have

here is that well we keep saying that

you're sharing that public key with

anyone but but simply getting a hold of

somebody's public key or downloading the

public key from a website that says that

this is Andrew's public key that's not a

guarantee of an actual identity an

attacker could potentially intercept

those public keys while Alice sends her

key to blob and intercept that public

key and injects the attacker's key

instead of it so how do we protect

against this type of scenario well pki

addresses this exact problem the problem

of validating the information that we're

receiving related to a public key I'm

basically validating whatever comes

inside of a certificate so you can say

that pki is a way of validating the

ownership of a public key because a

public key can be freely distributed and

downloaded

but we need to know it's the right

public key and the way apki is

implemented is by using digital

certificates which is just a wrapper

just a container for a public key now

that container actually includes a lot

more Fields than just the public key it

includes some information that uniquely

identifies you as a person your your

name your country maybe the scenarios in

which that certificate can be used for

like for digital signatures or for

encrypting files and so on and the most

important part about the certificate is

that it has to be vowed by somebody else

it has to be

confirmed by an higher level Authority a

certification Authority that the

contents of that digital certificate are

real valid and true so what we do in

order to validate this well we ask a

certificate Authority that everybody

trusts to sign our own digital

certificate and how does the ca actually

sign our certificate well the the same

way we sign anything with a digital

signature right the ca calculates a hash

of our certificate and then encrypts it

with the ca's private key now everyone

else on the internet whoever receives

our certificate sees the digital

signature in it can freely download or

they most likely already have the public

key of the well-known Cas out there they

use the public key to decrypted Hash

they validate the hash they validate the

signature and they know that the

contents in that certificate that state

that this is Andrew and this is his

public key are to be trusted and of

course the cas must be trusted by anyone

because if you don't trust the ca then

you're back to square one how do I trust

that I am Andrew or how do I trust that

the this is very sign the ca that I'm

supposed to trust it's the same problem

I mean you have to trust at some point

in order to create this hierarchy of

trust from that point on and if the ca

is trusted then we can use this

probability to validate the certificate

and then trust the identity of the one

person that is actually mentioned in

that certificate as well so that proves

that my certificate is a valid one

now as you mentioned in a previous video

most operating systems and browsers out

there have a built-in list of trusted

Cas so everything that comes signed by

those trusted Cas you know even in a

deeper level hierarchy I mean you could

have a certificate that is uh signed by

one CA and then that's the a certificate

is signed by another CA and so on and so

forth well at the end of that hierarchy

there has to be a CA that you trust in

your browser in your operating system so

this is a screenshot right here shows

the list of trusted root certification

authorities as you can see here on the

left hand side which are built into in

my installation of windows in the

previous video we saw that there's a

separate list maintained for example for

each and every browser out there for

example Firefox Chrome Opera and so on

now a CA is responsible for generating

digital signatures which actually end up

as being valid certificates but again

anyone can do this right it's basically

just a piece of software that generates

digital signatures you can install a

certificate Authority locally on your

own laptop if you wish in fact in many

companies we do have local certification

authorities which are local to the

Enterprise to the network inside of that

company only which means that we can

actually have our own little island of

trust so that everything that is signed

by a local CA inside of our network is

automatically trusted now of course if

we try to sign any resources that need

to be checked or validated outside of

our local network like over the Internet

that signature that digital signature is

not going to pass validation but within

a company if everybody is configured to

trust the the ca that is local to that

company that is locally installed in in

the company's data center than any other

certificates that we're generating using

that CA in any certificates that we're

we're signing using that CA are going to

be automatically trusted but if you go

outside in the wild wild internet you

want to communicate from one company to

the next then you have to rely on some

public CA out there the one that is

trusted and recognized by everyone else

now the ca actually does a bit more than

just generating digital signatures

normally in the process of generating a

certificate that has to be some sort of

a validation process because I I could

be submitting a certificate for for it

to be signed to to very sign and they

should probably ask me for some proof

like providing some sort of ID that

proves that I'm actually Andrew then

that is actually my name or that I

really own the website for which I'm

trying to get my certificate signed so

there has to be some sort of a

registration process where you have to

pass some checks in order for your

certificate to be generated now the CEO

isn't by themselves are not just

isolated Islands out there on the

internet we usually have a hierarchy of

CAS in which all these Cas are related

to one another in a hierarchy of trust

so to start with the simplest example

out there from a single CA just one

single CA now you could have one single

CA generating all your certificates and

that's it now the problem is that the ca

of course is going to be exposed

vulnerable because everyone interacts

with it and potentially open to exploit

and compromise and if a CA gets

compromised if the private key of A CA

gets compromised the rule says that

every certificate ever generated by that

CA becomes invalid that's because if the

private key has been compromised then

the private key now could be in the

hands of somebody else who is using that

private key to generate

fake certificates or certificates that

don't include real information so we

lose that trust that we should have had

from the very beginning in that CA

we don't know which certificates are now

valid generated by that CA and which

certificates are not valid so we

invalidate them all the moment the

private key gets compromised so we call

this a single point of failure right one

CA doesn't sound like a very good idea

so we have the second scenario where we

rely on a hierarchy of CAS so we have

multiple Cas each one signing the

certificates of those below them which

creates a hierarchy in which we have

root Cas we have intermediate Cas and

then we have Leaf Cas at the end of this

hierarchic tree now this model creates

what is called as certificate chaining

or a chain of trust that is because each

and every certificate that is generated

by a leaf CA can be traced back to its

parent in the hierarchy of trust up to

the root CA that actually signed all

those intermediate and leave cas

why do we need to over complicate this

so I mean what's the benefit instead of

having just the one single Routier well

the benefit is that by Distributing this

infrastructure this way at some point we

can safely take the root CA completely

offline

I mean we don't want to keep it online

and exposed and open to attacks because

otherwise it becomes the same single

point of figure that we had with just

one CA so once we have instantiated the

intermediate and leave Cas that are

actually going to deal with the

certificate generation process for us we

can safely bring the root CA offline and

completely disconnect it from the

network that way we can be close to 100

sure that the private key of that CA is

never going to be compromised even more

so if at some point it just happens that

one of the leaf Cas gets compromised

well we're not going to be losing the

all the certificates that were generated

within that pki we're just invalidating

the certificates generated by that

specific leave CA not by all the other

ones

and you can easily view this even in

Windows if you open the certificate

store and navigate to one of the

well-known root certificates out there

or just select one of the certificates

that you're using for a specific website

you gotta find a tab in there that says

certification path in this case right

here we actually have two additional Cas

so one root CA and one leaf CA the

GoDaddy root certificate Authority and

the GoDaddy secure certificate Authority

which in turn has actually signed the

comptia.org certificate that you're

you're receiving whenever you're

visiting the the CompTIA website and as

far as the route goes as we said before

we can safely take it offline because

we're we're only using your root CA to

create other

sub ca's other intermediariess other

leaves yeah so we're not signing end

user certificates we are just empowering

other Cas to do this for us so once

you've generated you've generated the

the certificates you've signed the

certificates of all your necessary Cas

you can safely bring it offline now the

process of registration when it comes to

Cas is basically a process of

authentication over the process of

creating an account with that CA so that

your identity is validated and then you

gain the rights of requesting further

certificates for example once I have

proven my identity as I am Andrew right

to to my favorite CA I can then ask that

CA well give me a certificate for email

signatures give me one for a web server

that I own give me one for disk

encryption and so on so that's the

registration part it's the identity

checks I wouldn't say background checks

actually but it's a it's a sort of

validating the the true identity of the

entity that is requesting that

certificate for example in case of the

people who are want to use a digital

certificate to sign their email you

might be required to present some sort

of an identification like a government

issued idea or in case of a website if

you want to secure your website to allow

clients to connect over https and you

want to install a certificate on that

website you have to prove ownership of

that website by publishing something in

the DNS domain or by sending an email

from the domain that has the same name

as the website and anyway you have to

prove that you're an admin and you are

authorized to request a certificate for

that specific domain

there can be even simpler situations

such as in Microsoft Windows Active

Directory there are policies in active

directory which allow users to generate

a certificate simply by authenticating

themselves inside of the domain so once

you you authenticate using a username

and a password or a smart card or

whatever you're using to log into

Windows once you're authenticated in the

domain you can freely request as many

certificates as you want for example for

a BitLocker or disk encryption

but the official method by which any

person can receive a certificate from a

CA is by filling in a form basically

that could be digital form of course

which is called a CSR that's a

certificate signing request I'm

requesting you you my Dr CA to sign the

certificate for me that's a CSR now in

digital form don't imagine it's a it's

not a PDF file or anything like that

it's basically an ASCII file it's an

ASCII string of characters encoded

actually in base64. and that file

includes all the information that I want

to end up with in my resulting

certificate such as my identity my name

maybe the domain names that I want to

cover if it's a web server certificate

and of course my public key

and that's the information that the ca

actually has to validate before actually

emitting that certificate the

information submitted in the CSR now

again in some cases simply because the

this process of generating and receiving

csrs creates the ca to be extremely

exposed because it constantly receives

input information from from outside

users the process of managing csrs is

sometimes outsourced to a different

entity which is called a registration

Authority this one is also part of the

pki but it's a separate server separate

entity that only deals with receiving

and validating csrs they don't actually

emit the end user certificates but they

do give a verdict as whether the CSR is

valid or not so finally if we pass all

those checks we end up with a digital

certificates received from the CA and

signed by that CA so it's basically just

a container for your public key with

some additional information that

identifies you as a person or as a

machine as web server as an email server

depending on the use case for that

specific certificate generally

certificates nowadays are based on the

x509 ietf standard remember that one but

there is also an additional set of

Standards created by RSA you have the

same name as the algorithm which is pkcs

a very generic name that stands for

public key cryptography standards

standards themselves Define What fields

are allowed within a certificate where

they should be positioned what data type

is accepted in there and the use case is

acceptable by each certificate type

now among the information that is

available within a certificate we're

going to find a serial number this is

just a unique number that uniquely

identifies the certificate very useful

when we want to check the validity of a

specific certificate or when we want to

revoke it from the ca so the ca can

actually publish a list or respond to

some requests that are going to say that

this specific list of serial numbers or

this specific list of certificates

basically are not valid anymore have

been retired we also have the signature

algorithm of the ca the algorithm that

was used to sign that certificate why do

we need this well we need to know the

signature algorithm so that we can check

that signature right we need to

calculate the hash on our own so that we

can have something to compare it with so

we need to know the algorithm that was

used from the very beginning

specifically we need to know the

signature hash algorithm as well we're

going to find the issuer in there that's

basically the name of the ca who signed

that certificate or who issued the

certificate we're going to see a Time

range described as a valid 2 and valid

from fields which indicates the period

of time in which the certificate is

valid all certificates out there have an

expiration date

we also get this subject that is the

entity that the certificate represents

it might be your name it might be your

email address if you're using for email

signing it might be part of the web

server fully qualified domain name if

you plan on using it in a network device

of course we get the public key because

we're basically talking about a wrapper

for the public key so it has to be in

there somewhere and some more extensions

couple of them will be covered in the in

the next sections

so going back to the topic of that

subject because that's the identifier of

the actual person or entity or server

that is using that certificate we have a

number of ways in which we can describe

that subject information first of all we

had had with an emphasis on the past

time here CN that's common name usually

this one was designed to be the fully

qualified domain name of the of the

website or of the server that

certificate is supposed to belong to now

since the CN actually did not specify an

exact syntax that is to be followed it

is nowadays deprecated because some

browsers some validation entities had

some problems in uh in double checking

this field and actually figuring out

which entities the certificate belongs

to so nowadays it was replaced with

something called Sam subject alternative

names and now the name itself might

suggest that a San is uh is just an

alternative to

to the actual subject no it's just

basically a list of all the subjects

covered by the certificate itself

in the example here on the slide we can

see a certificate from CompTIA which has

a subject section that uses the CN field

you can see here it's

cnlearn.comti.org now on the other hand

we have a certificate from cisco.com you

get the certificate if you access

cisco.com in your browser and there's a

section of subject alternative names

and you can see here it's an actual list

of alternative domain names that this

certificate can protect so if you visit

any of the Cisco www.cisco.com media

files score static Cisco the websites or

the browser visits them in the

background then it's going to use them

and validate those destinations by using

this same certificate now from a more

practical point of view listing all the

domains in here just like Cisco did is a

bit more secure but in reality you're

going to find wild card notations in

here like

star.cisco.com something like that which

implies that any subdomain that belongs

to that parent domain is going to be

protected by that certificate not all

certificates are equal that is not all

certificates have the same type the type

actually refers to the key usage what

can that certificate be used for could

we use it for signing emails for

encrypting files for encrypted disk and

so on and so forth and these user

scenarios are described in the key usage

field as part of the certificate itself

and of course since the contents of the

certificate are digitally signed by the

ca

so are validated first by the CA and

then the digital signature is applied in

there you cannot just freely change this

use cases for a specific certificate if

a certificate was generated only for

email signing then you will not be able

to use that certificate for disk

encryption

alternatively we can find a field called

extended key usage or the way Microsoft

likes to call it if you open up a

certificate in Windows is enhanced key

usage which is just another way a more

flexible way of defining use cases for

the certificate but the end result is

pretty much the same

so among the use case examples that we

can select inside of this key use it or

extended key usage field are server

authentication client authentication can

use this for code signing that's the

same type of certificate by the way that

is used when you're downloading and

validating applications downloaded from

an official app store on your mobile

device that's also going to be validated

using some sort of a code signing

certificate and email protection now you

can see that we have a couple more

extensions apart from these standard

fields that we find in the certificate

now of course these extensions can be or

might not be recognized by all the

clients and all the software out there

which brings us to the discussion about

critical and non-critical extensions in

a certificate if an extension is tagged

as critical then the application that

processes the certificate that uses it

in any way must be able to recognize

that extension if the application

doesn't recognize the extension maybe

it's an optional one it shouldn't use

the certificate at all it should reject

it completely and you can probably guess

what non-critical extension means well

it's a non-critical extension even if

the application doesn't recognize that

specific extension it's still going to

use the rest of the fields in the

certificate and the way the application

was programmed to use that certificate

even if it doesn't understand its

contents 100 percent

now when it comes to websites the

certificate that the website presents to

all its clients to all their browsers is

basically a proof of the website's

identity which is very important if

you're interacting with a with an

e-commerce site or with a banking site

or with any site that requires you

provide some sensitive data personally

identified or confidential information

so you need to validate the identity of

the entity that you're talking to that

you're actually communicating with

you're giving your credit card details

to Amazon and not to I don't know Amazon

with double o's at the ends.com

and that's a real problem actually there

are situations where anybody can just

set up a new domain name and perhaps

even submit a certificate signing

request for that new domain name such as

amazon.com to a real CA trusted by

anyone and they would get a valid

certificate for that website which then

they can use to impersonate amazon.com

and steal credit card data so we have

different levels of security involved

whenever the checks are being performed

before actually emitting web server

certificates from publicly trusted cas

and the way we can Implement these

checks we have two methods we have

domain validation which is a very simple

check which uh just proves that you're

the owner of the domain that you're

trying to register a certificate for it

might require you to fill in some DNS

records temporarily that can be publicly

checked by the ca or by the ra the

registration Authority or you might be

required to send an email from the

domain name with the same name as the

the website you're trying to register

the certificate for now for a higher

profile websites there's also an

additional more complex process called

extended validation which checks the

legal ownership the legal identity of

the owner of that of that resource that

we're trying to create a certificate for

and we avoid situations such as those

that are trying or attempting to create

valid certificates for spoofed or or

phishing domains

now the other certificate types that

you're going to encounter because users

and websites are not the only ones that

need certificates we're going to start

with users all right we can generate

certificates for users for them to be

able to use them for email signing or

for this encryption we can also generate

certificates for servers and

applications we can use those

certificates to prove the identity of

the server or the application that is

being accessed you can also use

certificates to sign code files and

applications and we can also have

self-site certificates because nobody

stops you from generating a certificate

that you are signing by yourself this

comes back to the discussion about the

napkin one or two videos ago I mean it's

nobody's going to trust it right

nobody's going to be able to validate it

but it is still a true and correct

certificate now the self-signed

certificates are usually the ones that

get installed in internal networks in

lab environments in demo environments

and pocs and those are the situations

where we get that warning in the browser

that says the certificate is not trusted

well it's not trusted because the

signature on that certificate is the

signature of somebody that we can cannot

validate its identity we don't know who

that is all right I can sign my own

certificates are you going to trust me

no because that's the point of all the

process right to trust my identity to

find another method of validating my

identity my signature means nothing you

need a CA for that also keep in mind

that in many cases the authentication

process for example gaining access to a

network can be performed at two

different levels we can validate the

identity of the user or the admin that

is trying to access the network and we

can also validate the identity of the

machine that the user or the admin is

trying to connect to the network so we

can have two levels in there

authenticate user and also the laptop

that is trying to gain access to the

network that's why they also have

machine certificates and user

certificates ever found yourself in a

situation where if you're using a

company laptop you can easily plug

anything red cable into it and gain

instant access to the local network

while if you bring your own laptop from

home you're not getting any kind of

access well that's because that laptop

in there has some sort of authentication

information built into it most likely a

certificate that it presents as a

machine certificate and authenticates

itself to the access control system that

allows access to the rest of your

network your home laptop doesn't have

that certificate doesn't have a valid

identity that it can present so it is

denied access

so a certificate is going to go through

a number of stages during its lifetime

starting with the creation of the keying

material that is the creation of the

private key and the public key right

we're using just a public key to grade a

certificate but we need a private key as

well because the public key is derived

from the private key not the other way

around you should know this by now

then we move on to the certificate

creation that is filling in that CSR

sending the CSR and receiving a valid

certificate from the ca certificate

storage is important not necessarily

from a security perspective but more

from a usability perspective you need to

store that certificate load it into a

certificate store where it can be

accessed by any applications that need

to use it to validate someone's identity

now on the other hand you should store

in a very secure manner the private key

that was used to generate that

certificate and finally we have

revocation of that certificate or

putting the certificate out of business

it might be because the certificate has

expired or it might be because the

private key has been compromised in any

situation a certificate can always be

renewed now if the private key has been

compromised you're probably gonna want

to use a new key and generate a new

public key pair for the new certificate

but if the certificate just happened to

expire because it reached its end of

life its expiration date you can will

reuse the same keying material you don't

need to generate a new key and keep in

mind that all certificates expire at

some point there is always going to be

an expiration date on certificates

now in general storing secure Keys is a

big problem in security because if you

back up the key just to say you're

you're storing it in multiple versions

just to make sure that you're not going

to lose it it exponentially increases

the risk of that Key's exposure on the

other hand if you don't have a backup

for the key then the place you're

actually storing that key becomes a

single point of failure which can cause

in case of failure your inability to

ever access your encrypted data so there

have been invented some processes for

dealing with this type of key recovery

in which we're trying to store the

private key somewhere but in a as secure

manner as possible for example we we

store its segmented into a different

number of storage devices or we need a

specific number like two or three admins

with access at the same time in order to

recover all the pieces and and build

that key back again then we're using all

these security measures to avoid any

kind of collusion or exploitation that

might happen against that key storage

system now key escrow is kind of similar

but it refers from a legal standpoint to

the practice of giving that key to some

third party for the purpose of safe

storage if you don't want to invest in

some Secure Storage infrastructure for

your keys you can pay a third-party

company to do that for you now of course

the liability that comes from a

potential keep compromise can be

transferred as a risk to that

third-party company but don't forget

that even if they are the ones now

responsible for the security of the key

any side effects that might occur from

that key being compromised are going to

hit back your own company and your own

reputation

and we talked about the fact that all

certificates expire at some point

normally these certificates that are

generated for end users have a shorter

lifespan maybe a couple of months maybe

even 30 days maybe even one year or so

but real certificates are usually

created for a longer period of time such

as one three five ten years or so now

generally when a certificate expires

there's a very simple procedure to just

renew it and in case of CAS or

registration authorities the process

itself if the user already has a valid

certificate if the user wants to just

renew it the process is going to be much

more smooth so not so many checks are

going to be performed if the user is

already holding a valid certificate

now certificate can also be revoked that

is manually and explicitly taken out of

commission so it's a process where we

suddenly decide that these certificates

are not going to be valid anymore maybe

the company went out of business the

company doesn't exist anymore maybe the

uh the private Keys has been compromised

maybe the servers that were storing them

are have been the victim of a data

breach and we don't know exactly how

much data was lost in there but we

decide to to revoke all those

certificates how can we do this well

there are two methods for doing this the

first one relies on the actual CA and

the ca can inform the end users what are

the revoked certificates that it manages

and that's called a certificate

revocation list crl now the way this

works is that when clients attempt to

validate a certificate with a CA well

they grab the public key of that CA they

decrypt the signature and so on so forth

but they also should check the serial

number of the ca to see whether it is

found in one of the crls that they can

download from the from the ca of course

this is up to the client if they perform

this additional check or not

which means that certain clients might

not perform this check at all and other

clients might perform this check maybe

once a day once a week or so when they

just download those crls and then they

don't update them until let's say a

number of days have passed it also might

happen that the cas don't update those

crls immediately for everybody else to

download so revoking a certificate might

not happen instantaneously we have

another method of providing the

certificate expiration revocation list

dynamically to our users and that is

based on the ocsp online certification

status protocol now this instead of

downloading an entire list of serial

numbers of expired certificates or

revoke certificates we're simply relying

on a type of request reply protocol

where we simply send a query about a

specific serial number and then we'll

receive a response based on that serial

number telling us whether the

certificate is still valid or not now of

course it depends on the server

implementation how they're performing

this type of query processing so some

servers might be acquiring the database

of certificates directly others might be

querying the crl list so in case the

serial list is a bit behind or up to

date then ocsp is also going to provide

a less than ideal or less than

up-to-date answer and since this entire

process of request reply request reply

puts a lot of stress on the actual CA

server we can actually delegate the web

server that we're trying to access to

respond on behalf of the ca with these

ocsp status responses how does this work

well the web server obtains from the ca

a timestamped response which then in

turn it can use to provide as an answer

to any request that might come into the

web server in order to validate its

certificates so it doesn't have to go

back and forth to the ca every single

time somebody validates that certificate

asks the ca once receives a signed

response and then shows everyone this is

the signed response from the ca stating

that my certificate is still valid trust

this one and this process is called

ocasb stapling

there's another problem here that we can

address and that is a problem of another

man in the middle type of attack because

theoretically at least when you're

accessing a site such as google.com

you're performing a certificate exchange

you're requesting the certificate from

Google in order to validate it now what

if somebody in the middle of that

conversation intercepts that certificate

and injects their own certificate

signed certificate trusted certificate

what are you going to do with that

certificate well you're going to accept

it and you're going to think that Google

certificate is the one that you just

received and then what you're going to

do well you're going to send your

authentication data you're going to send

your emails you're going to upload your

files

you're going to perform all your tasks

and you're going to encrypt those with

the public key that came

from within that bogus certificate that

was just injected and of course all that

information now can be safely inspected

and snooped by the attacker that

injected that certificate

so in order to avoid this situation we

have something called certificate

pinning or hbkp

which stands for HTTP public key pinning

which is just a method of embedding the

information in the original certificate

in the actual Google certificate

somewhere within the application code so

somewhere within the the web page code

of Gmail for example there's going to be

the contents of Google certificate now

the browser of course has to know to

look for this has to be configured to

understand hpkp so if it finds a set of

information that describes the

certificate within the application code

then it can compare it with the actual

certificate that it received now if the

certificate has been tampered with and

has been injected by a foreign attacker

then of course they're not going to

match so that's how the browser can

detect an attempt for a man-in-the-mill

attack and unfortunately it doesn't

always happen for a malicious purpose

this type of man in the middle

interception because in many companies

you have dedicated firewalls Next

Generation firewalls especially that

perform SSL decryption in order to

inspect the web traffic that the

employees are sending back and forth in

order to block them from accessing

unwanted websites in order to block them

from downloading malware from unwanted

destinations and so on but every pretty

much all the web traffic nowadays is

encrypted so you have to perform SSL

decryption on the traffic before you can

actually look at the traffic which means

that you'll have to replace the

certificate that the user is actually

expecting to come from Google with your

own self-signed certificate or some

internal company certificate which is

basically just the same example as

before it's performing a man in the

middle attack now if that website uses

hpkp or certificate pinning that man in

the middle approach is not going to work

anymore it doesn't matter if it's

performed in a legitimate manner or by

an attacker so that was one of the

reasons why at some point hpkp

implementation started to back off just

a bit because they were creating a lot

of issues with legitimate company

approved and an employee approved

traffic inspection that's happening all

over the the Enterprise world

okay so how do you store certificates

well at the end of the day don't forget

that a certificate is nothing more than

a simple file so we store it as a file

on the disk with a certain extension

perhaps to help you recognize them

easier now one of the first types is a

binary format with the Der extension

you're not going to find these very

often the one that you will find more

often are the pem extension files these

are certificates stored in ASCII format

which means that they're easily

selectable copy and pasteable you can

attach them to email you can even paste

them inside of an email if you wish and

you can paste them in a in a web

interface for an API access for example

so they're much easier to you know to

move from one place to another

and the screenshot right here on the

slide shows you the contents of a PM

format certificate now don't expect to

be able to read the contents by yourself

because it's a base64 encoding but

base64 is easily reversible in one of

the simplest thing coding methods out

there so you can immediately get to the

actual contents of the certificate and

you're also going to find certificates

using the extensions such as CRT or CER

which unfortunately don't happen to

agree on a specific format so they don't

tell you if it's binary or ASCII format

what's stored in there and we also have

some specific file extensions and file

types that can store more than one

certificate for example the pkcs trail

format allows us to bundle the private

key and the public key together in the

same certificate this is normally

atypical because a certificate is meant

to store only the public key right but

there are situations for example when

you need to move the private key along

with the public key from one machine to

another for example when you're

performing an upgrade you're replacing a

server your web server right and you

want to move the the certificate content

the cryptographic content from one

machine to the next you can export it as

a pfx or p12 format file and then import

it on the next machine

and it's also used for backup purposes

if you want to back up your private keys

and you want to store them somewhere

safe you can use the pfx format or p12

ideally you should also protect this

type of certificate format with a

password because it contains sensitive

information

and we also have the p7b format which

stores the entire certificate chain

sometimes a host that uses a certificate

or has to validate it doesn't have the

ability of dynamically downloading the

entire certificate chain in order to

validate the certificate it's CA this

the one the ca that signed that CA and

so on and so forth so it might help

especially for embedded devices small

devices to help them by providing the

entire certificate chain so that they

can use it to validate whatever

certificates have been generated by the

by the leaf CA in that chain

managing certificates depend on which

operating system you're using on Windows

all the certificate business is most

likely managed by active directory

and there are some command line tools

out there as well especially the search

util Windows utility that can help you

manually generate interact with or

validate digital certificates now in

Linux we very often use the open SSL

series of utilities

and you can use an open SSL for a number

of tasks for example you can even make

yourself ACA you can generate a

certificate signing request you can

generate an actual certificate you can

validate a certificate and so on and so

forth you get the ability to manage

everything related to certificates

on the example on the slide you can see

that we're generating an RSA type of

public-private key pair of 2048 bits

we're generating a certificate that is

going to have an expiration date of one

year and we are outputting it as a PM

format in the file called certificate.pm

now of course this is going to be a

self-signed certificate

also notice the information that is

required for you to provide before

actually generating this user

certificate

and for your reference here are some

basic open SSL commands that you can use

to generate and manage certificates by

default of course you can run these on a

Linux system but you can also get access

to openssl if you're running a Windows

subsystem for Linux on top of Windows 10

or 11. so starting with a generation of

an RSA key pair the first command is

going to generate the private key for

you while the second one as you can see

uses the private key as an input in

order to generate the public key

remember we talked about this we said

that the public key can be derived from

the private one but not the other way

around the length the 1496 at the end is

the length of the key and the AES 256

parameter in there indicates that we

intend to encrypt which is going to

require a passphrase from you as well

we're going to encrypt the private key

because that is truly sensitive

information moving forward you can also

use openssl to make yourself a CA and

start signing certificates for accepting

csrs certificate signing requests first

you need to generate the CSR on the

server for which you want to generate

the certificate for that's a command for

this one and then you assign the CSR on

your own CA

finally a couple of commands for viewing

and validating certificates generated by

you or generated by anyone else and

signed by any public CA out there right

so a lot of information here about

digital certificates I know it's not

light not easy to process but they're

everywhere nowadays we have to know

about them you have to know about them

for the exam as well so I really hope

you found this video informative and

useful if you want to discuss more leave

a comment and if you like this oh like

And subscribe and good luck on the exam

see you on the next video thank you and

bye bye

foreign

[Music]