Join Sean Colins for an in-depth discussion in this video Root certificate authorities, part of Understanding Secure Sockets Layer.
- A root certificate authority is easily identified. I'm in Mac OS X, and in OS X, we have this terrific application, called Keychain Access, that gives us the ability to view the certificates, and even gives us some really handy ways to interact with our Certificate Assistant. We'll be showing some of that later on, pretty cool A lot of this can be also viewed via the command-line, using the OpenSSL command, but I find that this is a much more graphicly rich way to view these, and so understand that you can certainly use OpenSSL to do this, but on your system, in Linux or in Windows, you can also in Windows use Graphic Designer Interface II to view certificates there, this is just where we are.
So, I wanted to show you this list of Certificates. Here in Keychain Access, we have all certificates listed here under this certificates category, and anything in the system roots section here, in this Keychain is a system root, something installed by Apple, that they say should be trusted, and this is where we have all of those public root certificates that I was talking about in Chapter One, where you can get to pretty much anything, so let's take a look here at Network Solutions, so here's the Network Solutions Certificate Authority, I will double-click on that, and pull it up, and we will start to explore this certificate.
So the first thing I'd like to point out here, is we have the name of the certificate, in OS X, we get a very different looking graphic, for root certificates. See that certificate, it's all gold, and it says Root in red right below where it says certificate, all in nice pretty script. We see right away a very clear graphic indication that this certificate is valid. We know that it is a Root Certificate Authority, and that it expires on a specific date, okay. We can also flip down on this disclosure triangle, to see what the trust settings are, and when this certificate is used, it is defaulted out to the system defaults, which makes a lot of sense, okay.
Under our details, our subject name, we know where it came from, US. We know the organization name right there, and the common name. Those are all things that are set whenever you set up the Certificate Authority. They're included here in the certificate. So here below are issuer names, Information with the common name, organization, and country. Again, we have the certificate serial number, which will be unique to this certificate, within this particular certificate vendor. So Network Solutions will not issue another certificate with the same serial number, especially in this case, but in any case.
The version number, the Signature Algorithm, so this is where we know the signature was signed with the SHA-1 hash, with RSA level encryption. We see its validity, beginning and ending dates, and then we have the public key. We've talked about the public key being available here in the certificate, and where would people get that public key from, well right here in the certificate. So we're here in Network Solutions Certificate Authority We know that it was encrypted with RSA encryption, we know that the public key is 256 bytes, and this is the public key.
So this hexadecimal number is used by clients to encode data, which would only then be de-coded by the associated private key, okay. We have key signs. We know that the key usage it's being used to verify authenticity, and here is the key signature file, which verifies the signature authenticity, of the public key, okay. This is all self-referencing. Below we have the things like the basic constraints, which are set.
We know that the basic constraint here in this is critical, so this is going to be observed, and that it is being used as a Certificate Authority. That's where that's listed there. We also have our subject key identifier, which is not critical, but the key ID is right here, and we also knkowthe CRL distribution points. They say it's not critical, but this is the URI that's being listed, to find out whether or not the certificate has been revoked. So if the client is not going to an OCSP lookup, it can always use the CRL distribution points, to look up whether or not they should continue to use certificates that are associated with this certificate, and below we have the SHA-1 and MD5 fingerprints listed.
All right, so this is a root certificate, we have an additional type of root certificate that we also could have looked up, that would have been virtually identical, except that it would not have been in the system root's keychain, instead, would have been in the system keychain, and that would be any certificate that is private. Okay, here you can see that we've got a root certificate authority for lynda.com, and that is an internal certificate, that is built on their internal system. I'm not going to open this one up, but is has custom trust settings.
You'll notice the icon looks identical, and we have an expiration date listed, and the fact that it's a root certificate authority. So, like I said, you can have a private certificate authority, or a public certificate authority, both will be listed within your system. The system roots, of course, will contain all of the public ones, and your local system will have the ones that you've administered for yourself.
- 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.