Introduction

Public-key infrastructure (PKI) is what makes internet encryption and digital signatures work. When you visit your bank website you are told it is encrypted and verified. If you install software on Windows machines you may notice a popup when Microsoft cannot verify the digital signature of the software. In this article I give my explanation of how PKI works then a solution for it’s implementation in a private environment within a Linux shop.

How PKI works

 

Most have heard the names of Verisign, Network Solutions, and GoDaddy. These companies along with many more are in the business of allowing the public to trust an organization’s encryption keys and are referred to as Registration Authorities (RA)

 

If an organization, let’s say your bank, wants to encrypt their website that you use to manage your accounts they would first need to generate a private encryption key. The private key is something that should remain just that; private. With the private key one can extract a public key. While a public key can be created from a private key, the reverse should not be possible.

 

 

Now the fun part, any messages encrypted using this private key can be decrypted via the public key and vice versa. The bank now decides that they want a third party to verify the authenticity of their private/public key pair because without it their users get a warning in their web browser stating that the site shouldn’t be trusted. I am sure most of you have seen this error before:

The bank sends their public key to an RA and pays for them to digitally sign it with their Root Certificate Authority (CA). This CA is nothing more than another public/private key pair. Remember how I said that anything encrypted with a private key can be decrypted with the public key? At the time it may not have sounded like a good idea to have any message encrypted that can be decrypted by anyone. In this case, the RA is the only one with access to their private key and everyone has their public key (You literally do have it, every modern operating system maintains a copy of these trusted Root Certificates). The RA adds a message to the bank’s public key using their private key with the goal that your web browser should now be able to decrypt and view the message. If this is all successful, you do not see the nasty page like the image above and you can be assured that this site is using a certificate that the third party has verified..

So you now have your bank’s public key. This means you can encrypt a message with it and only the bank can see that message using their private key. The bank does the same thing to send you messages. When you initiate a connection with a web browser to a site that uses HTTPS, you also send your own public key to your bank. They will use that to encrypt messages and send back to you for you to decrypt using your private key. Since you do not need to supply any authenticity of who you are to the website, there is no problem with your public/private keys being generated dynamically.

Lastly, public/private key encryption is wildly inefficient due to the existence of the public key. In order for the public key to be securely derived from the private, we have to use very large key sizes. At the time of this article I recommend 4096-bit key size.

So why do we use PKI if it is so inefficient?

This sort of encryption is also referred to as asymmetric encryption. Symmetric encryption is much more efficient, but has one flaw; both sides need to know what the private key is. The purpose of PKI is the means for two endpoints to securely decide on a symmetric key to use to continue communication; usually a 128-bit or 256-bit key.  

To summarize:

1. You type in your bank’s address in your web browser
2. Your web browser provides your bank with its public key.
3. Your bank responds with its public key
4. Your web browser checks it’s list of Root Certificates to try to decrypt the digital signature
5. If successful, both sides run through a series of algorithms and exchanges to derive the same symmetric key to be used for the rest of communication within this session.
6. At this point, your bank’s website finally appears in your browser and any communication henceforth will be encrypted using the symmetric key.

Security Concerns

So what benefit does a company get when a root certificate authority is used to verify the public key a server presents to a client? The answer is more human than you would think. When a self-signed certificate is used, a user gets that nasty warning I discussed earlier. If this warning is disregarded and the user continues to the site, the communication between the server and client is still encrypted.

However, If we train our users to ignore those security warnings about the inability to prove the authenticity of the server’s public key then our users will always ignore this error. In 99.999% of cases this is probably okay, but what can potentially happen is what is known as a Man-In-The-Middle(MITM) attack.

Using the brief description of PKI above, imagine if there was a malicious user somewhere on the internet, or more likely somewhere locally, placed directly between your computer and the server. When the initial key exchange takes place the attacker can intercept your public key, and send you theirs instead of the server’s of which you are trying to talk to. His public key will most likely not be digitally signed with the same domain name as the site you are visiting, although if this was a targeted attack on a particular server it could be possible.

Since the attacker likely wants to steal data, he will then proxy a connection to the server your originally wanted to go to, but instead of your public key going to the server it would be the attacker’s. This places the attackers computer directly between you and the server and will be able to capture and view any data sent between both machines. Well, that is if the user has been trained to simply ignore the warning they got from their web browser.

My Linux PKI Implementation

Most organizations rely on internal sites for their business operations and purchasing a certificate signed by one of these root authorities for each site can become costly. In addition, if an organization makes use sub-subdomains it becomes harder to simply use wildcard certificates for each subdomain. The solution here is for that company to become its own Root Certificate Authority.

In the Windows Server world, this is quite easy using their PKI Services Manager. If you are anything like me you cringe at the thought of Windows Servers! In the Linux world there is TinyCA, but it depends on a graphical environment. I am sort of a minimalist, so a Desktop GUI on my servers is just not going to work for me. Under this dilemma I decided to use OpenSSL which has all the necessary functions built within it. However, these commands are long and difficult to remember and I hate having to look up syntax or notes every time I want to perform a task.

