Certificates - CompTIA Security+ SY0-701 - 1.4

Summary

This script explores the concept and importance of digital certificates in IT security, emphasizing their role in establishing trust. It explains how digital certificates, signed by certificate authorities, authenticate identities and secure access to systems. The video delves into certificate creation, the validation process by authorities, and the use of both public and internal certificate authorities. It also covers certificate revocation methods, including CRL and OCSP stapling, highlighting the efficiency and security of modern web practices.

Takeaways

• 🔒 A digital certificate is a file that includes a public key and a digital signature, serving as a digital ID card with enhanced capabilities for authentication and trust.
• 🤝 Trust is a fundamental aspect of IT security, and digital certificates help establish trust by verifying the identity of users trying to access a system.
• 📜 Certificate Authorities (CAs) play a crucial role in the trust process by digitally signing certificates, vouching for the identity of the certificate holder.
• 🕸 The concept of a 'web of trust' allows for a decentralized trust model where individuals sign each other's certificates, creating a network of trust.
• 🏢 Organizations can establish their own internal CAs for issuing certificates within the organization, using tools like Microsoft Windows Domain Services.
• 🔒🌐 When visiting a secure website, the lock icon in the browser's address bar signifies a valid digital certificate, which can be inspected for details about the certificate and the issuing CA.
• 📑 The X.509 format is a standardized format for digital certificates, containing a wealth of information including serial number, version, signature algorithm, issuer, and holder details.
• 🌐 The 'Subject Alternative Name' in a certificate allows for a single certificate to be used across multiple domain names or services under the same domain.
• ⚠️ Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) are methods to manage and check the revocation status of certificates, ensuring ongoing trust.
• 🛡️ The validation process by a CA is critical for establishing trust in a certificate, as it confirms the identity and ownership of the certificate holder.
• 🔄 In the event of security vulnerabilities like Heartbleed, the ability to revoke and replace certificates quickly is essential to maintain trust and security.

Q & A

What is a digital certificate?

A digital certificate is a file that contains a public key and a digital signature, serving as a digital version of an identification card with capabilities beyond simple authentication, such as establishing trust in IT security.

Why is trust important in IT security?

Trust is crucial in IT security because it ensures that the person using a username and password is genuinely the one being granted access, thus maintaining the integrity and security of the system.

How does a digital certificate provide trust?

A digital certificate provides trust by being digitally signed by a Certificate Authority (CA), which vouches for the identity of the certificate holder, allowing others to trust the person or entity presented in the certificate.

What is a web of trust and how does it function?

A web of trust is a method where multiple individuals sign each other's certificates, creating a network of trust. If you trust a person who has signed a third party's certificate, you can also trust the third party.

Can organizations create their own digital certificates without a third-party CA?

Yes, organizations can create their own digital certificates using built-in certificate tools like Microsoft Windows Domain Services or third-party software, especially for certificates used internally.

What is the significance of the lock icon in a web browser's address bar?

The lock icon indicates a secure connection to a website. Clicking on it allows users to view the details of the certificate associated with the web server, ensuring the site's identity and security.

What is the X.509 format and why is it important?

The X.509 format is a standardized format for digital certificates. It is important because it allows for a consistent way to read and verify certificates across different websites and systems.

What information can be found in a digital certificate?

A digital certificate contains a serial number, version, signature algorithm, issuer's name, the certificate holder's name, the public key, and other relevant information.

What is a Certificate Signing Request (CSR) and why is it used?

A CSR is a request sent to a CA to create a digital certificate. It includes the requester's public key and identifying information, which the CA uses to validate and issue a signed certificate.

How does a Certificate Authority validate a certificate before signing it?

The CA goes through a validation process to confirm the identity of the certificate requester and ensure they are the legitimate owner of the website or server for which the certificate is being requested.

What is a Subject Alternative Name (SAN) and how does it work?

A SAN is a section in a certificate that lists additional domain names or identifiers for which the certificate is valid, such as wildcard certificates that can be used for multiple subdomains under the same domain.

What is a Certificate Revocation List (CRL) and why is it used?

A CRL is a list of all revoked certificates maintained by a CA. It is used to ensure that certificates that are no longer valid are not trusted, providing a way to revoke trust when necessary.

What is the Online Certificate Status Protocol (OCSP) and how does it improve certificate validation?

OCSP is a protocol that allows for real-time validation of a certificate's status, improving efficiency by eliminating the need to download a full CRL. It uses digital signatures by the CA to validate the certificate's status during the SSL handshake.

What is OCSP stapling and how does it work?

OCSP stapling is a process where the status of a certificate is embedded within the SSL handshake by the web server, using a digital signature from the CA to validate its status, streamlining the certificate validation process.

