9Creating and managing certificates

It is assumed that the reader has an extensive knowledge of certificates, certificate creating and public key encryption.

This chapter explains the usage of OpenSSL to create certificates.

It is important to note that mdm requires two different types of certificates and keys:

–Certificates and keys used to secure the communication between the mdm compo­nents

–Certificates and keys used for the PKI

How to create certificates and keys to be used for the SSL communication is explained in Chapter 9.1. The certificates and keys used in a PKI are described in Chapter 9.2.

Keystores

Certificates and keys are stored in databases called keystores. A keystore is a file, contain­ing the certificates and keys in encrypted form. To access the information in a keystore a passphrase is required. Keystores can have different formats, common formats are e.g. PKCS#12 or the proprietary Java KeyStore format (JKS). The encryption algorithm can usu­ally be selected when creating the keystore. AES256 is recommended.

The OpenSSL configura­tion file

OpenSSL uses default values specified in the configuration file openssl.cnf (the directory where this file is located depends on your distribution, e.g. check in the directory /usr/ssl or /usr/lib/ssl).

If you omit mandatory arguments of a command, OpenSSL uses the default settings defined in the configuration file. If possible, all mandatory arguments for the example commands below are explicitly stated, i.e. if you use the commands as described below the important information is taken from the command line and not from the configuration file. If the config­uration file is required for the respective command it is explicitly mentioned in the text.

For further information about the syntax and content of the configuration files, please refer to OpenSSL's documentation, particularly to the manual pages genrsa(1ssl), req(1ssl), ca(1ssl) and openssl(1ssl).

9.1Certificates and keys for SSL

To set up a secure connection between entities (e.g. ET1, ET2) usually the following com­ponents are required:

–a private key for each entity participating in the communication:

–ET1_key

–ET2_key

The term private key already implies that it is important to keep these keys private and store them at a location only accessible to the administrator.

–and the corresponding certificates:

–ET1_cert

–ET2_cert

The certificates contain among other information

–the public key of the entity

–information about the entity, e.g. the name and/or the IP address

–further information about the certificate, e.g. the intended usage

The certificate is either digitally signed with the private key of the respective entity (self-signed) or with a CA key.

The certificates are public and can be distributed to anyone participating in the commu­nication.

ET1 will use the public key contained in ET2_cert to encrypt the data sent to ET2. This assures that only ET2 is able to decrypt the data. If ET2_cert is self-signed it is assured that public key contained in ET2_cert corresponds to ET2_key. If ET2_cert is signed by a CA it is assured that the public key contained in ET2_cert really belongs to ET2 (authentication).

Create the private key

ET_key has to be created first using the following command:

openssl genrsa -aes256 -passout pass:yourSSLPW -out privkey.pem 2048

Explanation of the arguments

:

The command above generates one output file: privkey.pem

This file contains ET_key in PEM format. The key is encrypted with the AES256-algorithm. To access the key you have to know the passphrase specified above (in the example: yourSSLPW). Please use your own, secure password to encrypt the private key.

Create the certificate

The certificate is created with the following command:

openssl req -batch -new -x509 -key privkey.pem -keyform PEM
-passin pass:yourSSLPW -sha256 -outform PEM -out serverCert.pem

Explanation of the arguments:

The command above generates one output file: serverCert.pem

This file contains the self-signed certificate ET_cert.

Create a keystore

The keys and certificates have to be included in keystores. The installation archive mdm-ca-1.11.x.zip contains the (proprietary) java tool ImportKey in the demoCA directory which can be used to create and manage keystores. Please copy the file ImportKey.class to your working directory.

First ET_key has to be converted to PKCS#8 format and both ET_key and ET_cert have to be in­cluded in a keystore. In the example, Java KeyStore format (JKS) is used. This can be ac­complished with the tool ImportKey. ImportKey does accept the (unencrypted) key on stan­dard input only, therefore the output of the pkcs8 command has to be piped as follows:

openssl pkcs8 -topk8 -in privkey.pem -passin pass:yourSSLPW 
-inform PEM -nocrypt -outform DER |java -cp . ImportKey 
-alias yourAlias -storetype JKS -keystore serverKeystore.jks 
-storepass pass:yourSSLPW -keypass pass:yourSSLPW 
-chain serverCert.pem

Explanation of the openssl arguments:

Explanation of the ImportKey arguments:

The command above generates one output file: serverKeyStore.jks

This is the keystore containing the certificate and the private key.

Import a certificate

After creating the keystore it is sometimes necessary to import additional certificates into the keystore. This can be accomplished by using the following command:

