PKI Certificate

PKI Uses

Understood Nothing

You've probably heard the term PKI being used in a work environment. And if you're into IT security, you'll be well familiar with the term. PKI stands for Public Key Infrastructure. Essentially, what it is, if we can water it down to a single sentence, is it's a hierarchy of digital security certificates, where unique public and private key pairs are issued for each certificate. So certificate authorities, otherwise called CAs, are authorities that issue certificates. They can renew certificates because certificates have an expiration date, and they could be renewed before they expire. They also do have an expiration date where they will simply expire by themselves, where they can no longer be used.

And also certificate authorities are responsible for revoking certificates, maybe due to compromise of a station or because a user is leaving the organization. We also have the option of working with our own private internal certificate authority. You might install a product like Microsoft Active Directory Certificate Services or maybe you would use OpenSSL. But either way you can have a private CA where you sign your own certificates. The only issue with that is that devices out there on the network don't trust your private, self-created certificate authority.

So you would have to install the root certificate for your CA on those devices. Of course, we've got public CAs where we could have a certificate signing request that we've generated issued up to the public CA. And after they've done their due diligence, their CA can digitally sign and return our certificate. We might do that, for example, if we need a website certificate that's trusted globally. So what is PKI used for? Well, it uses a public key. And the public key can be shared publicly with any user or device, that's why it's called a public key.

So the recipient public key then would be used when we encrypt a message that we're sending to that recipient. We need their public key to encrypt it. Public keys are also used to verify digital signatures. Now the private key must be available only to the key owner, whether that's a device or whether it's a user. So it's not like a public key. Private keys are going to be kept private only to the owner, and they can also be embedded in things like cards, like smartcards. So encrypted messages then are decrypted using this key.

Remember up above you need a public key to encrypt the message to somebody. You need their public key. Well, they need their mathematically related private key from the key pair to decrypt that message. The private key is also used to create a digital signature. So if we have a need, let's say, of e-mail confidentiality, how does PKI serve this need? Well, we can encrypt the message with the recipient's public key. The second item here is what if we need e-mail authenticity and integrity? Well, a solution is to generate a message hash and encrypt that hash with the sender's private key.

And often, that's done seamlessly and transparently in modern e-mail programs. What if we have a need to secure network communication to a web server? Well, we would use a PKI certificate issued to that web server and make sure that TLS version 1.1 or higher are used. And then we would enable HTTPS on the web server. Now TLS version 1.1 is a secure way to secure network communications using a PKI certificate.

Using the older SSL security protocol should never be done due to its large number of vulnerabilities. And there are even vulnerabilities associated with TLS v1.0. And that's why we're saying here you should start at TLS version 1.1. What if we have a need to use Multi-Factor Authentication to a VPN? Well, PKI could solve that because we might embed a private key on a smartcard, which would be used. The smartcard would have to be available and presented when we need to authenticate the VPN.

Finally, what if we have a need to have a single card, a physical card that people carry with them, that would allow things like facility access, as well as computer access? Well, that's called a Common Access Card or a CAC. Essentially, it's a smartcard that has multiple uses that contains an embedded private key.

 

PKI Hierarchy

Understood Nothing

The PKI hierarchy is a hierarchy of digital security certificates, where certificates are issued and also managed after they're issued by a certificate authority. We could have a private certificate authority or a private CA that we set up within our own organization and that private CA issues certificates and manages them. The only thing we would have to consider is on all devices that need to trust certificates issued by that private CA, we would have to install that private CA's root certificate.

Public CAs are available for a fee as well. Where we could send a certificate signing request up to the public CA, either through a web form or through an e-mail file attachment. And after the public certificate authority does their due diligence to ensure that the information that we have provided in the request is valid, they can use their CA, private key to digitally sign our certificate.

And if it's a public CA, it will be trusted globally. So we might do this for example, if we have a public website that we want to secure using HTTPS.

The PKI hierarchy starts at the very top with the root certificate authority or root CA. Now from there, the root CA could issue certificates directly, but in a larger enterprise, you would have subordinate CAs.

Maybe for different parts of the world, different countries, different provinces, different regions. Or even within a large corporation, we might have different CAs for different departments, or different projects. And each of those subordinate CAs, in turn, can issue its own certificates.

A diagram explaining the PKI hierarchy is displayed. The Root CA is at the top. The Root CA is connected to Subordinate CA1 and Subordinate CA2. Subordinate CA1 and Subordinate CA2 are connected to Certificates. 

Now if that's the case, then the root CA doesn't need to be there, doesn't need to be online and available all the time, unless you're going to be doing something like creating a new subordinate CA. So the issuing certificate authority digitally signs issued certificates. And as we were saying, the root CA really, from a security perspective, should be brought offline when it's not being used.