Outlines

00:00

🔒 Digital Certificates and Trust Establishment

This paragraph introduces digital certificates as files containing a public key and a digital signature, serving as a digital ID card with advanced capabilities. It emphasizes the importance of trust in IT security, especially when granting access to systems. Digital certificates help establish this trust, either through a centralized certificate authority (CA) or a web of trust where individuals sign each other's certificates. The paragraph also touches on the possibility of creating certificates within an organization using built-in tools like Microsoft Windows Domain Services or third-party software. It explains how digital certificates are used in web browsers to secure connections, indicated by a lock in the address bar, and how the X.509 format is a standard for these certificates. The information contained in digital certificates, such as serial number, version, signature algorithm, issuer, and holder's name, is highlighted, along with the role of a root of trust in establishing trust with unknown entities.

05:02

🛠️ Certificate Creation and Validation Process

The second paragraph delves into the process of obtaining a digital certificate for a web server. It clarifies that purchasing a certificate involves a validation process by the CA to ensure the requester's ownership of the website. The creation of a Certificate Signing Request (CSR) with public key and identifying information is discussed, followed by the CA's validation and digital signing of the certificate. The paragraph highlights the significance of the validation process in establishing trust. It also covers the concept of being one's own CA for internal applications and servers, with the installation of an internal CA's public certificate on all devices within an organization. The use of various software packages to create an internal CA is mentioned, along with the process for creating and distributing certificates using an internal CA. The paragraph concludes with the mention of the Subject Alternative Name in certificates, which allows a single certificate to be used for multiple domain names under the same domain.

10:04

♻️ Certificate Revocation and Efficient Trust Management

The final paragraph addresses the need for certificate revocation due to various reasons, such as decommissioning a server or security breaches like the Heartbleed vulnerability. It explains the Certificate Revocation List (CRL) as a record of revoked certificates maintained by the CA. The paragraph describes the process of revoking certificates during the OpenSSL update following the Heartbleed incident. It also introduces the Online Certificate Status Protocol (OCSP) as a more efficient method for checking certificate validity, with the concept of OCSP stapling, where the certificate status is embedded in the SSL handshake. The paragraph discusses the importance of having a method for revoking trust and the browser's role in checking the CRL distribution points and OCSP responses to ensure a certificate's validity before allowing access to a web server.

Keywords

💡Digital Certificate

A digital certificate is a digital file that contains a public key and a digital signature, serving as a digital identity card. It is essential for establishing trust in IT security, ensuring that the person using a username and password is indeed the intended individual. In the video, digital certificates are discussed as a means to provide trust through digital signatures by a Certificate Authority, which validates the identity of the certificate holder.

💡Certificate Authority (CA)

A Certificate Authority is a trusted entity that issues digital certificates. It validates the identity of the certificate holder and signs the certificate with its own digital signature. The script mentions that if a CA trusts a person, then others can also trust that person, highlighting the role of CAs in establishing trust in digital environments.

💡Trust

Trust is a fundamental concept in IT security, referring to the confidence in the identity of a person or entity. The video emphasizes the importance of trust when granting access to systems, and how digital certificates and CAs help establish this trust by vouching for the identity of users or websites.

💡Web of Trust

The Web of Trust is an alternative to a centralized CA model where individuals sign each other's certificates, creating a network of trust. The video script describes this as a method to provide trust without relying on a single CA, allowing trust to be established through a community of users who vouch for each other.

💡Microsoft Windows Domain Services

Microsoft Windows Domain Services is a feature within Microsoft Windows that provides certificate tools for creating an internal CA. The script mentions this as an option for organizations to manage their own digital certificates, which is particularly useful for internal networks and applications.

💡X.509 Format

X.509 is a standard format for digital certificates, ensuring compatibility and readability across different systems and browsers. The video script explains that this format includes detailed information about the certificate, such as the issuer, holder, and public key, and is universally recognized to facilitate secure communication.

💡Secure Sockets Layer (SSL)

SSL is a security protocol for establishing an encrypted link between a web server and a browser. The script mentions the lock in the address bar of a web browser, which indicates an SSL connection, and how clicking the lock allows users to view the certificate details, including the SSL certificate's role in secure communication.

💡Root of Trust

The Root of Trust is the foundation upon which trust in a system is built. It can be hardware, software, or firmware that inherently provides trust. The video script discusses how a browser uses a third-party CA as the root of trust to verify the authenticity of a website during the first visit.

💡Certificate Signing Request (CSR)