java -cp . ImportKey -alias yourAlias -storetype JKS
-file additionalCertificate.pem -storepass pass:yourSSLPW
-keystore serverKeystore.jks

Explanation of the ImportKey arguments:

9.2Certificates and keys for a PKI

When rolling out a Private Key Infrastructure (PKI), which is basically your intent when using the mdm CA, there are more requirements to be taken into account than mentioned in the previous chapter. This chapter first describes some of the PKI basics and then the usage of OpenSSL to roll out a PKI.

PKI basics

Among others the main reasons for using a PKI are:

–Authentication

When communicating using data networks it is in most cases not possible to “see” the entity on the remote side (exception: video telephony), i.e. one cannot be sure that the entity on the remote side is the one it claims to be. The usage of a PKI assures the au­thenticity of the entities communicating with each other.

–Data confidentiality

This is the reason VPNs are used to exchange data: The data packets are sent “in the public” (Internet), but unauthorized entities are prevented from accessing the informa­tion contained in the packets.

–Data integrity

The assurance that the information received is identical to the information sent by the other entity. This prevents information to be altered by an entity “in the middle” which is not authorized to participate in the communication.

It is beyond the scope of this document to describe all components and their interactions involved in a complete PKI, therefore only the most important are mentioned here:

–Certificates and private keys

Certificates are the means in a PKI to assure authentication. The identity of the certifi­cate owner is approved by a CA by signing the certificate request of the respective owner. The public and private keys are used to encrypt/decrypt data and therefore as­sure data confidentiality.

–Certification Authority (CA)

A Certification Authority is a component in a PKI which assures authenticity of the par­ticipating entities by signing certificate requests (i.e. issuing certificates). Usually there are multiple CAs in a PKI organized in a hierarchical structure with one root CA at the top.

–CRL Distribution Points (CDP)

See the following section Certificate extensions.

–Entities communicating with each other

The entities using a PKI use certificates to authenticate themselves and use the pub­lic/private key pairs to encrypt/decrypt the exchanged data. The entities request certif­icates from the CA. Usually a Registration Authority (RA) is also part of a PKI. The RA is responsible for the initial registration of entities that would like to use the PKI. An RA is not required in the mdm usage scenario.

Contents of a certificate

As mentioned in the previous chapter a certificate contains the following information:

–the public key of the entity

–information about the entity, e.g. the name and/or the IP address

–further information, e.g. about the certificate and the infrastructure

The following sections explain the contents in more detail.

The Subject Distinguished Name

The Subject Distinguished Name is a unique identifier of the certificate and its owner. It is composed of several components:

Depending on your policy, not all of the components are mandatory, but if the extension Subject Alternative Name is not included in the certificate, at least one component that can be used as identifier has to be included, typically this is the Common Name (CN). Please note that currently the mdm CA cannot handle certificates with Subject Alternative Name ex­tensions.

Certificate extensions

Information about the certificate or the infrastructure is contained in the so called certificate extensions. Basically anyone can define its own extensions, but the standard extensions (X.509version3) are defined in RFC 3280 Internet X.509 Public Key Infrastructure - Certifi­cate and CRL Profile. Here is a short description of the extensions that are important for the mdm CA:

–Critical Bit

The Critical Bit is not an extension but used to force the usage of extensions in the cer­tificate. The Critical Bit can be set for any extensions in the certificate. Applications ver­ifying a certificate must be able to interpret an extension with the Critical Bit. If the ap­plication is not able to interpret the extension, the certificate must be rejected.

–Basic Constraints

The Basic Constraints extension is used to indicate whether the certificate is a CA cer­tificate or not. Basic Constraints consists of 2 fields:

–cA field of type BOOLEAN and

–pathLenConstraint field (optional) of type INTEGER

For CA certificates the cA field must be set to true. pathLenConstraint is only used if the cA field is set to true and specifies the number of CA levels allowed below this certifi­cate. Basic Constraints should be always marked as critical.

Please refer to Chapter 9.2.3 for requirements regarding the Basic Constraints exten­sion.

–Key Usage

Key Usage controls the intended use of the certificate’s corresponding keys. A key can be e.g. used to sign Certificate Revocation Lists (CRL), encrypt data or to sign certifi­cates.

Please refer to Chapter 9.2.3 for requirements regarding the Key Usage extension.

–Subject Alternative Name

The extension Subject Alternative Name can be used to add more identifiers to the cer­tificate. Subject Alternative Name can contain e.g. e-mail addresses, domain names etc. It can be used as substitute for the Subject as well, which must be empty in this case. Please note that the mdm CA is currently not able to handle Subject Alternative Name extensions.

