Chaining Certificate Authorities

Introduction

idenprotect Core Platform comes with a built-in Internal Certificate Authority that can be used to sign the certificates used by idenprotect Devices registered on that server.

This article explains how you can use the Chain of Trust principle to validate the Internal CA as a reliable CA by creating a key pair for the internal CA and then signing the key on a pre-existing external root CA in your organisation.

Completing the configuration steps will require an installation of the idenprotect Core Platform. If you do not currently have an installation, please follow our Idenprotect Core Platform Quick Start Guide or for more detailed instructions, Start Here

Internal CA Configuration

When validating idenprotect devices, the Internal CA signs different types of certificates as part of normal use. The signature algorithm and validity periods for each certificate type are defined in /etc/idenprotect/caprofiles.properties:

server.validity=315000000
server.sigAlgo=SHA256withECDSA

ephemeral.validity=28800
ephemeral.sigAlgo=SHA256withECSDA

secenc.validity=6400000
secenc.sigAlgo=SHA256withECSDA

device.validity=6400000
device.sigAlgo=SHA512withRSA

Each validity period value is defined in seconds. Supported sigAlgo signature algorithms are listed in JDK Cryptography Providers under SunRsaSign and for SunEC.

The certificate names in caprofiles.properties refer to:

• server certificate - idenprotect Core Platform's own public key
• ephemeral certificate - temporary certificates used when new connections are formed between idenprotect Core Platform and an idenprotect Device.
• secenc certificate - idenprotect Device certificate stored on the Device's Secure Enclave (or equivalent on non-iOS platforms)
• device certificate - idenprotect Device's own unique certificate

KeyStore Settings

The Internal CA uses a Java KeyStore to store key pairs and a Java TrustStore to store the associated certificates. Their properties are defined in /etc/idenprotect/ca.properties, for example

ca.keystore.path=/etc/idenprotect/
ca.keystore.pass=p455w0rd
ca.keystore.subject=C=GB, ST=LEEDS, OU=IT, CN=testIdenprotect
ca.keystore.alias=idenprotect

Certificates signed using RSA signature algorithm requires an RSA keypair and certificates signed using ECDSA require an Elliptic Curve (ECC) keypair.

KeyStore and TrustStore require at a minimum an ECC keypair and associated certificate. If an RSA signature algorithm is used, then an RSA keypair and associated certificate is also required in the KeyStore and TrustStore.

An ECC keypair and associated certificate is identified in the keystore and truststore by an alias prefixed with ec, followed by the ca.keystore.alias value in ca.properties.

• In the example above, an ECC keypair would need to be identified in the keystore with an alias of ecidenprotect and the associated certificate would need to be identified in the truststore with an alias of ecidenprotect.

An RSA keypair and associated certificate is identified in the keystore and truststore by an alias prefixed with rsa, followed by the ca.keystore.alias value in ca.properties.

• In the example above, an RSA keypair would need to be identified in the keystore with an alias of rsaidenprotect and the associated certificate would need to be identified in the truststore with an alias of rsaidenprotect.

When iDENprotect^server starts, the Internal CA checks to see if the required keys and certificates exist. If the keys do not exist, idenprotect Core Platform creates them.

These newly created certificates are self-signed by idenprotect Core Platform. Self-signed certificates are generally not used in production environments because a lot of clients do not consider self-signed certificates trustworthy. Using certificates signed by a trusted external root CA instead of self-signed ones is a way to extend this trust to idenprotect Core Platform as well.

Creating a chained CA certificate

This section shows how to use OpenSSL and Java Keytool to create a key pair for idenprotect Core Platform and an associated Certificate Signing Request (CSR) to be signed by the chained external Certificate Authority (CA). Other certificate tools can be used as well if you are more familiar with them.

Creating Keypair and CSR

The following commands can be entered on the command line of the idenprotect Core Platform or any other computer that has the required tools (OpenSSL & Java Development Kit) installed.

Create an ECDSA/SHA256 key:

openssl ecparam -out server.key -name prime256v1 -genkey

TIP: To create an RSA key, use genrsa instead of ecparam

Create a CSR for the key:

openssl req -new -key server.key -out server.csr

Signing CSR

This CSR now needs to be signed by the external root CA. The process for this depends on the specific CA but it is important that the certificate profile used allows for the signed Certificate to be used as a Certificate Authority.

If using a Microsoft CA to sign the CSR, this can be achieved via the certreq command line tool:

certreq -attrib "CertificateTemplate:<certificate template name>" -config <CA location> –submit <csr filename> <output certificate filename>

For example, to sign a CSR named server.csr by Microsoft CA located at ca.demo.net\CA-DEMO using a certificate template named demo-template, use the following command:

certreq -attrib "CertificateTemplate:demo-template" -config "ca.demo.net\CA-DEMO" -submit server.csr signedcert.cer

This command creates a certificate file signedcert.cer which is signed by the external CA. signedcert.cer (and all further certificates signed by it) are trusted by the same resources as the root certificate that was used to sign signedcert.cer.

Building KeyStore and TrustStore

1. Move signedcert.cer back to idenprotect Core Platform
2. Import the certificate file into the TrustStore defined in ca.properties:

   keytool -import -trustcacerts -alias ecidenprotect -file signedcert.cer -keystore /etc/idenprotect/truststore.jks
   NOTE: keytool is available under java/bin directory if the command is not recognised by the command line

3. Create a PKCS12 file from the key pair:

   openssl pkcs12 -inkey server.key -in signedcert.cer -export -out /etc/idenprotect/keystore.p12

4. Import the PKCS12 file into the KeyStore:

   keytool -importkeystore -srckeystore /etc/idenprotect/keystore.p12 -srcstoretype PKCS12 -srcalias 1 -destkeystore /etc/idenprotect/keystore.jks -deststoretype JKS -destalias ecidenprotect

For guidelines on naming the alias, see #KeyStore_Settings.

You will be prompted for passwords during the process. Ensure that all of these match the one specified in ca.properties.

You can use Keytool Explorer (and other tools) to verify the stores are correct.

Testing

With the KeyStore and TrustStore created and the details stored in ca.properties the idenprotect Core Platform can be restarted.

Once restarted, go to the Admin Console Config Tab. If everything is in order, the Show Certificate option displays the signed certificate. Any idenprotect Devices enrolled after this point will have their own certificates signed by the new certificate.