wiki:How_does_PKI_work

[DRAFT] PKI - How does it work?

PKI, or Public Key Infrastructure, is a way to establish trust with whom you are communicating. Imagine talking to a complete stranger in the street. You cannot be completely sure you can trust what that person says, and you probably wouldn't want to share secrets with that person, without some confidence that this person is trustworthy. If you have a good common friend, which you have ultimate trust in, and this friend can guarantee to you that this person is a trustworthy, then it makes it easier to trust and share information with this stranger.

The PKI model is basically the same. If you are the client and you need to communicate with a server, how can you be sure you communicate with the correct server? If both of you can confirm each others' identity by providing a certificate, this trust can be ensured if both of you trust the third party which provided you with your certificates. This third party is the Certificate Authority (CA).

It's (almost) all about Certificates

PKI is very much centered around certificates. A certificate is always signed by a CA. But what is a certificate? It's basically a collection of information which can be verified. This is typically the information you can find in a certificate:

  • Version
  • Serial Number
  • Algorithm ID
  • Issuer
  • Validity
    • Not Before
    • Not After
  • Subject
    • Common name (required)
    • Location (optional)
    • Organisation (optional)
    • Organisation unit (optional)
    • ...
  • Subject Public Key Info
    • Public Key Algorithm
    • Subject Public Key
  • Issuer Unique Identifier (optional)
  • Subject Unique Identifier (optional)
  • Extensions (optional)
    • ...
  • Certificate Signature Algorithm
  • Certificate Signature

The Certificate Authority

The CA is the most sacred piece of the PKI. The persons operating a CA, needs to validate that incoming signing requests are authentic, coming from persons they can trust and who can identify themselves. The CA have a private key which therefore must be protected as much as possible. This private CA key is the foundation of the trust, as this is used to issue certificates to servers and clients. If this private CA key leaks out, the CA is considered compromised and can no longer be trusted. In such a case where a private CA key have leaked, an unknown third party can generate certificates claiming to be authorised by the people operating the CA.

The purpose of the CA is to provide a trust level that everyone who have a certificate issued by them, are who they claim to be.

Preparing a CA

The CA itself are just files. It consists of a CA private key, CA public key and a CA certificate. And lets say it again, teh CA private key is the most sacred file you will ever have your hands on, this must under no circumstances get lost. If you loose that file, you have lost the credibility of your CA.

The CAs can operate in a chain, where a CA can be the root CA. In this case the CA certificate is self-signed. This means that it cannot point at anyone else that it is who it claims to be. If the CA certificate is signed by a different CA, it means that the CA certificate is signed by a superior CA which can confirm the authenticity. Further in this little document, only root CA/self-signed CA certificates will be considered.

There are more alternatives to setup a CA. OpenVPN ships with easy-rsa. And there are other alternatives such as XCA, ssl-admin and TinyCA. We will not cover how to configure either of these, but describe the process in general.

The steps to generate a root CA are:

  1. Generate a CA private key
  2. Generate a self-signed certificate, with the CA flags set

The CA flag is important here, as that tells clients and servers reading your CA certificate that it can be used to validate server/client certificates.

The CA certificate is to be distributed to your OpenVPN clients and servers. But the CA private key must be kept secret. And it is strongly recommended to store all these files in a off-line media. If your CA private key is lost, your CA is to be considered compromised and you need to start all over again and re-issue certificates to all clients and servers again.

Servers and their certificates

The server needs to have a private key, its certificate and the CA certificate. The first step is to generate a new private key. This private key is specific to this server. To get such a needed certificate, the server needs to generate a Certificate Signing Request (CSR). This is a file which needs to be sent to your CA. The contents of this file is a public key derived from the private key. This makes it possible to encrypt information, but to decrypt you need the private key. In addition the CSR will contain hostname information, location and other information needed to identify the server. It is also a server flag set in the CSR which will later be used to differentiate servers from clients. This information is then signed using the private key. Since the public key is also attached, the CA can validate that the information haven't been modified afterwards.

When the CA processes your CSR, all this information provided in the CSR needs to be verified. When the person operating the CA finds good enough, the CA will sign this CSR with it's private key. And the output will be the information from the CSR, the servers public key and the CA signature. All this is stored inside a certificate file (CRT) which is sent back to the server, together with the CA certificate.

When somebody connects to the server the server will send them the server certificate. If the client have a copy of the CA certificate, it can validate the authenticity of the server. If the signature is valid, and you trust the CA certificate, then you can trust this "random" server. The next steps is to check that the server flag in the certificate is set, and that the hostname of the server you connected to matches the server name given in the certificate (which is contained in the Common Name/CN field).

If the server later on replaces its private key, it needs to send a new CSR to the CA and get a new CRT. This way, clients can still trust the server, as the servers certificate is still signed by the same CA. If the server changes its hostname, a new CSR needs to be sent, with the new hostname as well.

When configuring the OpenVPN server, the files needed here are server key, server certificate and the CA certificate.

Clients and their certificates

This process is basically the same as for the servers, with the exception that it needs a client flag set instead of the server flag. This is to ensure that clients can't pose as servers and vice versa. The common name field which was used to identify the server name can be more freely chosen for client certificates, though. It can be the full name of the person this certificate is intended for, or the hostname of the client the user is expected to use. This information can later on be used for further validation and identification on the server side, so think twice here before settling down on a specific scheme.

When configuring the OpenVPN client, the files needed are client key, client certificate and the CA certificate.

Invalidating certificates

From time to time you need to invalidate certificates, for different reasons. A person who used the VPN setup don't need this access any more, a laptop with the certificate got stolen or the clients certificate was somehow lost. Any issued certificate are valid as long as they haven't expired, even if all files are deleted. And if someone claims to have deleted all the files, can you really be sure that this person don't have a backup anywhere? In these situations you need to revoke the certificate validity. This is done by issuing a Certificate Revocation List (CRL) to your OpenVPN server.

The CRL is also a small file, which contains a list over all certificates which should be considered invalid. This file is generated by the CA. The list of certificate is then signed by the CA key. At this point, it is not possible un-revoke a certificate. The only thing which can be done in this case is to generate a new certificate, but it can be based on the same CSR which was initially received.

To revoke a certificate, you need access to the certificate file you want to revoke and your CA files. The CA too you choose to use will take care of generating the CRL file. This file can then be distributed to your OpenVPN server(s).

Last modified 5 years ago Last modified on 07/28/12 07:07:28