–CRL Distribution Points (CDP)

Certificates can be revoked, e.g. if a private key was compromised or if it is no longer valid. Usually an application has to check whether a certificate is still valid, by checking the validity period and/or by retrieving revocation information from a CRL distribution point (CDP). To retrieve the information either Certificate Revocation Lists (CRL) can be used or a dedicated protocol like OCSP. However, the certificate should contain the information, which CDP should be contacted.

–Authority Information Access

Authority Information Access is not an X.509 standard extension, but an extension de­fined by the PKIX working group (http://www.ietf.org/html.charters/pkix-charter.html). Authority Information Access contains information about the issuing CA, e.g. policies, further root certificates or where to retrieve the higher certificates in the chain, if the complete chain is not contained in the certificate.

Depending on the settings of these extensions the receiver (not the owner) of a certifi­cate accepts or denies the communication with the peer, thus preventing any misuse of certificates and creating a higher level of security.

9.2.1Create the CA certificates

Depending on your existing infrastructure the mdm CA needs the following certificates:

–A self-signed root certificate (CA_rootCert) and the matching private key (CA_rootKey).

If you have another upstream (root) CA in place, there is no need to generate the root certificate and the matching private key.

The (self-signed) root certificate is distributed to all entities participating in the commu­nication. It is used by the entities to verify the authenticity of the communication peer and of any intermediate CAs in the certificate chain. The private key CA_rootKey is used to sign the self-signed root certificate.

–A CA certificate (CA_cert) and the matching private key (CA_key). This is the certificate used by the CA to authenticate itself to other entities. This certificate has to be signed with the root private key, i.e. either with CA_rootKey or with the key of your existing root CA. The private key CA_key is used to sign the certificate request sent by the mdm serv­er, i.e. it is used to issue certificates for the mGuards.

–A template certificate (CA_templCert) which is used by the CA as template when issuing end entity (mGuard) certificates.

Figure 9-1 shows the certificate hierarchy:

Figure 9-1: mdm CA certificate hierarchy

In the following it is assumed that there is no other root CA in place and that the mdm CA is used as root CA.

Create the root certificate

The following OpenSSL commands require input from the OpenSSL configuration file openssl.cnf (the directory where this file is located depends on your distribution, e.g. check in the directory /usr/ssl or /usr/lib/ssl). Instead of changing the standard configuration file of your OpenSSL installation, it is recommend to use the example configuration files provided in the mdm CA installation archive mdm-ca-1.11.x.zip and adapt those files to your needs. You can instruct OpenSSL to use the provided configuration files instead of the standard configuration file.

Adapt the OpenSSL configuration file

Please copy the file rootCert.conf provided in the installation archive
mdm-ca-1.11.x.zip to your working directory. Adapt the [ root_dn ] section of the file, which contains the Subject Distinguished Name of your root CA certificate:

[ root_dn ]

C= DE

O= Innominate Security Technologies AG

OU= Research & Development

CN= Test Root CA

Please note also the [ root_ext ] section of the configuration file, which is important for the proper generation of the root certificate (please refer to Section Certificate extensions for an explanation):

[ root_ext ]

keyUsage= cRLSign, keyCertSign

basicConstraints= critical, CA:true, pathlen:1

Generate the private key

CA_rootKey has to be created first using the following command:

openssl genrsa -aes256 -passout pass:rootPW
-out rootKey.pem 2048

Explanation of the arguments:

The command above generates one output file: rootKey.pem

This file contains CA_rootKey in PEM format. The key is encrypted with the AES256-algorithm. To access the key you have to know the passphrase specified above (in the example: rootPW). Please use your own, secure password to encrypt the private key.

Generate the root certificate

The OpenSSL command used to generate CA_rootCert is:

openssl req -batch -new -config rootCert.conf -x509
-key rootKey.pem -keyform PEM -passin pass:rootPW -sha256 -days 5479 -outform PEM -out rootCert.pem

Explanation of the arguments:

The command above generates one output file: rootCert.pem

This file contains the self-signed root certificate CA_rootCert.

Create the CA certificate

The intermediate CA certificate CA_cert is not self-signed but will be issued (signed) by the root CA. Therefore you first have to create a private key and a corresponding certificate re­quest and then “send” this certificate request to the root CA. The root CA will in return issue CA_cert.

First the configuration file has to be adapted to your needs, as described in the previous sec­tion.

Adapt the OpenSSL configuration file and the environment

Please copy the file caCert.conf contained in the installation archive
mdm-ca-1.11.x.zip to your working directory. Adapt the [ ca_dn ] section of the file, which contains the Subject Distinguished Name of your root CA certificate:

[ ca_dn ]

C= DE

O= Innominate Security Technologies AG

OU= Research & Development

CN= Test CA

Please adapt also entries crlDistributionPoints and authorityInfoAccess of the [ ca_ext ] section of the configuration file (please refer to Section Certificate extensions for an explanation):

[ ca_ext ]

crlDistributionPoints=URI:http://ca.example.com/ca-ca.crl

authorityInfoAccess=OCSP;URI:http://ca.example.com/ocsp/ca-ca

The configuration file contains some parameters, which cannot be entered on the command line. The entries specify files that have to be present in the file system. Therefore the files have to be created manually first (the filenames are also used in the configuration file ca­Cert.conf , therefore please use exactly the file names as stated below):

–Create a subdirectory archive in your working directory
(Linux: mkdir ./archive)

–Create a file named serial containing a valid serial number for the certificate in the sub­directory archive
(Linux: echo 1234 > archive/serial)

–Create an empty file to be used as openssl database.
(Linux: touch archive/index.txt
Windows: copy NUL: archive/index.txt)

Generate a private key

The private key CA_key has to be created first using the following command:

openssl genrsa -aes256 -passout pass:caPW -out caKey.pem 2048

Explanation of the arguments:

This command generates one output file: caKey.pem

This file contains CA_key in PEM format. The key is encrypted with the AES256-algorithm. To access the key you have to know the passphrase specified above (in the example: caPW). Please use your own, secure password to encrypt the private key.

Generate a certificate request

To create a certificate request enter the following command:

openssl req -batch -new -config caCert.conf
-key caKey.pem -keyform PEM -passin pass:caPW -sha256
-out caCertReq.pem -outform PEM

Explanation of the arguments:

The command above generates one output file: caCertReq.pem

This file contains the certificate request.

Request the CA certificate

The request has to be sent to the root CA. Since the mdm CA is the root CA in the example you can issue the certificate with the following command:

openssl ca -batch -config caCert.conf -days 3653
-in caCertReq.pem -cert rootCert.pem -keyfile rootKey.pem
-passin pass:rootPW -md sha256 -notext -out caCert.pem
-outdir .

Explanation of the arguments:

The command above generates one output file: caCert.pem

This file contains CA_cert.

Create a certificate tem­plate

The purpose of the CA is to issue certificates. To do so the CA needs instructions how the certificates to be issued should look like, e.g. which extensions should be included. This can be accomplished by providing the CA with a certificate template (CA_templCert). CA_templCert is a certificate issued by the CA. To issue a certificate you first have to adapt an OpenSSL con­figuration file again.

Adapt the OpenSSL configuration file

Please copy the file templateCert.conf contained in the installation archive
mdm-ca-1.11.x.zip to your working directory. Adapt the entries crlDistribution­Points and authorityInfoAccess of the [ template_ext ] section of the configuration file (please refer to Section Certificate extensions for an explanation):

[ template_ext ]

crlDistributionPoints=URI:http://ca.example.com/ca-ee.crl

authorityInfoAccess=OCSP;URI:http://ca.example.com/ocsp/ca-ee

Generate a private key

The private key has to be created first using the following command:

openssl genrsa -aes256 -passout pass:caPW -out templateKey.pem 2048

Explanation of the arguments:

This command generates one output file: templateKey.pem

This file contains the encrypted private key.

Generate a certificate request

To create a certificate request enter the following command:

openssl req -new -batch -config templateCert.conf
-key templateKey.pem -keyform PEM -passin pass:caPW
-sha256 -outform PEM -out templateCertReq.pem

Explanation of the arguments:

The command above generates one output file: templateCertReq.pem

This file contains the certificate request.

Request the template certificate

The request has to be sent to the (intermediate) CA. You can sign the certificate request (is­sue the certificate) with the following command:

openssl ca -batch -config templateCert.conf -days 1826
-md sha256 -in templateCertReq.pem -keyfile caKey.pem
-cert caCert.pem -passin pass:caPW -notext
-out templateCert.pem -outdir .

Explanation of the arguments:

The command above generates one output file: templateCert.pem

This file contains CA_templCert. The file should be copied to its final destination, the location must be configured in ca-preferences.xml in the node certificateFactory » certTemplate.

9.2.2Create the keystores

After following the steps described in Chapter 9.2.1 you should find the following files in your working directory:

–templateCert.pem
This file contains CA_templCert, signed with CA_key.

–caCert.pem
This file contains CA_cert, signed withCA_rootKey.

–caKey.pem
This file contains CA_key.

–rootCert.pem
This file contains the self-signed root certificate CA_rootCert.

–rootKey.pem
This file contains the encrypted private root key CA_rootKey.

Some of those files have to be included in keystores. The installation archive mdm-ca-1.11.x.zip contains the (proprietary) java tool ImportKey in the demoCA directory which can be used to create and manage keystores. Please copy the file ImportKey.class to your work­ing directory.

First the intermediate CA certificate and the root certificate have to be merged into one file (create a certificate chain):

cat caCert.pem rootCert.pem > caCertWithChain.pem

Then the key caKey.pem has to be converted to PKCS#8 format and both CA_key and the certificate chain have to be included in a PKCS#12 keystore. This can be accomplished with the tool ImportKey. ImportKey does accept the (unencrypted) key on standard input only, therefore the output of the pkcs8 command has to be piped as follows:

openssl pkcs8 -topk8 -in caKey.pem -passin pass:caPW
-inform PEM -nocrypt -outform DER |
java -cp . ImportKey -alias ca -keystore ca-keystore.jks -storetype JKS -storepass pass:caPW -keypass pass:caPW
-chain caCertWithChain.pem

Explanation of the openssl arguments:

Explanation of the ImportKey arguments:

The command above generates one output file: ca-keystore.jks

This is the keystore for your CA containing the certificate chain and the private CA key. Please copy the keystore to its final destination.

–The filename including the absolute or relative path of this keystore has to be con­figured in the ca-preferences.xml file in the node certificateFactory » keyStore.

–The password to access the keystore (in the example caPW) has to be configured in the ca-preferences.xml file in the node certificateFactory » keyStorePassword.

–The format of this keystore (Java KeyStore – JKS) has to be configured in the ca-preferences.xml file in the node certificateFactory » keyStoreType.

–The password to access the private key (in the example caPW) has to be config­ured in the ca-preferences.xml file in the node certificateFactory » keyPassword.

–The alias (ca) of the key has to be configured in the ca-preferences.xml file in the node certificateFactory » keyAlias.

9.2.3Requirements for certificates

For proper function of the VPN certificates also with future versions of the mGuard firmware and the mdm, the certificates have to satisfy the following requirements:

1.The private key should have a length of at least 1024 bits. Phoenix Contact recom­mends a key length of 2048 bits for long term security.

2.Any certificate must conform to RFC 3280.

3.Any CA certificate must contain a Basic Constraints extension marked as critical and with the boolean cA field set to true.

4.Phoenix Contact strongly recommends to include the pathLenConstraint field in any CA certificate's Basic Constraints extension. It must be set to one less than the number of descendant CA certificates. So for a typical scenario where a certification chain is made up of one root CA certificate, a single intermediate CA certificate and an end entity cer­tificate (VPN certificate in this case), the pathLenConstraint must be one (1) for the root CA certificate and zero for the intermediate CA certificate.

5.The template VPN certificate must have a Basic Constraints extension marked as crit­ical with the boolean cA field set to false and without a pathLenConstraint field.

6.Any CA certificate must contain a Key Usage extension marked as critical with the bit keyCertSign set. It is recommended to have the bit cRLSign set as well.

7.The template VPN certificate does not need to contain any Key Usage extension.

8.Any intermediate CA certificate must contain one or both of the extensions CRL Distri­bution Points and Authority Information Access, if it is planned to distribute revocation information online with a future release of the mdm and the mGuard firmware. The ex­tensions must be marked as non-critical. The former extension is required if it is intend­ed to use Certificate Revocation Lists (CRLs) in the future. The latter extension is required if it is intended to use the Online Certificate Status Protocol (OCSP, see RFC 2560) in the future. Any of the extensions must contain HTTP URLs only.

9.The template VPN certificate should contain one or both of the extensions CRL Distri­bution Points and Authority Information Access, described above, if it is planned to dis­tribute revocation information online in the future. Alternatively, the mdm server can be instructed to include them within the certification request sent to the mdm CA. The latter is more flexible, because this way the location of the revocation information (CRL) re­spectively information service (OCSP) can be set for groups of devices or even for in­dividual devices.
Please note: If the template VPN certificate already includes any of the extension and the mdm is instructed to include it within the certification request as well, the extension from the request overrides the one found within the template. The issued certificate will contain the extension copied from the request.

10.The keystore containing the certificates has to contain the complete certificate chain up to and including the root certificate.