Working with PKCS#1 Private Keys#

There are plenty of keystore formats that are used throughout, one of which is specified in the PKCS#1 specification in RFC 8017. A major drawback for PKCS#1 keystores is the fact that they can only contain one key, which makes it more difficult to manage, as the Identity Server prefers to use keystores with private- and public keys (or certificates) combined.

When certificates are obtained from Let’s Encrypt using the getssl script, the resulting files are two PKCS#1 files.

As a consequence, to use PKCS#1 keys and certificates, they must be processed outside Curity so they can be configured using the Admin UI or other means. Converting the PKCS#1 key material into a Curity supported format can be done with tooling like for example openssl. This section will walk through the steps needed to perform the conversions to produce a singular keystore that can be used with the Identity Server.

When looking inside the contents of a PEM-encoded file, you can tell that it is a PKCS#1 formatted private key when the file starts with -----BEGIN RSA PRIVATE KEY-----. A PKCS#8 formatted file would start with -----BEGIN PRIVATE KEY-----.

Given there are two files, a private key in one file (e.g. curity.example.com.key) and a certificate in another file (e.g. curity.example.com.crt), you can use the following commands to convert these into one file in the PKCS#8 format, that can be used directly with the Identity Server to import:

$ openssl pkcs8 -in "curity.example.com.key" -topk8 -out "curity.example.com.key.pkcs8" -nocrypt
$ cat curity.example.com.key.pkcs8 curity.example.com.crt > curity.example.com.pkcs8

The commands above produce a file curity.example.com.key.pkcs8 that can be used in the same way that a PKCS#12 file can be used to configure the Identity Server using the instructions from. Configuring private keystores .

Was this helpful?