The reason is because if the root CA is always left online and by chance, it gets compromised. Now it has a higher degree of being compromised if it's always online. If that root CA at the top of the hierarchy is compromised, all subordinate certificates are compromised, including subordinate certificate authorities. So you can see why this is a big deal.

Now, if we have a compromised subordinate CA, then certificates issued by that CA are compromised, nothing above it in the hierarchy. So it's always important then that we consider the PKI hierarchy when we're planning our public key infrastructure, or if we're making changes to an existing configuration and trying to harden it.

 

Create a PKI Certificate Authority Using Linux

In this demonstration, I'm going to use Linux to create a PKI Certificate Authority. The first thing you're going to need to do is to make sure you have the appropriate module or tools installed to work with PKI in Linux. So for example, I could use the apt-get install command if I wanted to install the openssl package. Here I can see that openssl is already installed with the newest version.

He opens the root@kali: / window on the Linux operating system. The root@kali: /# prompt is displayed. Then he executes the following command: apt-get install openssl. The output displays the status of the latest version of the openssl installed. 

So now what I'm going to do is make a directory here on the root of the file system, and I'm going to call it pki. And I'm going to change directory into the pki directory. Because any files that are generated, I want organized in this location.

So what I want to do then is use openssl, this is the command that's built-in once you've installed this. And I got to tell it I want to generate some RSA keys, rsa, I want to use aes256 bit keys. So AES is the algorithm. And I have to give it the name for an output file. So I'm going to call this let's say ca_priv for private.key. That's the private key file that will be generated. And then we're going to tell it that at the RSA level, we want to make sure that we use 2048 bits. And we going to go ahead and press Enter.

 

Generating CA Private Key:

He executes the following command: openssl genrsa -aes256 -out ca_priv.key 2048. The output displays a message: Generating RSA private key, 2048 bit long modulus, and asks to enter a pass phrase for ca_priv.key.

Okay, so we now have a private key that's 2048 bits, that's good. So the next thing we're going to do is enter a pass phrase for the private key. I'm going to put in a password, and then I will verify that same password.

Now the next thing that we want to do is actually generate a CA or certificate authority certificate. So to do that I'm going to run openssl req for request -new and then -x509. x509 is the standard that's used for PKI certificates. I'm going to specify my private key with -key. So that was called ca_priv.key. Then I'm going to specify the signature algorithm, because remember a certificate authority digitally signs certificates.

Here it's going to use sha256. I'm going to specify in days, the lifetime of this certificate, so it's going to be let's say, only 365 days, that's not very long for a CA. Commonly it might be five years, maybe even ten years, but here I'm just going to make it one year. And I'm going to specify the name of the output file for this CA certificate. So -out and I'm going to call it ca, let's say .pem, standard file format.

He executes the following command: openssl req -new -x509 -key ca_priv.key -sha256 -days 365 -out ca.pem. The output prompts to Enter the pass phrase for ca_priv.key. 

Now because we referenced our private key it wants the pass phrase for it, that's good. You always want a pass phrase on a private key file. So I'll go ahead and enter that, and then I have to fill in some details because we're establishing a certificate authority, so it has questions. So the country name, two letter code, in this case, for Canada, I'll put in CA.

He enters the pass phrase and presses the Enter key. The output includes a message that reads, You are about to be asked to enter information that will be incorporated into your certificate request. Country Name (2 letter code) [AU]:. 

 

 State or province, I'll fill in the appropriate value, same with the locality, that's city name. Locality is filled in, the organization name, I'll just put in here as FakeCo and organizational unit, maybe Hq, headquarters. And a common name, so this would be for my certificate authority, I'm going to call it MyCA. And then an email address for a user. So that would be an administrative account, for example, so I'll fill that in.

He enters the email address as user@fakeco.com. He again presses the Enter key and the prompt remains the same. 

ca_priv.key -> Private Key

ca.pem -> Certificate Authority

 

Web of Trust

When you acquire a passport or a driver's license, that is trusted by other government departments, and agencies, and institutions, because they trust the issuer of the passport or the driver's license. And with Public Key Infrastructure or PKI, the same type of web of trust exists.

So in the PKI hierarchy, the issuing certificate authority or CA digitally signs issued certificates using its private key. Now, only the CA owner has access to that private key and the signatures created from it. Now, the signature is then used to establish trust, because if we trust at the certificate authority then by extension, we also trust any certificates that have that certificate authority digital signature. Pictured on the screen, we've got a screenshot on the right of the trusted root's certification authority's store on a Windows machine.

The screenshot of Trusted Root Certification Authorities displays a table which includes Issued To and Issued By column headers. 

 

 In other words, different types of operating systems, in this case, Windows, have a list of public certification authorities who they trust. And if they trust that public certification authority, by extension, they trust any certificates issued by that authority. So devices then, like your laptop, your desktop, your smartphone, needs to trust certificate signers. Now, we're looking at the Windows trusted certificate store, that's what we were talking about. But the same type of system exists on a Linux host using the Linux CA certs key store.

