pki overview

symmetric encryption vs asymmetric encryption

Let’s assume, we’re have 2 servers, and we’re should send encrypted data between them. We’re may create some password on both servers, for example “123”. With that password you can encrypt data, transmit via Internet, and decrypt on destination host. Notice, both passwords are same on each host. So it’s called symmetric encryption, because keys are symmetric, equal.

On the other hand exists asymmetric encryption – when two keys looks different, but you can encrypt data with first and decrypt with second. Key points are:

  • there is mathematical dependency between two keys
  • one called private key and other public key
  • you can encrypt data with public key and decrypt with private key
  • you can not encrypt data with private key and decrypt with public key
  • public key called – digital certificate, It is public, you can show it to any one, and it is OK
  • private key called .. private key, nobody should see it.
  • csr request file – it looks like public or private key, but it doesn’t used for encryption or identification, it is used to create logical connection between one pair of private and public keys and another pair of private and public keys

On these simple principles PKI infrastructure works.

Root Certificate Authority

And now we’re started from root Certificate Authority. You probably imagine it like physical dedicated server which, well-guarded, but no. Certificate Authority is a file. Say exactly, not file but again two files public and private keys, and again there is mathematical dependency between them. In Linux world exist openssl utility which can generate these keys.

Step 1. You generate private key of Root CA

Step 2. You generate certificate Root CA based on private key of Root CA, this certificate should be installed on users desktops.

Intermediate Certificate Authority

For purpose of security there is intermediate certificate authority, which acts as proxy for Root CA. According to PKI infrastructure, Root CA delegates certificate emission to intermediate CA. For intermediate CA creation you should follow these steps.

Step 1. You generate private key for Intermediate CA

Step 2. You generate csr file for Intermediate CA, based on private key for Intermediate CA

Step 3. You generate certificate for Intermediate CA, based on private key of Root CA and csr of Intermediate CA

Chain of CA

You can generate this chain as long as you like for the purpose of security. The last Intermediate Certificate Authority will issue the certificates for web sites. And one important thing you should keep in mind – all generated certificates of Intermediate Certificate Authorities (not certificates for web sites) should be merged in one file – it is certificate authority chain file, this file should be installed on web server.

In apache web server it looks like this:

SSLCertificateFile           /etc/pki/public.crt
SSLCertificateKeyFile     /etc/pki/private.key
SSLCertificateChainFile /etc/pki/intermediate.crt

In Nginx web server it looks like this:

ssl_certificate           /etc/pki/public.crt;
ssl_certificate_key   /etc/pki/private.key;

 

public.crt file contains certificate for web site and all CA chain.

Ok, now we’re have simple understanding what Certificate Authority is. Now our task is to install secure web server. Let’s assume we have created virtual machine and installed web server, in my case it is Nginx, and we’re need one file – private key. In order to generate this file – we will use openssl utility, but for understanding of how PKI works we’re don’t need to delve in details of how web servers works or how openssl command line works. Just think, that you generated private key by openssl command and webserver with some secure data is running.

And now we’re need second file, no, not public key, we’re need csr – certificate signing request, yes it like public key, but it is not. It is not secure file, you can show it to other people – it’s ok. With openssl utility you can generate private key and based on that private key, you can generate csr, and again there is mathematical dependency between these files. Next, csr we’re should send to server with intermediate CA, for example we’ve copied that csr file by ssh. By openssl utility we’re can generate public key based on private key of certificate authority and csr. After that, we’ve copied our new generated certificate with intermediate certificates of CA and CA public key to web server.

Now we may delete csr files on both hosts, we do not need them any more, it is temporary files. But one thing we’re should keep in mind – now we have mathematical dependency between all files!

Let’s go further, we will consider simple example, when you open secure web page, then these actions are process:

  1. there are two files on a web server – certificate with intermediate certificates and private key.
  2. browser requests https page, web server returns certificate with intermediate certificates to browser
  3. browser checks certificate with intermediate certificates with local certificate of root CA installed in OS.
  4. browser generates temporary hash, encrypts it with certificate and send to web server.
  5. web server decrypts hash with private key, and based on hash encrypt web content and send it to browser, and browser can decrypt content with temporary hash. During that exchange web content encrypt and decrypt with symmetric encryption.

 

 

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>