Creating a public key infrastructure requires extensive planning. In this video, you’ll learn about the most important components required to build a successful PKI.
<< Previous Video: Wireless Security Next: PKI Concepts >>
“PKI” stands for Public Key Infrastructure. And it’s a way to describe the policies, the procedure, the hardware, the software, and the people that are used to manage digital certificates. This means the process of creating, distributing, managing, storing, and revoking certificates is all encapsulated under PKI. From that description alone, you can tell that this is a large undertaking that has many different decisions that need to be made during its implementation. This is not something where you would install some software and make certificates in a matter of minutes. Instead, there’s going to be a number of conversations and meetings that take place, to determine how you want to implement the PKI in your environment.
“PKI” also refers to the associations we make with a public key to a person, or a public key to a device. It’s all based on trust, and this trust is created by a certificate authority, or a CA. This key management lifecycle starts with the creation of a key. We decide on a particular strength for the key, which would be a certain number of bits, and we decide what cipher we’d like to use to create the key.
We would then generate a certificate where we associate this public key with a particular user or a particular device. Then we distribute the key to the user or device that it’s associated with, and we store it in a protected area. We don’t want someone else to gain access to the certificates so they would use it in an unauthorized form. If someone does gain access to this certificate, or we find that the certificate needs to be replaced, we may need to revoke the current certificate and manage any keys that might be compromised.
Even if we don’t revoke the certificate, there is usually an expiration date associated with the certificate. Best practices tell us that we should update our certificates frequently. So, once the certificate expires, we begin the key management process over again.
A public key certificate or digital certificate is usually a public key combined with a digital signature. There might also be other important details included with the certificate, as well. This digital signature is one that comes from a third party. So we might have a public key associated with me, but I might have a certificate authority sign my public key so that you can trust that the key really did come from me. If you’re using a web of trust, like you do with PGP, you may get your digital signatures from other people that you know. And then, if somebody knows someone that you know, it creates a web of trust, and they can trust that it’s your certificate.
You can create your own digital certificates with Windows. It’s part of the Windows domain Services. And in Linux there are a number of third-party options you can use to create certificates.
The digital-certificate format has a standard format called the X.509 certificate format. There are a number of different items that are listed as part of a certificate, including a serial number so you can identify this certificate. And we mentioned commonly a public key will be part of this certificate, as well. The certificate authority will also be listed as the issuer, and we can see other items such as the algorithm used by the certificate authority to digitally sign the certificate and the date and time in which the certificate may be valid.
You can also add other items to a certificate, to add functionality, or include other details about the certificate holder. There are a number of standard extensions that can be added to the certificate. It might include a digital signature, nonrepudiation information, or information about a certificate revocation list.
If you look into the details of your web browser, you’ll see that there are hundreds of certificate authorities listed. These are the trusted certificate authorities that can be used to digitally sign certificates from web servers. If you manage a website, you would have one of these trusted certificate authorities sign your digital certificate that you can then place on your web server. And then anyone who connects from any browser will see that your web server was signed by a certificate authority that is trusted by the browser.
This is a relatively easy process, to have this digital signature created by a certificate authority. It starts with the creation of a key pair– your public key, and your private key. You would keep the private key on your website, and then you would send the public key to the certificate authority to be digitally signed. This is called a “certificate signing request,” or a CSR.
The certificate authority then performs number of checks, to verify that you indeed are the owner of this particular domain and web server. It will then provide a digital signature and, in some cases, provide additional features to the certificate and send it back to you. Of course, you can perform all of these certificate-authority functions yourself in-house, by building your own CA. All of your devices inside of your network must be configured to trust this particular certificate authority. This is usually very common to find in medium-to-large organizations that have many web servers and other devices that need to have some type of encryption. And, instead of going out to a third party and paying for each individual certificate, you would have your own certificate authority, and you would simply build them in-house.
There are many different software packages that can be used to help build your own CA. In Windows, there’s the Windows Certificates Services. And other platforms may want to use OpenCA.
There are many ways to roll out a certificate authority. One way is to have a single CA for your organization, where every device and every person receives all of their certificates from the single certificate authority. In most environments, however, it’s unusual to have a single certificate authority. Instead, you’ll roll out something that’s more hierarchical, where you might have a root certificate authority and underneath the root might be many different intermediate certificate authorities. This allows organizations to distribute the load of the certificate creation or perhaps allow different regions of the company the ability to create and manage their own certificates.
Another good reason to use intermediate certificate authorities is to manage the process of revocation. If someone does gain access to the private signing key that’s used on these intermediate certificate authorities, you would only need to revoke the certificates that are underneath that particular CA and not revoke all of the certificates for the entire organization. The process for revoking these certificates occurs on the certificate authority, through a certificate revocation list, or a CRL.
There are many different reasons for revoking a certificate. The certificate may be associated with a server that’s no longer in use. Or maybe the certificate was issued originally in error.
Or you may have an instance where someone gains improper access to that certificate, and you need to revoke it and assign another one. This happened in April of 2014, with the Heartbleed vulnerability. Every web server using OpenSSL found that there was a flaw that might provide someone access to the web server’s private key. OpenSSL had to be patched, and every web server needed a new certificate. Older certificates were then moved to the certificate revocation list, so that someone could see that all of those certificates were formally revoked.
Now that the certificate authority has this list of revoked certificates, there needs to be a way for the browser to recognize that these have indeed been revoked. For that, we use OCSP, or Online Certificate Status Protocol. And this is what the browser uses to check the status of a particular certificate.
These are usually sent via HTTP, since that is the normal protocol used for a web browser. And this is also something that’s easily supportable over existing internet connections. Not all browsers and applications that need to communicate using these certificate details will support OCSP. For example, many early Internet Explorer versions had no support for any type of OCSP, and some applications don’t even bother checking to see if a certificate may have been revoked.