Here is where my bash script comes in. Using whiptail to add a decent interface while keeping everything within one script I included functions that:

• Manages multiple domains

• Creates a Root Certificate for each domain

• Unlimited subdomains

• Certificate revocation

When you are running your own Root CA, it is critical that your certificate be installed in your company’s web browsers and other applications that access other applications encrypted using your certificates. For each domain you create using my shell script, there is a ca.crt file that is created under the certificates directory. This ca.crt is a public key and can be freely distributed and installed within your company. Additionally there is a certificate revocation list titled ca.crl. This should also be made available to ensure that a certificate that has been revoked is properly blocked by the configured clients.

While this script functions well under Ubuntu 12.04 LTS, I have not tested under other distributions. I also wanted to add a feature to completely rekey an entire domain in the event of a compromised Root CA. Alas, I did not get around to it which is why I decided to write this article and share my work allowing for feedback and further development.

Feel free to take this script and modify it as your please. I only ask if you make improvements that you share them with me so that I can update this script.

 

The directory and file structure

I have typically kept this under the /etc/pki directory, but it does not really matter.

/etc/pki/pki_wt.sh

This file is the main shell script that uses Whiptail and OpenSSL commands for managing the PKI domain. The full script is available at the end of this article.

/etc/pki/pki_domains

 

This file contains a list of all active domains that are

managed by the pki_wt.sh script.

/etc/pki/example.com

Each domain will have its own folder

 

/etc/pki/example.com/openssl.cnf

Each domain has its own openssl.cnf file. If any configuration changes are desired for the domain, this is the guy to edit. The pki_wt.sh script creates this file and you can edit the defaults within that file.

/etc/pki/example.com/crlnumber

This file counts the number of revoked certificates by this CA.

/etc/pki/example.com/serial

This file counts the number of serials signed by this CA.

/etc/pki/example.com/index.txt

This file is a database of all serial numbers of certificates signed by this CA.

/etc/pki/example.com/certs

This folder is where all public keys are placed. They are created with a .crt extension and the ca.crt is also stored in this directory. As you create certificates for subdomains they will be stored here. For example, www.example.com.crt.

/etc/pki/example.com/certs/ca.crt

This file is the bread and butter for the domain. This file needs to be distributed to all systems that would verify the authenticity of the certificates created for this domain using the pki_wt.sh script.

/etc/pki/example.com/crl

This folder contains the ca.crl file

/etc/pki/example.com/crl/ca.crl

This file needs to be distributed to all systems that would verify whether the certificate being presented has

actually been revoked.

 

/etc/pki/example.com/csr

This folder contains the Certificate Signing Requests. These are generated when a private key is created for a domain. CSR files contain information about the private key that the CA uses when digitally signing the certificate generated from that private key. It is a way to pass information about the private key to the CA without having to provide the private key itself because sharing it would defeat the purpose of the private key. In our scenario the private key is on the same server as the CA, but it’s role is more critical when the CA is a third party.

/etc/pki/example.com/newcerts

This folder is a default place for new certificates. It is unused by the pki_wt.sh script.

/etc/pki/example.com/private

This folder is where all private keys are placed and strict access should be enforced. They are created with a .key extension and the ca.key is also stored in this directory. As you create certificates for subdomains their private keys will be stored here. For example, www.example.com.key.

/etc/pki/example.com/certs/ca.key

This file is the private key for the public key; ca.crt. Access to this file should be as limited as possible.

/etc/pki/example.com/revoked

When a private key for a domain has been compromised you will want to revoke that key and its certificate. WHen you do, they are placed in this folder.

/etc/pki/example.com/certs/[certs|csr|private]

These folders are where their corresponding file types are placed when a key has been revoked.

 

Understanding the OpenSSL Commands

 

Although you may never look at the contents of the pki_wt.sh script, for those that do this is a break down of the more complicated parts and the overall justification for writing this script; horrifically long OpenSSL commands. For the purpose of demonstration the domain used will be example.com and a private/public key pair will be generated for www.example.com and signed with the CA key file for example.com.

 

Creating a CA

Creating a New Private Key and CSR

Creating and Signing a New Certificate

Revoke a Certificate

Generate a New CRL File

 

Summary and Downloads

The biggest downside of managing your own PKI is being persistent in enforcing clients, users or other, to check the authenticity of your certificates. In addition, the CRL is often an overlooked and yet superbly critical aspect of PKI. If security is important for your organization then I suggest the following:

• Only generate certificates with some sort of signing CA.
• Put the CA certificate file and the CA revoke list on a web server unencrypted.
• Use a cronjob to periodically publish the CA revoke list and CA certificate file to the aforementioned web server.
• On clients, use a cronjob to periodically grabs these two files from the web server in order to be used for any scripts or programs.
• Lastly, with these two files easily accessed from a web browser it becomes pretty easy to install them in your user’s web browser.

A current copy of the complete script can be found at pki_wt.sh. Place it in /etc/pki/ and edit it as you see fit.