Subversion Repositories configs

Introduction to PKI
===================

This document is designed to give you a brief introduction into how a PKI, or
Public Key Infrastructure, works.

Terminology Used
----------------

To avoid confusion, the following terms will be used throughout the Easy-RSA
documentation. Short forms may be substituted for longer forms as convenient.

 *  **PKI**: Public Key Infrastructure. This describes the collection of files
    and associations between the CA, keypairs, requests, and certificates.
 *  **CA**: Certificate Authority. This is the "master cert" at the root of a
    PKI.
 *  **cert**: Certificate. A certificate is a request that has been signed by a
    CA. The certificate contains the public key, some details describing the
    cert itself, and a digital signature from the CA.
 *  **request**: Certificate Request (optionally 'req'.) This is a request for a
    certificate that is then send to a CA for signing. A request contains the
    desired cert information along with a digital signature from the private
    key.
 *  **keypair**: A keypair is an asymmetric cryptographic pair of keys. These
    keys are split into two parts: the public and private keys. The public key
    is included in a request and certificate.

The CA
------

The heart of a PKI is the CA, or Certificate Authority, and this is also the
most security-sensitive. The CA private key is used to sign all issued
certificates, so its security is critical in keeping the entire PKI safe. For
this reason, it is highly recommended that the CA PKI structure be kept on a
system dedicated for such secure usage; it is not a great idea to keep the CA
PKI mixed in with one used to generate end-entity certificates, such as clients
or servers (VPN or web servers.)

To start a new PKI, the CA is first created on the secure environment.
Depending on security needs, this could be managed under a locked down account,
dedicated system, or even a completely offline system or using removable media
to improve security (after all, you can't suffer an online break-in if your
system or PKI is not online.) The exact steps to create a CA are described in a
separate section. When creating a new CA, the CA keypair (private and public
keys) are created, as well as the file structure necessary to support signing
issued certificates.

Once a CA has been created, it can receive certificate requests from
end-entities. These entity certificates are issued to consumers of X509
certificates, such as a client or server of a VPN, web, or email system.  The
certificate requests and certificates are not security-sensitive, and can be
transferred in whatever means convenient, such as email, flash drive, etc. For
better security, it is a good idea to verify the received request matches the
sender's copy, such as by verifying the expected checksum against the sender's
original.

Keypairs and requests
---------------------

Individual end-entities do not need a full CA set up and will only need to
create a keypair and associated certificate request. The private key is not used
anywhere except on this entity, and should never leave that system. It is wise
to secure this private key with a strong passphrase, because if lost or stolen
the holder of the private key can make connections appearing as the certificate
holder.

Once a keypair is generated, the certificate request is created and digitally
signed using the private key. This request will be sent to a CA for signing, and
a signed certificate will be returned.

How requests become certificates
--------------------------------

After a CA signs the certificate request, a signed certificate is produced. In
this step, the CA's private key is used to digitally sign the entity's public
key so that any system trusting the CA certificate can implicitly trust the
newly issued certificate. This signed certificate is then sent back to the
requesting entity. The issued certificate is not security-sensitive and can be
sent over plaintext transmission methods.

Verifying an issued certificate
-------------------------------

After 2 entities have created keypairs, sent their requests to the CA, and
received a copy of their signed certificates and the CA's own certificate, they
can mutually authenticate with one-another. This process does not require the 2
entities to have previously exchanged any kind of security information directly.

During a TLS handshake each side of the connection presents their own cert chain
to the remote end. Each side checks the validity of the cert received against
their own copy of the CA cert. By trusting the CA root cert, the peer they are
talking to can be authenticated.

The remote end proves it "really is" the entity identified by the cert by
signing a bit of data using its own private key. Only the holder of the private
key is able to do this, allowing the remote end to verify the authenticity of
the system being connected to.