Types of Certificates – CompTIA Security+ SY0-501 – 6.4

As a security professional, you’ll manage many different certificate types. In this video, you’ll learn about root certificates, SSL certificates, self-signed certs, and more.

<< Previous Video: PKI Concepts Next: Certificate File Formats >>

As a security professional, there are a number of different certificates that you’ll use every day for many different purposes. In this video, we’ll look at the many types of certificates.

The root certificate is the public certificate that’s assigned to your root certificate authority. Everything in your PKI infrastructure starts with this root certificate. It’s usually the root CA will then begin issuing other certificates. And very commonly, the root CA issuing intermediate CA certificates.

This is one of the most important certificates in your public key infrastructure. If someone gains access to the private key associated with this root CA, they would effectively be able to issue their own certificates for whatever reason they’d like.

There are a number of different kinds of certificates that can be assigned to web server for SSL encryption. One of the most common is a Domain Validation certificate, or DV. Usually the certificate authority is confirming that the person receiving the DV certificate has some control over the domain associated with the SSL certificate.

Another type of web server certificate is an Extended Validation certificate, or an EV certificate. In this case, the certificate authority is performing some additional checks of the person that is receiving the certificate. And if they pass those checks, they get a special EV certificate that has the green name of the organization that appears to anyone who connects to that web server over an encrypted channel.

You can also have web server certificates that support many different domains in exactly the same certificate. We call this a Subject Alternative Name certificate, or SAN. It’s an extension of the X.509 standard that allows you to put a subject alternative name extension. And then you can list out all of the DNS names that would be associated with this particular certificate. It’s very common to have a certificate that’s associated with the name of a server.

For example, I could have a certificate that’s associated with www.professormesser.com. But you can also create a wildcard domain certificate. Instead of specifying a particular hostname, you can create a certificate that will apply to all the names that happen to be associated with the domain. So it doesn’t matter what the name is of the server. It could be www.professormesser.com. But anything with the asterisk could be replaced. So it could be www1, it could be ftp, it could be web server, or anything else that I’d like to put as the name of that server that’s associated with professormesser.com.

When you purchase an SSL certificate for your web server from one of those certificate authorities that’s listed in your browser, you’re effectively purchasing a level of trust. But what if you have web servers that you’re creating inside of your business that are only used internally? In that case, there’s no need to pay an outside source for a certificate that can be trusted because everybody who’s part of your organization already trusts all of the servers that are inside of your network. In those cases, you would create your own certificate authority. And you would sign your own certificates that you would create.

You would usually install this trusted certificate authority certificate on all of your web servers and all of your workstations. That way, anyone who connects to one of your internal servers sees that it was signed by an internal CA. And that internal CA is already trusted by everyone’s web browser.

As an IT security professional, you’re responsible for allowing many different devices to communicate on your network. But many of these will be devices that you never even see. They may be connecting from another state or another country. So how can you truly authenticate a particular device? How can you trust that that device is really allowed to communicate on the inside of your network?

One way to do this would be to put a certificate on these devices that had been signed by your certificate authority. That means when someone tries to connect into your network with a VPN, you can check for that certificate. And if someone does not have a certificate that’s valid, or they don’t have a certificate at all, you can decide not to allow that particular device onto your network.

We could also assign certificates to individual users and take advantage of that during the authentication process. They may be asked for their username and password. And then they would slide the smart card into their computer so that the certificate could be read. And then we know that that is another authentication factor because that is something that the user has with them. This is something that’s commonly integrated into smart cards. But it could also be part of a digital access card either on a mobile device or built into the computer that someone may be using.

Another common form of certificates is use in email. We may need to encrypt information, send it securely to another individual. And it will be these email certificates that allow us to do that. This is usually using a recipient’s public key to encrypt the contents of that email, which means that the receiver of that email would be the only one who would be able to decrypt that email message. We also commonly use these certificates for digital signatures. Even if we’re not going to encrypt the contents, we could digitally sign that email so that when someone receives a copy of that email, they’ll know that nothing has changed since the time that email was digitally signed.

You might have also seen digital signatures used when you install a piece of software. This is a code signing certificate that’s used in this digital signature, where application developers can provide you with the level of trust by digitally signing the code that they distribute. This means as we are installing the software or executing the code, the developer’s signature will be checked. And we’ll see if anything has changed with that software since it was distributed by the developer. If the name of the developer doesn’t match what we were expecting or the digital signature itself does not validate because something has changed with the application, we can stop the execution of the app and contact the developer.