Join Sean Colins for an in-depth discussion in this video How do public trusted certificates work?, part of Understanding Secure Sockets Layer.
- Let's talk about how publicly trusted certificates work. I'm also going to tell you how to go about getting them, because the process is a little more involved, of course, than just creating one for yourself. So let's talk about that now. Private root certificates are signed by themselves because there is no higher authority in their chain to sign them. Root certificates from a certificate authority, on the other hand, are also signed by themselves because there's no higher authority in their chain. So they're really, really similar. The difference is that a trusted internet certificate authority will rarely, if ever, deliver you a certificate that's signed directly by the private key from their root certificate, but instead will give you a certificate signed by their intermediate certificate.
That's mostly because the root certificate is very, very vulnerable and, if it were ever compromised, they would have to be removed from the trusted list of providers on all of the systems that are out there in the world, and that would be very, very bad. If their intermediate certificate's compromised, they just revoke it, using their root certificate, and issue a new one. They contact all their customers ... it's going to be a big pain for their customers, but it's not that they need to be eliminated from the world of secure transmissions, right? It's a much smaller deal than that would be.
So, basically, this whole concept of an intermediate certificate is about maintaining the integrity of their root certificate, which needs to be protected at all costs. Why are root certificates that are publicly trusted in the first place? Well, it's all about that assumption, that agreement, of trust that we just sort of take for granted. If you go out to the Apple store and you buy a MacBook Air and you bring it home, if you just open up the utilities folder and open up the Keychain Access application, you look into the system Keychain and you click on the certificates in the sidebar, you're going to see a long, long list of trusted certificates.
We'll show you that in another movie later on. All those certificates are root certificates. They are there because Apple said they should be. Apple decided these are the companies that are on the Internet that host SSL that need to be trusted. And so they are. So those are the vendors that you can go to and purchase with a certificate signing request. and you can purchase a certificate that's signed by them that will be automatically trusted when people go and use them. So that's what's going on. Because third-party root certificates are preinstalled virtually everywhere, the trust situation is no problem for you and your customers, which is just great.
So how do we get one? Well, we get a trusted certificate by first creating a self-signed certificate. And that process starts out very simply. On your server, you create a certificate ... very, very straightforward. Then, you go out to a CA like Verisign or Network Solutions or GoDaddy or Thawte or whoever, and you purchase an SSL certificate from them. Now, when you make that purchase, you're really just making a purchase, and you're sort of making a reservation for the opportunity to then use that purchase. You're not actually purchasing the physical certificate at that point, because you haven't requested it yet.
You then have to create a certificate signing request, and you do that using your self-signed certificate that you created back in the first step on this slide. Okay. You then submit your certificate signing request, or your CSR, to the certificate authority, or CA. The certificate authority then goes through this very -- hopefully -- secure process of figuring out if you are who you say you are. They go to the WHOIS database on the Internet for your DNS name and they say, "Okay, "so this DNS name is owned by this email address." So then they'll send an email out to the person whose email address is listed in the WHOIS record, and they will say, "Hey, we are so-and-so.
"We are being asked to submit a certificate "in your domain name. "Is that something that we're allowed to do?" And in a lot of cases, they will require a response back from that email address, so you'll have to be sure, before you make these requests, that the WHOIS information on the Internet is accurate and that the email address that's listed there goes to an actual person and that actual person knows that they're supposed to respond back and say, "Yes, this is all valid. "We're all good." Now, that how it goes today. In the old days -- by the old days, I only mean a few years back -- a certificate authority would call you on the phone.
They would look up the WHOIS record, they would find phone numbers, they would research your company name, they would do a Dunn & Bradstreet lookup, they would call you, interview you, grill you (chuckles) on, are you who you say you are, because they're putting their reputation on the line and, as a business, their entire certificate issuing business is based upon whether or not the people that they say are who they say they are, really are. And so this is something that has been automated now, for the most part. There's not a whole lot of people actually involved in validating identities.
And that's mostly because of the sheer volume of SSL certificates being requested nowadays. There's so much more going on on the Internet now than there was, say, 10, 15 years ago. Once that automated process has been completed, they verified your identity to the best of their ability, they then approve the certificate signing request and they apply their signature. Now remember, that signature is a signature that's generated using their private key, right? And they apply that signature to the certificate that they're going to send back to you. Then they notify you that they've signed your certificate, because remember, your CSR, your certificate signing request, included your self-signed certificate.
So they just took that same certificate, applied their signature with their private key, and they notify you that it's ready for download. Then the next step is, you go onto their site, you download the newly publicly-trusted signed certificate, and you install that certificate on your server. If necessary, you may need to download and install an intermediate certificate. That might be necessary to complete that chain of trust up to the CA's root certificate, which is already on your server. Now, installation of the certificate, that's going to be different on each type of system. So if you're a Windows server, or if you're on a Mac OS X server or a Linux server, that's going to be different from one to the next, right? But in general, you're going to have to do something to install the certificate on the server, whether that's to drag it into the ETC Certs file in a directory on your hard drive, or it's dragging it into the interface in a GUI, maybe in Mac OS X servers' server app, wherever it happens to be, you will be installing the certificate once you've got it.
And then, the final step is really just to configure the services that you're running on your server to use the certificate. If you get the certificate and you just install it on the hard drive, that doesn't really do much. It puts it there, but then it's not being used by the services. The whole point of all of this is, if you're running a web server, you need Apache to know where that certificate is and know that it's been configure to use it. If you've got a calendar server, you may need CalDAV to use it. If you're running some other service that is able to be secured by a certificate using SSL, you need to configure your service to use the SSL certificate you just got.
All right; so, in review: root certificates are preinstalled everywhere. Remember that. That's why the trust exists in the first place, whenever you're dealing with publicly trusted certificates. It's why third parties, why people who are complete strangers can communicate with your server and initiate that trusted communication. And remember, we trust these certificate authorities because we all have agreed to, because Apple and Google and Mozilla and whoever have all agreed that certain companies are trustworthy. But they're not intrinsically trustworthy. That trust can be eroded over time simply by having their root certificates compromised by a hacker at some point.
So we need to keep on top of this stuff and be sure that we know that the certificate authority that we're using, whether we are a administrator or as a user, is still valid. Most of that's taken care of for us by the operating system manufacturers. For example, Apple will remove a root certificate from the Keychain in a system update if it becomes compromised. So just keep that in mind. Same thing is true of Microsoft and everybody else. There's mathematically nothing different between the CA that you can create on your server -- we talked about that in a previous movie -- and a CA like Verisign and Network Solutions.
But functionally, the difference is enormous because, in the previous movie, we talked about how your CA and the root certificate can provide trust to the systems that you can administer, and especially on a private network, where there's a domain name that doesn't have records in the WHOIS database on the Internet, that's huge, right? Very important. But if you are a public domain name, and you do have a WHOIS record, and you do want people on the outside Internet to be able to go to your secured services without having to first be administered by you somehow, this is great.
This is exactly how shopping works. This is exactly how publicly available services work. So what makes Verisign and other like them trusted is, as I've said before, Apple, Mozilla, Microsoft, all these guys, they put these root certificates on every system that they distribute. Just remember that; it's very important.
- SSL communications
- Certificate authorities
- Public key infrastructures
- Symmetric and asymmetric key pairs
- Cryptographic hash functions
- Encryption algorithms
Start now, and by the end of this course you'll have the knowledge to create SSL certificates, as well as revoke and renew them, from the command line.