Public Key Infrastructure

Ján Štefkovič, 433387@mail.muni.cz

Content

Digital certificates of PKI

Digital certificates of Public Key Infrastructure are means to ensure confidentiality and integrity between entities.
In PKI, a trusted third party called a registration authority verifies the identity of a person or entity. Then it instructs the certificate authority (CA) to issue a digital certificate which contains that entities‘ public key. CA declares this certificate valid by signing it with its own root certificate. This certificate (and the public key contained therein) may subsequently be used to prove identity and enable secure communication with other parties.

Root CA has a self-signed certificate. Every other CA in the hierarchy has its certificate signed by the higher-level CA. A list of root certificates is present on every system that will use the PKI, so the system can verify if the certificate is signed by a trusted CA. If not, the certificate chain is followed up to the higher CA, until a trusted CA is found. This process ends at Root CA.

The structure of a certificate

The structure of the digital certificates is in conformance with the X.509 standard. The required fields creating the certificate areas follows:

How to get a certificate from a CA

There is an alternative called self-signed certificates. These should not be used in production environments.

  1. Create a private and public encryption key pair.
  2. Create a certificate request based on the public key. The certificate request contains information about your server and the company hosting it.
  3. Send the certificate request, along with documents proving your identity, to a CA and follow their instructions.
  4. When the CA verifies your claimed identity, they send you a digital certificate.
  5. Install this certificate on your secure server, and configure the appropriate applications to use the certificate.

Configuration on Ubuntu

This example will use OpenSSL, which is software under an Apache-style license.

Generating a Certificate Signing Request (CSR)

  1. Generate the keys:
    2. # openssl genrsa -des3 -out server.key 2048
    You will be prompted for a passphrase. The server key can then be found in the server.key file.
  2. (Optionally) Create a non-passphrase key:
    3. This insecure key can be used by service daemons to start without entering the passphrase. Use with caution!
    # openssl rsa -in server.key -out server.key.insecure
    # mv server.key server.key.secure
    # mv server.key.insecure server.key
    This renames server.key to server.key.secure and creates an insecure one under server.key.
  3. Create the CSR:
    4. # openssl req -new -key server.key -out server.csr
    After being prompted enter the passphrase (if any), Company Name, Site Name, Email Id... CSR is then created into the server.csr file. This file can be sent to a CA (which will issue the certificate) or used to create a self-signed certificate.

Creating a Self-Signed Certificate

# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
This command will create a certificate and store it in the server.crt file.

Installing

# sudo cp server.crt /etc/ssl/certs # sudo cp server.key /etc/ssl/private
This command will install the key and the certificate file (your own or the one issued by a CA). Application which will use the PKI can now be configured.
There is also a possibility to set up your own CA for your network.

Others

Another important thing is the possibility to revoke a certificate (= make it invalid before the expiration date). The two most common revocation methods are CRL and OCSP. CRL works with periodical publishing and checking a list of revoked certificates, while OCSP is a request-response system (for details see my bachelor thesis).

Literature