Digital Certificates

There's still some things we haven't covered when it comes to digital certificates, like the fact that we can use them for things other than just public key infrastructure.

Other names for digital certificates

Digital certificates can go by different names, such as public key certificates and identity certificates.

The format of digital certificates

X.509 is a standard that defines how digital certificates are going to look, so it defines the format of the certificates, so that way there's some consistency when it comes to these digital certificates. Some of the things that are included in X.509, and specifically with version 3 of it, are the version number, the serial number, signature.

So let's jump onto that digital certificate for the TechKnowSurge website. I'll click on the lock, click on connection is secure, click on certificate is valid, and open it up. Then I can see a lot of information, like where this is validating, what site it's validating, where the validation is coming from — so Let's Encrypt — the issued on date and the expire date, the fingerprints that are associated with this, so I can do some verification, and also the hashing algorithm used, so I can actually go through the verification process of the certificate.

There's also this details tab that I can click, which gives me some additional information, like the hierarchy up here. So if I wanted to take a look at the TechKnowSurge certificate, I can look at it here, or maybe I want to take a look at the R3 or the root certificate. I can click on the root certificate, I can click on the version, and here again it's X.509 version 3, so that's the format that this is all following. So it has a lot of extra information in here: the subject's public key here, so here's the public key that's involved. So that's pretty cool, and some additional information around this particular certificate.

Wildcard certificates

There are different types of certificates, and specifically one of the types is a wildcard certificate.

Here I have a techknowsurge.com domain, and I have several resources on it. One is the main website, and I also have a courses website. These are different websites, and so they need different certificates, because the names are different. Even if they were hosted on the same server, they would need two different certificates because of the names — unless I created a wildcard certificate.

I could apply or submit a CSR for a wildcard certificate, in which case it has this little asterisk at the beginning, so it's *.techknowsurge.com. That says that I could have anything that's hosted through the techknowsurge.com domain, and I can use this certificate for it. What I'd have to do is, on each of these services, I'd have to use the same private key, because there's only going to be one public key that's associated with the certificate that's associated with this. So I'd put the same private key on both of these. It's going to have the same certificate that I'm going to use, and then I could use it for both of these domains here, both the www.techknowsurge.com and the courses.techknowsurge.com.

One of the downsides with a wildcard certificate is around security, and that is, you're putting the same private key on each of your servers, and you have the same certificate that you're handing out. So if one of these servers did get compromised and that private key was compromised, you would have to change the private and public keys and get a new certificate, and you'd have to go through that process, and you'd have to change all of your services to that.

On a similar note, if I'm hosting something on somebody else's site — as an example, let's say courses.techknowsurge.com is hosted through another site — I wouldn't want to hand over my certificate and the private key to them. The certificate doesn't really matter, because anybody can download that, but I wouldn't want to hand over my private key. So in that scenario right there, I may have a wildcard certificate for all my internal services, but anything that's hosted externally, I would get a separate certificate for hosting those services.

Self-signed certificates

There are also self-signed certificates. If you recall, certificates actually do two different things for us. Number one, they verify that the information that's coming into us is coming from the authentic source, but it also encrypts our data. So there are two advantages to having these certificates.

Sometimes we just want the advantage of encrypting our data, but we don't really care about verifying the entity on the other side. An example of this might be a switch. I might want to securely connect to a switch — I probably will want to securely connect to a switch. I want to encrypt the traffic between me and that switch, but I don't want to have to go through all of the process of generating a CSR, submitting that CSR, getting approval and verifying my domain, then downloading the certificate and then installing it on here, making sure there's connectivity. There's a lot to the public key infrastructure and setting everything up that way.

So what I might want to do is generate a self-signed certificate. If I generate a self-signed certificate, I can usually do it right on that piece of equipment. It will generate a certificate, and now when I connect to this device, what will happen is it will use that certificate to encrypt the traffic.

The drawback to a self-signed certificate is you're going to get some sort of error message, something saying that the connection isn't secure, or it's not verified, the source is not verified. It's going to come up with some sort of error message, and the only way that you're going to be able to get to it in modern browsers is to bypass that, or click on there and say I accept this risk, I am going to go to this site anyway.

Now, this becomes dangerous when it comes to end users. As administrators, you should know the difference: when you're connecting to a specific piece of hardware and you know what it is, then you can accept that risk and connect to it. But if you're allowing your end users to do that, then the problem is that you are going to train them to bypass those security measures, and we don't want to do that.

So when it comes to equipment that you're setting up, if you or your admin team are connecting to the server, it's probably okay to have a self-signed certificate. But if your end users are connecting to it, you shouldn't have them connecting to devices that are self-signed. That's going to give them that error message and train them to bypass that error message, and it's going to become dangerous when they encounter that in other sites and they're just going to bypass that, and that's not what you want to train them to do.

Expiring certificates

In most aspects of IT, we're going to want to think about the life cycle. Whether it's equipment, software or accounts, we need to think about the full life cycle of how do we create things securely, how do we manage them, and how do we end of life them. Certificates are no different: we need to be thinking about the end of life of these certificates.

One thing that may happen is that these certificates just expire. It's kind of a natural way of renewing these certificates and making sure that, if something was compromised, it has an end of life of where that compromise is going to be. Certificates usually expire after a year or so. So what could happen here is that, if you don't renew your certificate and your users are trying to get to your site and it expires, then they are going to get an error message, and a lot of your users are not going to bypass that error message. They shouldn't bypass that error message — once again, we don't want to train users to do that. And so now your site is going to be down, for the most part not really accessible, until you renew that certificate. So you have to make sure you think about the expiration date and make sure that's on your calendar, to go and renew those certificates before they expire.

Revoking certificates

Another issue that can come up is if a digital certificate is compromised. What that looks like is that it's actually the private key that gets compromised. If the private key gets out there, then somebody can mimic your domain, and you don't want that. Therefore the digital certificate is now compromised, and we need some sort of mechanism to be able to revoke these certificates if it's compromised before the expiration date.

Now, one interesting thing about the public key infrastructure and how it works is that this root certificate is actually on the machine already. The problem with that is, if this key was compromised — this private key right here, and therefore this certificate compromised — this machine still could do the check and validate that this certificate is okay, even though it's been compromised. And so we need a mechanism in place, a double check, some sort of check that happens to make sure that this certificate still should be valid.

The two ways that we can make sure that a certificate is not revoked are either using the certificate revocation list, the CRL, or the online certificate status protocol, the OCSP. These are the two mechanisms that we use to revoke certificates after they've already been verified.