So certificate trust stores then have a list of trusted root and subordinate certificate authorities. And, as we know, if you trust the certificate authority, then you also trust all the certificates issued by that certificate authority. That's what the web of trust is about. Now, with private certificate authorities that you might create within your own organization, as opposed to public certificate authorities. Certificate trust stores on devices will not automatically trust the CA. They won't contain the certificate, the root certificate, and so they will not trust any issued certificates.

So the trusted root certificate then you would simply have to import on devices in your organization. Now, the private CA will issue certificates and remember that they will then be trusted on devices. The trust is established based on the CA signature contained within issued certificates. So again, the overall theme is very simple. If you trust the certificate authority, then you trust all of these certificates that are issued by that authority. Just as in the same case, if you trust an issuer of passports within a country, then you will trust all of the passports issued by that country.

 

PKI Certificates

With Public Key Infrastructure, PKI certificates are issued by a certificate authority, by a CA. And these certificates could be issued to a user. Or may have a certificate issued to a device like a smartphone that needs to authenticate to a VPN. Or we can even have certificates issued to be used by software components or services. So these certificates are issued by the CA for security purposes such as to encrypt files or encrypt network communications.

To verify file integrity or message integrity over a network to ensure it's not been changed. And also for authentication such as over the network with messages so we can trust that the message came from the sender it says it came from. So we can store PKI certificates in many different places. It might be stored in a file, in the file system on a device. A PKI certificate might be stored on a smartcard. So there are many different ways that we can store these PKI certificates.

As a matter of fact, if you're using a business computer like a laptop, you might even have the trusted platform module TPM firmware chip which can also incidentally store PKI certificate information. So what's in a PKI certificate anyway? How does this work to allow security in an environment? Well, we know the PKI certificate is issued by a CA and that it can be stored in a variety of different ways. What's in it?

Well, the version of the X.509 standard that's used to generate that PKI certificate. The digital signature of the certificate authority, which is important to establish trust. The signature algorithm that was used by the certificate authority to create the signature. For example, maybe it was SHA256. The certificate serial number is certainly stored within the certificate.

The date the certificate was issued, when it expires, how the certificate and the keys can be used whether only for encryption, or maybe only for authentication, or both. The subject name which is important. The subject name could be the URL of a website, which has to match what people are typing in for the certificate to be trusted. Or maybe the subject name is a user e-mail address, if we're using user certificates to encrypt and digitally sign e-mail communications. So the certificate can also contain public and, in some cases, private keys.

Now the purpose here would be for encryption and decryption. For example, we would encrypt with the recipient's public key if we sent something to them. And they decrypt with the related private key. Digital signatures are created with the private key and verified with the public. In some cases, the private key will not be stored within a certificate. So it really depends on the environment and how the certificates are being used.

PKI certificates can also be issued from templates depending on the solution that you're using. And as you would guess, the template is just a blueprint of all of the details that will be placed within the PKI certificate. The items that we just talked about. Certificates and public or private keys can also be exported.

Now if we think about this, we might have a certificate that contains a private key. And we might want to backup the private key in a safe place. So we can actually export it as long as when that certificate was issued, exportation of the private key was marked as being allowed. Now public keys can be shared with anybody. And so it's okay to provide a public key to anyone over the internet, whether you trust them already or not, however, not the private key. And as we said, you might export the private key from a certificate for backup purposes. Private keys should only be available to the entity to which it was issued, be that a piece of software, or user, or a device.

Now in the PKI certificate, we mentioned the subject name field. And we said that this must match the entity such as the URL of the website or the e-mail address of the user. So if that's not the case, then we won't have trust established. So in the case of a secured website, if the URL that people are typing in doesn't match the URL in the subject name field in the certificate, then depending on the web browser people are using will determine exactly what message pops up. But in essence, that site will not be trusted. And that is not a good thing.

 

Issue a PKI Certificate Using Linux

In this demonstration, I will use OpenSSL in Linux to issue a PKI certificate to be used by a Linux web server.

The first time here, we're going to use it to generate a private key file that will be used by our web server certificate. And to do that, I'll run openssl genrsa, I want to generate an RSA type of key, that's the algorithm that will be used. And the output file will be, let's say, the file name can be anything, but I'm going to say www.site.com.priv.key. So I know it's the private key and I want it to be a 2048 bit RSA key.

He executes the following command: openssl genrsa -out www.site.com.priv.key 2048. The output displays a message: Generating RSA private key, 2048 bit long modulus. 

 

