It takes many different components to build a successful PKI. In this video, you’ll learn about the key management lifecycle, digital certificates, certificate authorities, and more.
PKI or Public Key Infrastructure, is the process of managing practically every aspect of digital certificates. This covers the policies and procedures, the hardware and software, behind these digital certificates, and of course the entire digital certificate process starting with the creation all the way through the revocation.
Creating a public key infrastructure for your organization, is not a trivial undertaking. There is a lot of questions that need to be asked and this is something that usually involves a large number of the people in the organization. If you’re working with PKI on a daily basis, most of your work is going to be about creating certificates and associating those certificates with users or devices. This is something that is centrally located in the certificate authority or the CA.
Since the PKI creates the foundation of trust for all of these certificates, it becomes a very central and very important part of your infrastructure. If you’re managing the PKI for your organization, then you’ll have a number of different responsibilities. For example, you’ll be responsible for creating the keys, those keys will have a particular strength and use a particular cipher.
You’ll also be responsible for generating the certificates which associate these keys with a particular user. And then you’ll need to safely and securely distribute those keys to their users. Those keys will need to be stored somewhere and of course, we’ll need to make sure that they are stored safely and that they are used appropriately, and there may be times when a key has to be revoked and it will be the responsibility of the PKI administrator to manage that revocation process.
We usually create these keys with a particular expiration date, and once the expiration date is met, you’ll have to begin the process again with creating new keys. We often talk about distributing digital certificates to users and to devices on our network and those digital certificates are commonly a public key that is combined with a digital signature. Usually the digital signature is from the certificate authority.
These digital certificates might also contain additional information that could describe more characteristics for that particular user or device. We mentioned earlier that the foundation for this public key infrastructure, is the trust we associate with these certificates. The only way that we can trust that certificate is valid, is to evaluate its digital signature, and since that digital signature is coming from the certificate authority, that certificate authority is the central point of trust.
There are other ways to associate trust with these digital certificates. One way would be through a web of trust. If you don’t have a central certificate authority, then it’s up to the users of these certificates to vouch for each other and digitally sign each other’s certificates.
There are many different ways to create these digital certificates, and if you’re building out a certificate authority, you’ll find that Windows domain services has the certificate creation process built into the operating system itself. If you’re using other operating systems like Linux or Mac OS, there are many third party options available as well.
Your browser or operating system, will maintain a list of all of the trusted commercial certificate authorities. And if you bring up that list, you will see there are hundreds of CAs that are part of the operating system or part of the browser you happen to be using.
These commercial certificate authorities, allow us to purchase a certificate from them, that is then trusted by all of these browsers or all of these operating systems. This is usually done by building a key player locally on your machine, you would then provide the public key to the certificate authority, the certificate authority would go through a number of steps to confirm that you are indeed the person making the request and then they will sign that particular certificate.
When you’re providing that public key to the certificate authority, we refer to that as a certificate signing request or a CSR. Once the certificate authority signs that certificate, they send it back to you and now you can put that certificate on your server. When people connect to your server, they can not only see that there is a certificate with your name but it has been signed by one of these commercial CAs and therefore it can be trusted.
If all the applications and services that you’re using are done in-house, and no one external will be connecting to them, you could become your own certificate authority and sign your own certificates. It’s certainly much easier to build your own certificates internally and sign them yourself, than sending them out to a third party, and it’s also less expensive because we don’t have to pay for a third party to do that.
Having an internal CA is almost a requirement if you’re a medium to large scale organization with hundreds of different servers and you need to provide sign digital certificates for every single one of those servers. There are many ways to manage this process internally and be your own certificate authority and Windows, you have the Windows certificate services and in Linux and other operating systems you can use software such as open CA.
In the simplest infrastructure, there is a single certificate authority and that single certificate authority signs the certificates for everyone in the organization. But in most organizations there is a hierarchy of certificate authorities. You can have a root CA, there might be intermediate CA just underneath, and underneath an intermediate CA would be what we call a leaf CA. This distributes the load of managing the certificates across multiple CAs, and perhaps even across different parts of your organization.
This also makes it easier if a particular certificate authority is compromised, and you need to revoke all of these certificates that, that CA is signed. You can remove one of those leaf CAs, and the intermediate and root CA would still remain valid.
In large organizations, you might have someone managing the certificate authority, and there may be another group that handles the registration authority or RA. The registration authority goes through the process of identifying who the requester happens to be, they perform some validation of that requester, and then ultimately decide if that certificate should be signed.
This is a critical step when we’re working with certificate authorities because everything is based on the trust of that CA. And if somebody is performing additional checks and balances, then you have a stronger level of trust for that sign certificate. This already may also be responsible for revocations.
So if a certificate is deemed to have been compromised, the RA can revoke that certificate, and make that certificate invalid for anyone connecting to that servers. And eventually, the certificates that have been assigned, will expire and need to be reassigned or recreated and the registration authority can be responsible for that as well.
So what’s inside one of these certificates? If you’re connected to a website right now, you can click the lock that’s in your address bar, and you can look through the certificate and all of the different characteristics. This is the certificate from professormesser.com it was issued by cloudflare, and it has an expiration date at the top, and the browser has already done its checks and determined that this certificate is valid.
There are a number of other attributes that are inside of this certificate and you can scroll through the certificate and see all of the different settings that can be used by the browser or other clients that are connecting to the server.
An important attribute on the certificate, is the common name or CN. This is the fully qualified domain name associated with the certificate. So on my site it would be professormesser.com or www.professormesser.com.
If you’re connecting to a site and that common name in the certificate doesn’t match the name that you put into your browser or address bar, you get a message like this saying your connection is not private, if you’d like to see some of these error screens in your browser, you can go to badssl.com and there are a number of different error messages so that you can get an idea of what you can expect to see in your browser if any of these errors were to occur.
You can assign a single common name to that CN attribute, but in my particular case, my website could be professormesser.com or www.professormesser.com in that case I want to add some additional names and we can do that through the subject alternate name attribute, or the SAN. This allows me to set additional hosts and you may find with some sites that there are many subject alternative names associated with a single certificate. If you look at the one for professormesser.com there are generally only two listed there for professormesser.com and www.professormesser.com
There are times when these certificates will expire and if you connect to a site that has an expired certificate, you’ll see a message that says the cert date invalid. This means that this particular certificate has expired on that server, and the owner of that site would need to renew the certificate and update that on their servers.
It used to be very standard to create web server certificates that might last as long as three years, but through the years we’ve decided to shorten that time frame to limit the amount of time that a particular certificate might be compromised.
So in your browser, there is a maximum expiration that is allowed of about 30 months or 398 days. This means that any certificate you create for your website, will need to be a maximum of 30 months or smaller amounts of time for that certificate. If you go to professormesser.com, you’ll find that my certificates are only valid for about 1 to 3 months.
There may be times when a site is compromised and the certificates on that site need to be revoked before they expire. We can provide this key revocation through a number of different means, one of these is a certificate revocation list or CRL.
This is a large list of revoke certificates that is stored at the certificate authority. And usually this is a single large file that is stored on the CA. I was looking at the certificate on the comptia website, and you can see that the CRLs are listed as one of the attributes in their certificate. I downloaded one of these files before making this video and that single certificate revocation list was about 18 megabytes in size.
There are many different reasons for modifying or revoking a certificate there could, of course be compromise to the site, but it may be that you’d like to change one of the attributes that’s part of the certificate. Or maybe you acquired a new company and you’re changing all of the certificates on their servers.
One big reason that we had for changing certificates occurred in April of 2014, through a vulnerability and open SSL called heartbleed. Through this vulnerability, the potential existed for someone to gain access to the private keys associated with these certificates on these web servers.
And because the potential was there, and we had no way to know whether someone had been able to take advantage of this or not, almost everybody had to replace the certificates on their website servers across the world. This meant that a lot of certificates had to be replaced and we ended up adding many of these to our certificate revocation lists.
If you want to see the CRL for a website you happen to be visiting, you can click the lock in the SSL view of your browser, and go through all of the different attributes of the certificate to find the one for the CRL distribution points.
In many environments, downloading a relatively large certificate revocation list file is not very practical. So there needs to be another way to check the validity of these certificates. In a much more efficient way to do this, is by using an online certificate status protocol or OCSP. This is something built into our browser that can perform a single check just for this certificate, to see if that certificate may have been associated with something revoked.
This is usually a check that can be done from your browser to an OCSP responder, that is usually managed by the certificate authority. This allows a browser to validate a single certificate rather than downloading a large file which may or may not include this certificate.
Many browsers these days support OCSP, but you may find some older browsers or older applications that do not properly perform any OCSP checks. You might also find browsers that support OCSP but don’t go through the process of actually checking for the revocation when visiting that site. For that reason, you may not want to rely on a single method for performing validation and instead use multiple methods to check on the validity of a particular certificate.