A Certificate Signing Request is a block of encoded text that contains information about the entity requesting a certificate. The script explains that a CSR is sent to a CA, which then validates the request and, if approved, issues a digital certificate, illustrating the process of obtaining a certificate from a CA.

💡Subject Alternative Name

The Subject Alternative Name is a field in an X.509 certificate that allows for additional domain names or identifiers to be associated with the certificate. The script uses the example of a wildcard certificate, where *.birdfeeder.live could cover multiple subdomains, demonstrating the flexibility and utility of the Subject Alternative Name in certificate management.

💡Certificate Revocation List (CRL)

A Certificate Revocation List is a record of all digital certificates that have been revoked by the issuing CA. The script describes the importance of CRLs in maintaining security, especially in situations like the Heartbleed vulnerability, where certificates need to be revoked and new ones issued.

💡Online Certificate Status Protocol (OCSP)

OCSP is a protocol used to check the revocation status of a certificate in real-time. The script explains OCSP stapling, where the status of a certificate is included in the SSL handshake, reducing the need for downloading a full CRL and making the process more efficient and secure.

Highlights

A digital certificate is a file containing a public key and a digital signature, serving as a digital version of an identification card with additional capabilities.

Digital certificates are essential for establishing trust in IT security, verifying the identity of users accessing a system.

Certificate Authorities (CAs) digitally sign certificates, transferring trust from the CA to the certificate holder.

A web of trust can be created through multiple individuals signing each other's certificates, decentralizing trust.

Organizations can create their own certificates using built-in tools like Microsoft Windows Domain Services or third-party software.

Secure connections in web browsers are indicated by a lock in the address bar, which provides access to the certificate details.

The X.509 format is the standardized format for digital certificates, recognized across different websites and browsers.

Digital certificates contain a wealth of information, including serial number, version, signature algorithm, issuer, holder's name, and public key.

The root of trust is a foundational concept in IT security, referring to a trusted third party that vouches for a site's authenticity.

When visiting a website for the first time, the browser relies on the root of trust to establish a connection's validity.

Certificate Authorities undergo a validation process to ensure the digital signature's recipient is the rightful owner of the website.

Internal applications and web servers can utilize an internal CA, streamlining the process of creating and trusting certificates within an organization.

Wildcard certificates, indicated by a Subject Alternative Name, allow a single certificate to be used for multiple domain names under the same domain.

Certificate Revocation Lists (CRLs) are used to maintain a list of revoked certificates, ensuring their trust is no longer valid.

The Heartbleed attack in 2014 highlighted the importance of revoking and updating certificates in response to vulnerabilities.

OCSP, or Online Certificate Status Protocol, provides a more efficient method for checking certificate revocation status without downloading a full CRL.

OCSP Stapling embeds the certificate status within the SSL handshake, validated by the CA's digital signature for trust.

Modern browsers support OCSP, allowing them to perform revocation checks during website visits, ensuring the validity of certificates.

Transcripts

A digital certificate is a file that contains both a public key

and a digital signature.

You can think of this as a digital version

of an identification card.

But in reality, it has so many more capabilities

than simply providing authentication.

One of the characteristics we're constantly

striving for in IT security is that of trust.

Whenever we're allowing someone access to a system,

we're trusting that the person using that username

and password really is the person that we'd

like to provide access.

A digital certificate is a way to provide that trust.

We can create a digital certificate,

have a certificate authority digitally sign that certificate

so that we know that if the certificate authority trusts

that person, then we should also trust that person as well.

There are other ways to provide trust

with digital certificates.

One of those methods is through the use of a web of trust.

Instead of having a centralized certificate authority,

we can have multiple individuals sign

each other's certificate, thereby creating

this web of trust.

If we trust our friend and our friend

has signed the digital certificate

of a third party, then therefore,

we can trust the third party as well.

But of course, you don't necessarily

need a third-party certificate authority to provide trust,

especially if you're just creating certificates

within your own organization.

In that case, you may want to use the certificate

tools that are built into Microsoft Windows Domain

Services.

And there are many other third-party software options

to provide your own certificate authority.

If you're in a web browser and you're connected securely

to a website, you'll notice there's

a lock in the address bar.

And if you click that lock, you'll

be able to see the details of the certificate associated

with that web server.

You'll notice that your browser is

able to show you the information about the certificate

for that web server regardless of what websites

you might be connected to.

That's because all of these different websites

are using a single certificate format that everyone can read.

The standard for that format is called an X.509 format.

And sometimes, you'll hear people

refer to the X.509 certificate.

And they're referring to the standardized format

for a digital certificate.

There is an amazing amount of information stored

in these digital certificates.

You have a serial number, a version,

and a signature algorithm.

You can see who issued the digital certificate, the name

of the holder of the digital certificate,

the public key, and other information as well.

In this video, we'll look at some of these characteristics

inside of this certificate.

And we'll talk about how we can use those to help better secure

our networks.

Having a method of creating trust between yourself

and someone trying to gain access to your systems

is a foundational part of IT security.

The real challenge, of course, is,

how do you trust something that up to this point

has been an unknown entity?

For example, when we use our browser

to visit a website for the very first time,

how does our browser know that we're

connecting to the right website and creates that trust

between you and that resource?

One way to provide this trust is to have a third party

vouch for the site that you're connecting to so

that if the third party trusts the site, then

therefore, I should be able to trust the site as well.

We often refer to this inherently trusted component

as the root of trust.

This might be provided through hardware or software.

Or there may be firmware or some other component that provides

trust for a particular system.

If we have a mobile phone or a website,

we may be using hardware security modules, Secure

Enclave, a certificate authority, or some other method

that provides us with some level of trust

for this particular system.

The method of trust that's built in to all of our browsers

is one that allows us to understand

if we're connecting to a website that can be trusted

or not trusted.

When you're connecting to a website for the very first

time, it would be great if we could get some feedback

on whether this site can be trusted

or whether it's untrusted.

So we'll use a trusted third party, an authority of sorts,

called a certificate authority.

The certificate authority is one that

digitally signs the certificates that

are stored on that website.

And your browser trusts the certificate authority.

So when you visit this website for the very first time,

you can view their certificate and see that their certificate

was digitally signed by a certificate authority

that your browser already trusts.

Therefore, you also will trust this third-party website.

This provides a real-time validation

that this website is one we can trust.

And it's this process that occurs to every website we

visit throughout our workday.

This process that a browser uses to trust a website

is built into the internals of the browser that you're using.

And if you look at the list of certificate authorities

that are trusted by your browser,

you will see there are hundreds of certificate

authorities listed.

This means the website can purchase a certificate from any

of these hundreds of certificate authorities,

put that digitally signed certificate

on their web server.

And as long as they're in the list of your browser,

they'll be trusted.

In this example, the certificate authority

is in charge of digitally signing this certificate

that you put on your website server.

But we're not really purchasing a digital signature.

When we purchase a certificate, we're

really purchasing the validation process

that a certificate authority goes through.

The certificate authority is going

to go through a series of verifications

to make sure that the person receiving

that digital signature is truly the owner

of that particular website.

That is the trust part that is built into this certificate

authority.

And it's how we can trust any of these websites

that we visit throughout the day.

Let's say that we would like to create a certificate

for our web server.

We'd like to send that certificate to a certificate

authority to be validated, have them digitally sign it,

and return that back to us.

The process to do this is relatively simple.

We would first create what is effectively

a digital certificate by using our public key,

add the identifying information about what

server this might be connected to

and information about our organization,

and combine those together to create a Certificate Signing

Request, or a CSR.

That CSR is sent to a certificate authority.

The certificate authority now does the validation process.

They confirm that the certificate that you're

asking for is one that is really for a web server

that you own and control.

And if they agree that this is a valid certificate,

they will use their private key to digitally sign

the certificate and send it back to you.

It's this middle part where the validation

is occurring that is so important

to this entire process.

If the certificate authority doesn't

provide this validation, then we can't

trust any of the certificates from that CA.

That's why this validation process is so important,

because that's where we get trust associated

with this digital certificate.

So far, we've been talking about using a public CA that

is built into everyone's browser in the world

to be able to provide trust.

But if you have your own internal applications

and your own internal web servers

and these will only be connected to by people inside

of your organization, then you can be your own certificate

authority.

For this to work, we would install our own certificate

authority software inside of our organization.

We would then take the public certificate

for that certificate authority, and we

would install it on everyone's computer

inside of our organization.

That way, everyone's machine would trust the certificate

authority we run internally, the same way that they

would trust a certificate authority that was external.

And you'll find that this is relatively common for medium-

to large-sized organizations that have

their own internal services.

They can create their own certificates

using an internal CA.

There are many software packages that

allow you to create your own certificate authority.

Microsoft has their Windows Certificate Services

that you see here.

There's OpenCA and many other third-party software packages.

So now we've created our own certificate authority

for everything that is internal to our organization.

And if we have an application or user that needs a certificate,

we don't have to go outside to a public CA.

We can simply use our internal CA

to create those certificates.

The process for creating a digital certificate,

having the certificate authority digitally sign

that certificate, and distributing it back

to the end user is exactly the same

as you would use with an external CA.

The only difference is we're using our internal CA

to provide the trust and provide digital signatures for all