Now, I have to generate a certificate signing request. What I'm doing is preparing a file here that needs to be submitted to the certificate authority whether it's on this host or whether we send it through e-mail or paste it in to a web form field. One way or another, the certificate signing request has to be sent to the CA because we need the CA to digitally sign it and send it back to us. So let's generate a certificate signing request, openssl req -new.

And I have to tell it to the key -key, the private key that is, that I've generated previously for this web server certificate. And then I have to specify an output file for this certificate signing request. So how about we call it www.site.com.csr, for certificate signing request.

He executes the following command: openssl req -new -key www.site.com.priv.key -out www.site.com.csr. The output includes a message that reads, You are about to be asked to enter information that will be incorporated into your certificate request and the field: Country Name (2 letter code) [AU]. 

It's going to ask me for a bunch of stuff like the Country name and so on. I'm going to specify, let's say, CA two character country code, state or a province of some kind, so I'll spell that out. A city name, organization name, and I'll just fill in some values here. And the common name is important because if people will be entering, let's say, www.site.com in a web browser to access my secured web server, then I'm going to have to make sure that that is in the certificate. So I'm going to put that in as the Common Name, for the Email Address, maybe admin@fakeco.com.

He types CA for the Country Name (2 letter code) [AU] and presses the Enter key. The output prompts: State or Province Name (full name) [Some-State] and he types Nova Scotia. He presses the Enter key, the output prompts: Locality Name (eg, city) [], and he types Halifax. He presses the Enter key, the output prompts: Organization Name (eg, company) [Internet Widgits Pty Ltd], and he types FakeCo. He presses the Enter key, the output prompts: Organizational Unit Name (eg, section) [], and he types Hq. He presses the Enter key, the output prompts: Common Name (e.g. server FQDN or YOUR name) [], and he types www.site.com. 

Now, when you do this with public certificate authorities out on the internet, you don't just make this stuff up. It has to be filled in correctly. So do I want a challenge password to be used with this signing request? No, so I'll just press Enter, optional company name, Enter.

And if I clear the screen and type ls, we now have a certificate signing request file, csr.

So as you might have guessed, the next order of business is we need to ask the certificate authority, which is on the same host, it doesn't have to be. But we've got the private key for the certificate authority and the certificate file for a certificate authority I've previously created already available here.

He highlights the private key: ca_priv.key and certificate file: ca.pem in the output. 

 

So that in conjunction with the certificate signing request will allow us to actually generate a usable PKI certificate for the web server.

In the real world, when you request a certificate from a public authority, they'll do some due diligence to make sure that the information you provided is accurate and correct. So trust is very important with this. Now notice here, I've got a file I've already prepared called otherinfo.ext. It's extension, or additional information, you can think of it as a template that will be used to issue certificates. And if I used the cat command to display the contents of that file, you're going to see what I've typed in here.

So I've typed in a bunch of stuff, notably, keyUsage, how can this be used, for digitalSignature, for keyEncipherment. In other words, for encryption of keys and also for the encryption of data, dataEncipherment. But what's really important here is the subjectAltName, san, S-A-N which is referring to a section further in the file called @alt_names. And here it is down here. So the first DNS name, DNS.1 is going to be the URL people will enter to connect to my site, www.site.com. So I actually want that injected into the certificate that we're about to issue. Okay, so let's just clear the screen, let's just do an ls so we can see our file names again here.

So I've created the command here. It's openssl x509, that's the type of certificate we're creating, a PKI certificate. We are looking at a request for an actual certificate, and we're getting that from our certificate signing request input file, so -in. And I'm just referring to the name of the CSR that we generated. Then I'm going to specify the CA certificate file which happens beyond this machine that's called ca.pem, then the CA private key file, same thing. It's on this machine.

I'll specify that and then the output file I want to create here which is my actual web server certificate file, the number of days that the web server certificate will be valid. So here it's only one year, 365 days. The signature algorithm that will be used by the CA to digitally sign the certificate, in this case, sha256 is the algorithm that will be used, telling it to create a serial number. Because PKI certificates are uniquely tracked by a serial number and then I'm specifying to use that otherinfo.ext file with the extensions file parameter -ext file. And remember, that maps our subject name to our alternative name, so the URL of the host. And I'm going to go ahead and press Enter.

He executes the following command: openssl x509 -req -in www.site.com.csr -CA ca.pem -CAkey ca_priv.key -out www.site.com.crt -days 365 -sha256 -CAcreateserial -extfile otherinfo.ext. The output prompts: Enter pass phrase for ca_priv.key. 

So of course, it wants the pass phrase for the CA private key, I'm going to go ahead and specify that value, and then I'll press Enter. And that's it, it's done. If I clear the screen with the clear command and type ls, we've now got an actual PKI certificate file that can be used, in this case, for a web server, such as with the Apache web server.

So then when we configure our web server engine whether it's nginx or Apache or whatever it is to use that as the PKI file to secure the connection normally over port 443.