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- 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 ]crlDistributionPoints = @crl_info[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.cnfOnline 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[ 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!
