Establish multi-level Public Key Infrastructure using OpenSSL
In this short how-to guide we will establish a Public Key Infrastructure based on OpenSSL. To keep things simple and straight forward we only define two levels (although many more are possible):
- A Root Certification Authority which is only used to sign certificates of subordinate intermediary Certification Authorities
- An Intermediary Certificate Authority which is used to issue certificates for both servers and users
It should however be easy to modify the instructions below to your target implementation.
Creating a dedicated user for pki operations
For security reasons it is preferable to create a dedicated user for use with your PKI and to ensure that only this user (or group of users) has access to this location. In our setup we will create a user called pki and use the homedirectory for this account as root for the PKI.
sudo adduser pki chmod -R 0700 /home/pki/pki-root
Make sure you repeat the last command when the PKI setup is completed to ensure that no files or directories remain world readable.
A word about structure
The following directory structure is recommended as a skeleton for setting up a new PKI. Each Certificate Authority in your Public Key Infrastructure should have a directory structure similar to the one explained below.
PKI directory: Root directory for the OpenSSL PKI
CA directory : Root directory for the Certificate Authority
CA.db.tmp: Temporary directory for openssl operations. This directory will mainly be used to store intermediary .pem files.
CA.db.certs: Directory used to store generated certificates in .pem format. It is advised to create additional subdirectories corresponding to the common name of the generated certificate to hold certificates, private keys and other formats such as p12 containers for future reference.
CA.db.crl: Directory used to store certificate revocation lists generated by openssl.
Additionally the following files will need to be created for the CA to function properly.
CA.db.serial: File indicating serial to be used for the next generated certificate. The initial value should be 01.
CA.db.crlserial: File indicating serial to be used for the next CRL. The initial value should be 01.
CA.db.index: Text based database file used by OpenSSL to store details of all generated certificates. Initially this file should be empty.
CA.db.rand: File containing a random string which ensures the randomness of the CA. If security is of high importance it is recommended to use a hardware random key generator for this.
To simplify our setup we will consistently use the following naming and extension convention throughout our PKI:
.crt: File containing a certificate
.csr: File containing a Certificate Signing Request
.key: File containing a private key
.p12: Binary container with certificate, private key and ca chain
.pwd: File containing the password used to open the p12 container
The commands to put the above mentioned structure in place are mentioned below. Make sure you modify ca in the example to reflect the name of the CA you are putting in place and make sure you execute the commands within the proper location on the filesystem (in this example /home/pki/pki-root).
mkdir ca mkdir ca/ca.db.tmp mkdir ca/ca.db.certs mkdir ca/ca.db.crl echo 01 > ca/ca.db.serial echo 01 > ca/ca.db.crlserial touch ca/ca.db.index openssl rand -out ca/ca.db.rand 8192
Configure OpenSSL through openssl.cnf
The OpenSSL configuration file allows us to (pre-)define many of the settings related to our Certificate authority. Although many of these options can equally be set using command line parameters we can simplify our command lines and standardise the creation of certificates by using the configuration file.
We will define the following aspects of our Certification Authority through the configuration file:
- The Certification Authorities making up our Public Key Infrastructure and their related settings such as base directories and files.
- The policies to be applied to certificate requests, indicating which fields are optional, mandatory and/or should match the Certification Authorities values.
- The standard certificate request parameters to be used.
- The extensions to be used when generating specific types of certificates.
Let us create the OpenSSL file and place it in our root PKI directory (/home/pki/). The OpenSSL configuration file should start with a entry indicating which Certification Authority should be used by default is none is specified during certificate generation.
[ ca ] default_ca = CA # The default ca section
As a next step we need to introduce a CA configuration section for each of the CA’s which make up our Public Key Infrastructure.
Note: if your PKI only consists of one CA you should only create one section.
Note: Make sure to replace CA with the name of the Certification Authority you are implementing, in our example RootCA and IntermCA.
[ CA ] dir = ./CA # Where everything is kept certs = $dir/ca.db.certs # Where the issued certs are kept crl_dir = $dir/ca.db.crl # Where the issued crl are kept database = $dir/ca.db.index # database index file. unique_subject = no # Set to 'no' to allow creation of several ctificates with same subject. new_certs_dir = $dir/ca.db.certs # default place for new certs. certificate = $dir/ca.crt # The CA certificate serial = $dir/ca.db.serial # The current serial number crlnumber = $dir/ca.db.crlserial # the current crl number must be commented out to leave a V1 CRL private_key = $dir/ca.key # The private key RANDFILE = $dir/ca.db.rand # private random number file name_opt = ca_default # Subject Name options cert_opt = ca_default # Certificate field options default_days = 365 # how long to certify for default_crl_days = 60 # how long before next CRL default_md = md5 # use public key default MD preserve = no # keep passed DN ordering policy = policy_match
The options, policy match and unique subject are most commonly used for root certification authorities since you will want the attributes of the intermediary CA’s to match the root CA and to ensure that you have a unique subject. These two options should potentially be modified for intermediary CA’s.
Make sure to modify the relevant values to reflect the configuration of the CA’s you want to put in place. Additionally it is advisable to modify the default_ca parameter to contain the CA you want to use for signing certificates by default.
Once we defined the CA’s we have the option of creating a policy which will be applied to certificate signing requests. By default the OpenSSL configuration file contains two policies called policy_match and policy_anything.
The first requires the request to match most of the values present in the CA certificate such as country name, state or province etc.
The latter imposes no restrictions on the content of the certificate signing request.
[ policy_match ] countryName = match stateOrProvinceName = match localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional
Let’s go ahead and define our own policy which is to be used when signing user certificates. Feel free to modify the template below to match whatever requirements you want to put on specific types of certificate signing requests.
[ policy_usr ] countryName = supplied stateOrProvinceName = supplied localityName = supplied organizationName = supplied organizationalUnitName = optional commonName = supplied emailAddress = supplied
With our CA’s and policies in place it’s time to define the ‘default’ request parameters. Modify the parameters below to reflect your organisation
[ req ] default_bits = 2048 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # The extentions to add to the self signed cert string_mask = nombstr [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = BE countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Vlaams-Brabant localityName = Locality Name (eg, city) localityName_default = Leuven 0.organizationName = Organization Name (eg, company) 0.organizationName_default = AUSY 1.organizationName = Second Organization Name (eg, company) 1.organizationName_default = not used organizationalUnitName = Organizational Unit Name (eg, section) organizationalUnitName_default = Demo CA project commonName = Common Name (eg, YOUR name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 [ req_attributes ] # challengePassword = A challenge password # challengePassword_min = 4 # challengePassword_max = 20 # unstructuredName = An optional company name
As a final step we have the option of defining specific extensions, contstraints and comments for specific certificate types. Below you find an example of server and user certificate types and their specifics. Make sure to modify the crlDistributionPoints and/or comment to reflect your environment.
[ srv_cert ] basicConstraints=CA:FALSE nsCertType = server crlDistributionPoints = URI:http://example.com/crl.pem nsComment = "OpenSSL Generated Server Certificate" [ usr_cert ] basicConstraints=CA:FALSE nsCertType = client, email nsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always
The v3req, v3ca and crlext definitions are required for OpenSSL to function properly. These sections define the basic configuration for a common certificate request and the required extensions to generate a CA certificate. The crlext section defines how CRL’s are generated.
[ v3_req ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment [ v3_ca ] # Extensions for a typical CA subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always basicConstraints = CA:true [ crl_ext ] # CRL extensions. authorityKeyIdentifier=keyid:always,issuer:always ## Establishing our CA’s ### Setup Root CA
Create Root CA public / private keypair
openssl genrsa -des3 -out ./RootCA/RootCA.key 2048
Generate Root CA certificate, which is by definition a self signed certificate. Don’t forget to modify the validity to an appropriate value.
openssl req -new -x509 -days 3650 -key ./RootCA/RootCA.key -out ./RootCA/RootCA.crt -config openssl.cnf
Setup intermediary CA(’s)
Create Intermediate CA public / private keypair
openssl genrsa -des3 -out ./RootCA/RootCA.db.certs/IntermCA/IntermCA.key 2048
Generate Certificate Siging Request for intermediary CA. Don’t forget to modify the validity to an appropriate value.
openssl req -new -days 1095 -key ./RootCA/RootCA.db.certs/IntermCA/IntermCA.key -out ./RootCA/RootCA.db.certs/IntermCA/IntermCA.csr -config openssl.cnf
Sign the previously generated CSR using the RootCA while adding the CA extension to ensure that the resulting certificate can be used to sign other certificates.
openssl ca -config openssl.cnf -name RootCA -extensions v3_ca -out ./RootCA/RootCA.db.certs/IntermCA/IntermCA.crt -infiles ./RootCA/RootCA.db.certs/IntermCA/IntermCA.csr
Now copy over the relevant certificate and key to the IntermCA root.
cp ./RootCA/RootCA.db.certs/IntermCA/IntermCA.crt ./RootCA/RootCA.db.certs/IntermCA/IntermCA.key ./IntermCA/
It’s recommended to create a certificate chain file for future use. This file can be imported by a client and will indicate the full chain of Certification Authorities linked to the provided certificate.
That’s it, all relevant bits and pieces should be in place to start using our OpenSSL PKI. In this section you will find some common operations and the related openssl commands.
Generate server certificate
openssl req -newkey rsa:2048 -keyout ./IntermCA/IntermCA.db.certs/server.domain/server.domain.key -nodes -config openssl.cnf -out ./IntermCA/IntermCA.db.certs/server.domain/server.domain.csr
openssl ca -config openssl.cnf -name IntermCA -out ./IntermCA/IntermCA.db.certs/server.domain/server.domain.crt -infiles ./IntermCA/IntermCA.db.certs/server.domain/server.domain.csr
Generate user certificate
openssl req -newkey rsa:2048 -keyout ./IntermCA/IntermCA.db.certs/username/username.key -nodes -config openssl.cnf -out ./IntermCA/IntermCA.db.certs/username/username.csr
'' openssl ca -config openssl.cnf -extensions usr_cert -name IntermCA -out ./IntermCA/IntermCA.db.certs/username/username.crt -infiles ./IntermCA/IntermCA.db.certs/username/username.csr
openssl pkcs12 -export -clcerts -in ./IntermCA/IntermCA.db.certs/server.domain/server.domain.crt -inkey ./IntermCA/IntermCA.db.certs/server.domain/server.domain.key -certfile ./pki.crt -out ./IntermCA/IntermCA.db.certs/server.domain/server.domain.p12
openssl ca -config openssl.cnf -name IntermCA -revoke ./IntermCA/IntermCA.db.certs/02.pem
openssl ca -config openssl.cnf -name IntermCA -gencrl -out ./IntermCA/IntermCA.crl/crl-27.02.2014.pem
Generate CA chain
cat ./RootCA/RootCA.crt ./IntermCA/IntermCA.crt > pki.crt
... Regularly reinventing a slightly different wheel ...