Demystifying SSL: From Zero to Certificate Authority

Author:Jeff Propes
Date:June 21, 2014

Follow along with me at http://self2014.grimoi.re/demystifying_ssl_part2/

Overview

Understanding the SSL Tree of Trust

The X.509 Certificate Format and Features

Configuration & Best Practices

Revocation Lists and OCSP

Signing Your First Certificate

Assumptions & Expectations

Creating and maintaining your own certificate authority is Hard

Know how to operate the openssl binary

There will be lots of fumbling around

Mistakes will be made (and that's ok!)

We will try to keep the swearing to a minimum

Understanding the SSL Tree of Trust

As a certificate authority you are peddling Trust

Trust is expensive, especially when you're selling with billion-dollar corporations

The Tree

images/ssl_tree_of_trust.png

Copyright Jon Warbrick, http://jw35.blogspot.com/2010/05/splits-and-joins-in-pki-certificate.html

Used with permission under license CC BY-UK http://creativecommons.org/licenses/by/2.0/uk/

Trust in Layers

A CA's primary asset is their root certificate

This certificate is the tip of the tree

Self-signed, many years of validity

Protected by Hardware Security Mechanism, air gaps, lasers, poison gas, and armed guards

Delegates authority for managing your Trust out to intermediate or end user certificates

Intermediate Certificates

Workhorse certificates mostly used for signing end-user certificates

One root cert can have many intermediates which are all trusted

Usually has many years of validity

They must be available for signing while still remaining secure (use a HSM)

Large revocation lists

End-User Certificates

A tiny dollop of Trust for a very narrow application

Granting Trust for one or a few domains for a short period of time (usually 1 year)

Verify that the information presented in the Certificate Signing Request is accurate

If the owner of this certificate does Bad Things, that damages your Trust

Can be revoked and reissued as needed (but then you have another item in your CRL)

The X.509 Certificate Format and Features

Example CA certificates and CSR

View the cert with openssl x509 -noout -text -in <certfile>

Configuration

Warning: the configuration is UGLY. This is where most of the swearing comes into play

Major sections (denoted by square brackets) correspond to commands in openssl

Some options can refer to other sections which have 0+ options in them

Try to keep all associated files in a neat structure within a single directory

basicConstraints

Two flags which are critically important to CA certificates appear in the basicConstraints setting

Best Practices

Keep individual configuration files for each root and intermediate cert you create

Don't settle for MD5 or SHA1 hashing. Go for something stronger like SHA128 or SHA256

Don't blindly copy extensions from client CSRs (e.g. turn off copy_extensions)

Set authorityKeyIdentifier to use only the keyid and not keyid,issuer

Revocation Lists and OCSP

As a certificate authority, you have a duty to maintain an accurate list of SSL certs that you have revoked

Not all certs were revoked for bad reasons. Some just need to be altered and reissued

Certificate Revocation List maintained in a publicly-accessible location

As your root and intermediate certs exist for many years, so too must the URL for the CRL

OCSP invented as replacement for huge CRL

Signing Your First Certificate

We are going to create a self-signed root certificate with pathlen: 1

Example configuration: http://self2014.grimoi.re/demystifying_ssl_part2/resources/root.cnf

Creating the Root CA

The root CA certificate MUST be self-signed

Create the private key first with openssl genrsa -des3 -out rootca.key

We use the req command with a special flag -x509 to denote this should be self-signed

openssl req -config root.cnf -new -x509 -key rootca.key -out rootca.crt

Signing another certificate

Review the CSR carefully before agreeing to sign it

openssl req -noout -text -in <csrfile>

When you are ready to sign: openssl ca -config root.cnf -in <csrfile> -out <crtfile>

It will ask you to confirm your willingness to sign the certificate and whether you want to keep records of it

ALWAYS KEEP RECORDS - If you don't, you can't properly maintain CRLs or track what you've done

Fin

Thanks for coming!

This presentation can be found permanently at http://self2014.grimoi.re/demystifying_ssl_part2/

More information can be had by reading the following: