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.