Chaining Certificate Authorities
Contents
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 iDENprotectserver 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
- Move
signedcert.cer
back to idenprotect Core Platform - 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
-
- Create a PKCS12 file from the key pair:
-
openssl pkcs12 -inkey server.key -in signedcert.cer -export -out /etc/idenprotect/keystore.p12
-
- 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.