- So how do privately trusted certificates really work? Well, it's a pretty straightforward process, actually. First let's talk about what privately trusted and self-signed really mean. All ROOT certificates are certificates that are signed by themselves. They don't have another source of authority that is higher up than they are. That doesn't make them untrustworthy just because they signed themselves, that seems like a circular kind of argument. But in fact, that is the way that all ROOT certificates work, even the ones out on the internet.
So in your private environment, once you stand up a certificate authority, you then can create your own signed certificates that'll be trusted by your people. That doesn't make them untrustworthy, it just means that you have to go around and install that ROOT certificate on all of the machines that you administer, all those computers. So, what's a ROOT CA? A ROOT CA is a top-level certificate authority. It has the authority to create certificates at the topmost hierarchical level of that organizational structure.
Its authenticity can't be revoked though, ever, by anybody. The authenticity of that ROOT certificate is extremely important, and it is important to protect those ROOT certificates, and that certificate authority. Because if it's ever destroyed, then every certificate that that certificate authority is responsible for, will become invalid, and will not be trusted by the chain up the chain to that ROOT certificate. So that's very, very important. If it's ever compromised, it must be destroyed.
It must be pulled out of the trusted chain. Apple, and other manufacturers have literally pulled the ROOT certificate out of what is delivered to customers because of problems like this, where the ROOT certificate has been compromised, and is no longer trustworthy. Makes every certificate signed by that certificate authority invalid. So you can be a certificate authority. And in fact, may organizations do this. Windows, Linux, Mac OS X, other major operating systems all have utilities within them that allow for the creation of a self-signed ROOT certificate, and allow for you to become a certificate authority.
So, this is really, really useful for you, right? Because you can establish trust by copying that around, as I explained before, to all of the computers in your organization. You don't have to work with an outside public certificate authority to depend upon trust. But even more importantly, on some private domains, you don't have a fully-qualified domain name that a publicly-trusted certificate authority would be able to verify. So you can't have SSL in that environment, unless you do it yourself.
Knowing how to create your own certificate authority, make your own ROOT certificates, make your own leaf and intermediate, and whatever other certificates you want to make for your organization, can be extremely useful in those environments. So as I said, your ROOT certificate is going to be at the top of this hierarchical chain. Your certificate authority can issue intermediate certificates, so that those other certificates will be chained through to your ROOT. And then leaf certificates that will be used by servers in your environment, so that they can encrypt and validate traffic between them and the client systems on your network that you're administering.
So how does this work? First thing you do is on a system you control, located on your network, you create a certificate authority. Then on that certificate authority, you create a certificate that will then be distributed to all of the computers on your network. Now, a stage in the middle of this can be that you create an intermediate certificate, so that your ROOT certificate doesn't have to be distributed. That's just fine too. Once you have this chain of trust up to the ROOT certificate, you can install either the intermediates or the ROOT certificates.
You can also install the final certificates on all of the client systems that you want to administer, or you want this trust to exist. You can copy those out manually. Certainly you can go around to all of the computers, and you can hand install them manually. If you're a smaller organization, there's nothing wrong with that. If you have five or 10 computers or devices that need these certificates, that may certainly be the faster way to get this job done. And I would fully support that. But, if you're in a larger organization, and you've got hundreds of thousands of computers that you need to do this with, it could be much more efficient to do this by placing the certificate trust into the master image on a computer you're imaging.
And we don't talk about imaging in this course, that's a subject for a different course. And in fact, here on Lynda.com, we have another class on how to do imaging of Macs across a network. I encourage you to go look at that. We also have courses on how to use management profiles. If you look at the Mac OS X server course here that we recorded in Mavericks for Server 3.0. We cover management profiles there. Those describe how you would put items like that into a deployment process, whether it be through management profiles or through imaging.
You can also script this process. You can send out a shell script to all of the systems that does an automatic installation of all of the certificates. Lots of options there. And of course, once the ROOT certificate, and if you have it in intermediate, and then the leaf certificates are on the systems that you administer, then all of the traffic will flow back and forth without generating any error messages for your users. And they will be able to use the certificates to secure traffic back and forth with your servers where those servers utilize SSL.
- 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.