Certificates – SY0-601 CompTIA Security+ : 3.9

We use digital certificates extensively for servers, users, and software. In this video, you’ll learn about using certificates for web servers, code signing, machines, email, and more.


In previous videos we talked a lot about what’s inside of a certificate but we haven’t talked about when you would use these, and in this video, we’ll look at the many uses for these digital certificates.

One of the most visible uses of these certificates, is a certificate that allows you to encrypt communication to a web server. This is usually indicated by a lock that’s in the address bar of your browser. We refer to these as domain validation certificates or DV certificates.

And this means that the owner of this certificate who’s added it to this website server, has some control over the domain that you’re connecting to. This provides the trust that when you’re connecting to a website, you really are connecting to the legitimate form of that particular website.

In the past, you may have also seen websites with an EV or an extended validation certificate, that ostensibly additional checks had been done by the certificate authority, and they’ve enabled additional features that would show the name of the certificate owner in the browser bar itself, and it’s marked in green in the browser bar as well.

These also usually meant that you paid a little bit extra for the extended validation certificate, but it made it very clear what websites you were connecting to. These days, the use of SSL has become normal if not expected on a website. So it’s not necessary to promote the fact that you’re running SSL on your server.

If you were to look at the attributes of a certificate, you’ll notice that one of those extensions is called a subject alternative name or SAN. This allows the owner of the certificate to add many different DNS names into this certificate configuration. And that means a single certificate could support connectivity for many, many different websites.

This is common to see on sites like cloudflare which is providing a reverse proxy service. So they’ll use a single certificate and that single certificate will support many, many different sites that are using cloudflare as a service.

One thing you may notice when looking through the subject alternative name fields, is that these certificates can support many different hosts by using a wild card. The wild card is designated with an asterisk, and you can see that the asterisk means that there can be many host names associated with this particular DNS.

For instance on this certificate, there is a domain birdfeeder.live and there is an asterisk.birdfeeder.live which means this certificate could support .birdfeeder.live ftp.birdfeeder.live ssl.birdfeeder.live or any other name that you would like to use, thanks to the wild card associated with this name in the certificate.

Another use of digital certificates, is often used when we are distributing software. A developer will create an executable or a piece of software that needs to be distributed, and then they will sign that software with a code signing certificate. This means that we can receive that software and install it and during the installation process, we can validate that the program that we’re installing is exactly the same executable as the one that was distributed by the manufacturer.

This lets us know that this software has not changed since the time it left the developer. If we’re installing the software and it fails this validation check, that we have the option to decide whether we’d like to continue with the software installation or whether we’d like to stop the installation and determine why this particular code signing certificate, did not properly validate.

If you’re building out a public key infrastructure, you’re starting with a certificate authority. And that certificate authority needs a starting point and that starting point is a root certificate. All of the signatures and additional certificate, authority certificates, are starting with this root certificate.

So if you’re building out an intermediate CA, and leaf CA is beyond that, you will start with this root certificate and sign everything downstream from there. This is obviously an incredibly important certificate, it is the foundation of your PKI and that means that you want to be sure that, that certificate remains safe.

If someone wants to gain access to this root certificate, they could effectively create any type of certificate for your organization, which is why there is so much emphasis put on the security of this root certificate.

We mentioned in an earlier video that you may not need to go outside of your organization to manage certificates, but instead build your own internal certificate authority. If you do that, you’ll be providing your own signatures to your internal certificates. And we often refer to these as self sign certificates.

This designates that we’ve created this certificate ourselves, we have signed it internally and distribute it to our internal devices. This also means that we didn’t go outside of our organization to have a third party validate this certificate.

This is very common to do, especially if you have a large number of servers and devices and you need to create many, many certificates. You can build them all out and self sign those certificates. But this also means that you have to tell all of those devices to trust your internal certificate authority.

If someone tries to use a device that doesn’t have that trust in place, a message will appear that say that the certificate is not trusted. That’s why it’s very common to distribute your CA certificates to all of your devices and that will ensure that your root CA, intermediate CA, and all of the other CA which you’re using are trusted internally.

As a system administrator, you may be deploying hundreds or thousands of devices throughout your organization. So it’s important that if a device is connecting to your network, that you’re able to tell if that device is a trusted device or not. One way to do this, is to deploy machine or computer certificates to all of the devices that need to be trusted by your organization. And if someone is connecting to the network and that device contains one of these certificates, that it must be trusted by your organization.

A good example of this might be if someone is connecting through the VPN, and before it gains access to the internal network. It provides an additional set of authentication to check for that certificate. And if that device validates properly, we know that, that machine is trusted by the rest of the organization.

If you’re sending or receiving email messages, you may have the option to enable encryption or digital signatures. If that’s the case, then you probably have an email certificate on your system. This email certificate uses public key cryptography to be able to encrypt information so that you can send it in a protected form through the internet. And it would also provide a way for you to receive encrypted messages and decrypt them locally in your email client.

These email certificates can also be used for digital signatures. We can sign any of these emails that we happen to be sending with this email certificate and the recipient of this email can validate that everything in this email is exactly the same as it was when it was sent and that provides the integrity. They can also validate that it was really us that sent the message providing non repudiation.

Your organization may also distribute user certificates to every single user. These can often be integrated into Identification cards and used as an additional form of authentication. Their card readers that you can connect to a system via USB or may be integrated into the device itself, and that can be used as that additional authentication factor.

This is often integrated into the smart cards that we’re using so this might be both a physical identification that might have your picture on it, and a digital access card that you can use when logging into your system.