Building an OpenSSL Certificate Authority - Configuring CRL and OCSP

Certificate Revocation Lists

We completed reviewing our PKI design considerations and created root and intermediary certificates completeing our two-tier certificate authority. Now we'll create certificate revocation configurations to comply with NSA Suite B PKI. A certificate revocation list (CRL) is a published list of revoked certificates issued and updated by the certificate authority who signed them. Clients like your internet browser, will check the certificate's CRL URI to find out if the certificate is valid. When a certificate is revoked, the CRL is updated to reflect the revokation and published accordingly. Lists are not the most efficient way to maintain a record of revocation in high volume scenarios so some application vendors have deprecated their use in favor of online certificate status protcol (OCSP). We still need a CRL configuraiton as it's still common and recommended for backward compatibility. Previously we created a CRL URI via the

openssl_intermediary.cnf

 when creating the intermediary certificate. This was an exercise in anticipation of us creating the CRL. Don't forget we're adhering to NSA's Suite B PKI so we have to remember:

• Every Suite B certificate and CRL MUST be signed using ECDSA
• And certificate and CRL MUST be hashed using SHA-256 or SHA-384, matched to the size of the signing CA's key

The OpenSSL configuration file object 

[ server_cert ]

includes 

crlDistributionPoints = @crl_info

which directs the OpenSSL to:

[crl_info]
URI.0 = http://crl.grilledcheese.us/whomovedmycheese.crl

This allows us to enter multiple CRL distribution points for redundancy.

Create the CRL

# cd /root/ca
# openssl ca -config intermediate/openssl_intermediate.cnf -gencrl -out intermediate/crl/whomovedmycheese.crl

Using configuration from intermediate/openssl_intermediate.cnf
Enter pass phrase for /root/ca/intermediate/private/int.cheese.key.pem: ******

 

Validate the CRL with OpenSSL

# openssl crl -in intermediate/crl/whomovedmycheese.crl -noout -text

Certificate Revocation List (CRL):
        Version 2 (0x1)
    Signature Algorithm: ecdsa-with-SHA384
        Issuer: /C=US/ST=WA/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=Grilled Cheese Inc. Intermediary Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us
        Last Update: Aug 24 23:21:38 2017 GMT
        Next Update: Feb 20 23:21:38 2018 GMT
        CRL extensions:
            X509v3 Authority Key Identifier:
                keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD

            X509v3 CRL Number:
                4097
No Revoked Certificates.
    Signature Algorithm: ecdsa-with-SHA384
         30:65:02:30:7b:e4:08:01:06:60:c8:e8:c8:fb:a7:e8:49:7b:
         bf:ee:a6:a6:19:8f:93:67:6c:15:25:bb:c0:d2:ad:c1:ff:05:
         d4:73:e0:72:f0:35:cd:64:35:8b:83:e7:7c:47:ed:ea:02:31:
         00:d4:3c:30:7c:00:73:b6:93:34:3e:1d:96:8f:ba:8a:9b:21:
         3e:ff:36:95:2c:e9:6e:e9:4b:9c:6c:49:1d:fd:ba:6a:75:70:
         41:a5:5e:67:4d:ca:04:2c:c5:37:46:52:91

Yes it was that easy. The CRL file will reside at the URI you specified within the

openssl_intermediary.cnf

.

Online Certificate Status Protocol

The online certificate status protocol (OCSP) is used to check x.509 certificates revocation status. This is the preferred method over CRL by utilizing OCSP responders to return a positive, negative, or unknown status. This provides a faster response for the revocation check versus parsing potentially bulky CRL files. The OCSP responder must be signed by the same CA that issued the certificate being validated. OCSP stapling further improves certificate revocation checking by allowing the server hosting the certificate in question to provide a time-stamped response on behalf of the OCSP responder. Additions to the x.509 v3 extensions would require an OCSP stapled response during TLS negotiation or the connection would be terminated (unless an unknown status or no response is returned). Setting up an OCSP responder equires a server with our OCSP certificate in play and is out of scope for this article. OCSP configuration data is already present in our  

/root/ca/intermediate/openssl_intermediate.cnf

 so when the intermediary certificate was created, it referenced the configuration through the

[ v3_intermediate_ca ]

extension authorityInfoAccess = @ocsp_info.

[ocsp_info]
caIssuers;URI.0 = http://ocsp.grilledcheese.us/cheddarcheeseroot.crt
OCSP;URI.0 = http://ocsp.grilledcheese.us/

Create the OCSP key & certificate

Just like the intermediary CA, we'll generate the key and CSR in one line, using the same secp384r1 elliptical curve during root and intermediary CA creation.

# cd /root/ca
# openssl req -config intermediate/openssl_server.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/ocsp.cheese.key.pem -out intermediate/csr/ocsp.cheese.csr.pem -extensions server_cert 

Generating an EC private key
writing new private key to 'intermediate/private/ocsp.cheese.key.pem'
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.
-----
Country Name (2 letter code) [US]:
State or Province Name [WA]:
Locality Name [Seattle]:
Organization Name [Grilled Cheese Inc.]:
Organizational Unit Name [Grilled Cheese Intermediary CA]:
Common Name []:ocsp.grilledcheese.us
Email Address [grilledcheese@yummyinmytummy.us]:

Sign the CSR with our Intermediary Certificate Authority

# openssl ca -config intermediate/openssl_intermediate.cnf -extensions ocsp -days 365 -notext -md sha384 -in intermediate/csr/ocsp.cheese.csr.pem -out intermediate/certs/ocsp.cheese.crt.pem

Using configuration from intermediate/openssl_intermediate.cnf
Enter pass phrase for /root/ca/intermediate/private/int.cheese.key.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 4103 (0x1007)
        Validity
            Not Before: Aug 28 22:23:14 2017 GMT
            Not After : Aug 28 22:23:14 2018 GMT
        Subject:
            countryName               = US
            stateOrProvinceName       = WA
            localityName              = Seattle
            organizationName          = Grilled Cheese Inc.
            organizationalUnitName    = Grilled Cheese Intermediary CA
            commonName                = ocsp.grilledcheese.us
            emailAddress              = grilledcheese@yummyinmytummy.us
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Subject Key Identifier:
                55:96:45:08:3E:BA:6A:F7:1C:A2:5A:4E:5C:BB:63:65:44:8F:DD:4B
            X509v3 Authority Key Identifier:
                keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD

            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage: critical
                OCSP Signing
Certificate is to be certified until Aug 28 22:23:14 2018 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Verify the certificate's usage is set for OCSP

# openssl x509 -noout -text -in intermediate/certs/ocsp.cheese.crt.pem

           X509v3 Key Usage: critical
               Digital Signature
           X509v3 Extended Key Usage: critical
               OCSP Signing

OCSP Stapling and Beyond

OpenSSL does support operating as an OCSP responder. Per OpenSSL's OCSP man page, running their OCSP server is benefitial for test and demo purposes and is not recommended for production OCSP responder use. Other PKI vendors have more robust OCSP management capabilities integrating into CMS web solutions. Since most clients carry on with a certificates duty if OCSP is unavailable this shouldn't concern us for testing purposes. If you want to setup OCSP stapling DevCentral's Jason Rahm has a guide on setting up OCSP Stapling for use within the virtual server interfaces if you're so inclined to enable BIG-IP for these features. Now we've completed a basic CRL and OCSP configuration, our clients (web browsers) shouldn't complain and we can move on to the fun part, creating server certificates!