of our certificates.

As long as you've installed your internal certificate authority

certificate to the trusted chain on all of your devices,

it works exactly the same as an external or public CA.

All of these devices will inherently

trust anything they're connecting

to because you've digitally signed

those with the internal CA.

If you're visiting a website in your browser

and you click the lock that is in the address bar,

you'll be able to see all of the details of that certificate.

And if you scroll through this web server certificate,

you may see a section called Subject Alternative Name.

Sometimes, we refer to this as a wildcard certificate

because it allows you to put the name of a domain

with an asterisk associated with the name of the device.

This means the certificate that we've created

can be used for any device that happens

to share that fully qualified domain

name listed in the Subject Alternative Name.

For example, in this certificate,

there are large number of DNS names that are listed.

One of these is birdfeeder.live, which

is one of my certificates.

And you can see it has an *.birdfeeder.live.

That means that this certificate could

be used for www.certificate.live,

ftp.certificate.live, mail.certificate.live,

and so on.

From an administration perspective,

this makes it very easy to create a single certificate

and distribute that certificate to a large number of devices

within your organization.

As long as that device is associated with that domain

name, this certificate will be valid for that service.

There may be times when we're decommissioning a web server,

and we would like that certificate

to no longer be valid.

Or maybe we're concerned that an attacker has gained access

to our certificates.

So we would like to revoke all of those certificates

and create some that are new.

One of the ways that we can provide this revocation

is through the use of a CRL, or a Certificate Revocation List.

This is a list of all of the certs that have been revoked.

And we keep this list on the certificate authority itself.

This administrative process of creating and then revoking

certificates is one that is built into any certificate

authority.

But there might be other reasons for providing some way

to revoke a certificate.

We found this out in April of 2014,

when we discovered an attack that

could have a web server provide a third party with the web

server's private key.

We refer to this attack as Heartbleed.

And it was due to a vulnerability in the OpenSSL

application library.

We had to revoke all of our certificates

and create brand-new certificates once this OpenSSL

code was updated.

All of our old certificates were moved to the certificate

revocation list.

And our newer certificates were then

installed into all of our web servers.

You can see how important it is to have

some method for revoking this trust which had previously

been installed onto a particular service.

You can find where this list of revoked certificates

happens to be by looking into the details

of your certificate.

If you click the lock on the address bar of your browser,

you can scroll through the certificate

and find a section that's called CRL Distribution Points.

This will include a list of URIs,

or Uniform Resource Identifiers, that are effectively

a link to the CRL file.

So this tends to be a multistep process.

Your browser connects to a third-party website.

That third-party website provides your browser

with its certificate.

Your browser then looks through the cert

to find the CRL distribution points

and then follows one of those URIs to download the CRL list.

From there, your browser can look through this list

and make sure that this certificate is not one

that's listed as being revoked.

As long as it's not in the list, you

can continue with your browsing session.

But if this certificate from this third-party website

is listed in this CRL, your browser

knows that is now a site that is not trusted.

This certificate is not valid.

And it will not allow you access to that web server.

As you can imagine, it's not very

efficient to have a single file that

lists out all the revocations for a certificate authority.

It would be great if we could have a more efficient process

that didn't involve us going to a third-party site

and downloading a big list of revocations.

Fortunately, we've created a protocol

that does exactly that.

This is OCSP, or the Online Certificate Status Protocol.

Relying on the certificate authority

to provide a list of all of these revocations

to anyone who might be visiting our website

is inherently inefficient.

To make this process more efficient,

we can put the status of our certificates

onto our web servers itself.

This is accomplished by sending status messages

about the validity of your certificate

during the SSL handshake that occurs when you first

connect to a web server.

This is referred to as OCSP stapling

because we're embedding the status of this certificate

within the handshake of this server.

We obviously can't trust a third-party web server

to truthfully tell us the status of the certificate.

So this OCSP protocol uses a digital signature by the CA

to validate its status.

Most browsers today support OCSP for the Online Certificate

Status Protocol, which means the browser itself can handle

all of the checks for revocation when you

visit a third-party website.

If you're not stapling the status into the handshake

message, you could use a third-party server

to provide the OCSP status information.

This is easily added to the certificate.

And it's much more efficient than downloading

an entire certificate revocation list from your CA.

If your organization is using very outdated browsers,

you may find that OCSP is not an option.

And even some of the newer browsers

say that they support using OCSP but unfortunately don't

implement the checks properly to be able to confirm

the status of a certificate.

Most modern browsers support OCSP.

But you might want to check your browser

and see that it really performs the validation when you connect

to a website so that you can tell what the status is

of those certificates.