PKI

Jan 8, 2018
16 minute read

Some of my (and others) notes of managing PKI with the excellent openssl. Its simple and just works. To get going will create a root CA (Certificate Authority) and an intermediate signing CA. Using the CA’s will issue three keypairs; one for email protection, one for TLS, and one for digital signatures. The digital signature keypair will be presented in the form of a CSR (Certificate Signing Request), as if generated by a third party that would like a keypair, signed by our CA hierarchy.

The Request (CSR)

Start by producing a new keypair, in the form of a Certificate Signing Request (CSR). A CSR, breaks out the private and public keys, so you can provide just the public key portion to another trusted party for signing. Once signed, and now part of a trust chain, you can combine the two pieces together again.

Create Working Certificates

Email Protection Certificate

The Request (CSR)

The req -new command to create a new keypair (in the form of a CSR).

openssl req -new -config email.conf -out certs/ben-email.csr -keyout certs/ben-email.key
Generating a 2048 bit RSA private key
..+++
.............+++
writing new private key to 'certs/ben-email.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
1. Domain Component (DC=net) []:DC=net
2. Domain Component (DC=bencode) []:DC=bencode
3. Domain Component (DC=pki) []:DC=pki
4. Organization Name (O=bEncode Labs) []:O=bEncode Labs
5. Organizational Unit Name (OU=section) []:
6. Common Name (CN=Benjamin Simmonds) []:CN=Benjamin Simmonds
7. Email Address (emailAddress=ben@bencode.net) []:emailAddress=ben@bencode.net

PKCS#12 (p12) Bundle

A standards, cleaned up version of Microsofts PFX format. Typically used for bundling a certificate and its private key. Additional certificates (e.g. those needed to build the trust chain up to the Root CA) can be included. For example:

PEM Bundle

Super simple. Involves concatenating other PEM formatted files together. This could be the trust chain certificates, or the private key and its certificate, or the private key its certificate and the trust chain certificates, or any other combination.

Key usage extensions

Key usage extension

Description

Digital signature

Use when the public key is used with a digital signature mechanism to support security services other than non-repudiation, certificate signing, or CRL signing. A digital signature is often used for entity authentication and data origin authentication with integrity.

Non-repudiation

Use when the public key is used to verify digital signatures used to provide a non-repudiation service. Non-repudiation protects against the signing entity falsely denying some action (excluding certificate or CRL signing).

Key encipherment

Use when a certificate will be used with a protocol that encrypts keys. An example is S/MIME enveloping, where a fast (symmetric) key is encrypted with the public key from the certificate. SSL protocol also performs key encipherment.

Data encipherment

Use when the public key is used for encrypting user data, other than cryptographic keys.

Key agreement

Use when the sender and receiver of the public key need to derive the key without using encryption. This key can then can be used to encrypt messages between the sender and receiver. Key agreement is typically used with Diffie-Hellman ciphers.

Certificate signing

Use when the subject public key is used to verify a signature on certificates. This extension can be used only in CA certificates.

CRL signing

Use when the subject public key is to verify a signature on revocation information, such as a CRL.

Encipher only

Use only when key agreement is also enabled. This enables the public key to be used only for enciphering data while performing key agreement.

Decipher only

Use only when key agreement is also enabled. This enables the public key to be used only for deciphering data while performing key agreement.

Digital Signatures - how they work

This does have an XML flavour to it.

To validate (i.e. to prove)

First the message can be normalised, and in the case of XML will use something like the “Exclusive XML Canonicalization” (XML-C14N), so we’re comparing apples with apples. This will disgard things like usage of white space.

Using the normalised representation, compute a hash (e.g. SHA1) of the timestamp (contained WS-Security header) and entire message payload (the SOAP body).

Using the public key from the partner organisation certificate, RSA decrypt the hash computed by partner organisation.

If the two hashes are identical, we know the message has not been tampered with.