SSL and TLS for Humans, Part 4 (Streamlined CA Procedures) by Chris Pepper
In Part 1 of this article, we discussed SSL/TLS and how they work. In Part 2, we examined Apple's Certificate Assistant for working with SSL/TLS certificates. In Part 3, we discussed command-line procedures for actually using SSL/TLS certificates. In Part 4, we look at some streamlined CA tools.
http://www.reppep.com/~pepper/ca/
I have developed a couple simple tools, named cert.command and sign.command. They can be used from the command line or launched like normal Mac programs, by double-clicking. cert.command walks through the process of creating a CSR and signing it, to create a brand-new signed certificate; sign.command takes an existing certificate and signs it, as a commercial CA would do. The behavior of each tool is the same whether launched in a shell window (without arguments) or double-clicked: the script prompts for necessary information and produces a .crt file, signed by the root certificate specified in openssl.cnf. cert.command also prompts for the organizational information used to build a CSR, while sign.command doesn't need this, since the information is available inside the CSR.
For greater efficiency, both scripts may be run from a command line with an argument, that being the name of the certificate to create (as in "cert.command www.tidbits.com.20071108"), or the CSR file to sign (as in "sign.command www.tidbits.com.20071108.csr").
1. Create a new Certificate Authority -- This is rare enough that I didn't bother providing an alternative. Just be aware that "CA.pl -newca" always creates ./demoCA, regardless of the configuration in openssl.cnf. Once demoCA is created, you can move it to the location and name (and make sure openssl.cnf is configured for the new location).
2. Create a new certificate signing request -- Every certificate starts with a CSR, so if you want a CSR - perhaps to send to a commercial CA - you can use cert.command, and disregard certificate.crt (signed by your own CA) and instead submit certificate.csr to the CA to be signed. cert.command also creates certificate.key, containing the private key which the CSR and eventual certificate are based on. See #5 below for more on cert.command.
3. Create a self-signed certificate -- With one's own CA, there's little reason to use a self-signed certificate, so don't.
4. Request that a CA sign a CSR, and return a signed certificate -- This is entirely in the CA's hands, and doesn't really involve CA.pl either.
5. Sign your own CSR with your own root certificate -- This is the core CA activity, and can be done with either cert.command (to create a new CSR and sign it in one operation) or sign.command (to sign an existing CSR). For cert.command, I suggest using the fully qualified domain name of the host and the date as the certificate name, as in "cert.command www.tidbits.com.20071108". sign.command requires the name of an existing file (ending in .csr) to process, as in "sign.command www.tidbits.com.20071108.csr".
For convenience, both scripts can be run without arguments, or launched by double-clicking; in either case they will prompt for the name.
pepperbook:~/CA/tidbits julia$ cert.command www.tidbits.com.20070401
Generating RSA private key, 512 bit long modulus
....++++++++++++
...............++++++++++++
e is 65537 (0x10001)
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 (full name) [New York]:
Locality Name (eg, city) [Ithaca]:
Organization Name (eg, company) [TidBITS]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:www.tidbits.com
Email Address [webmaster@tidbits.com]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /System/Library/OpenSSL/openssl.cnf
Enter pass phrase for /Users/julia/CA/tidbits/private/ca.tidbits.com.20070401.key:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Apr 1 05:57:59 2007 GMT
Not After : Mar 31 05:57:59 2008 GMT
Subject:
countryName = US
stateOrProvinceName = New York
organizationName = TidBITS
commonName = www.tidbits.com
emailAddress = webmaster@tidbits.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
38:68:9D:9D:3F:B8:9C:C3:20:5E:EB:44:CF:F8:9B:D3:A1:B5:82:CB
X509v3 Authority Key Identifier:
keyid:A5:2F:7D:A1:25:C5:9E:50:5D:A3:57:B0:A7:D4:F4:F6:DC:66:3F:CB
DirName:/C=US/ST=New York/L=Ithaca/O=TidBITS/CN=ca.tidbits.com/emailAddress=webmaster@tidbits.com
serial:94:16:46:00:6F:79:CC:4B
Certificate is to be certified until Mar 31 05:57:59 2008 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
Your files are:
-rw-r--r-- 1 julia julia 6734 Apr 1 01:58 www.tidbits.com.20070401.crt
-rw-r--r-- 1 julia julia 509 Apr 1 01:57 www.tidbits.com.20070401.csr
-rw------- 1 julia julia 497 Apr 1 01:57 www.tidbits.com.20070401.key
For comparison, here's sign.command signing www.tidbits.com.20071108.csr, created above:
pepperbook:~/CA/tidbits julia$ sign.command certs/www.tidbits.com.20070401.csr
Using configuration from /System/Library/OpenSSL/openssl.cnf
Enter pass phrase for /Users/julia/CA/tidbits/private/ca.tidbits.com.20070401.key:
DEBUG[load_index]: unique_subject = "no"
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 2 (0x2)
Validity
Not Before: Apr 1 05:58:49 2007 GMT
Not After : Mar 31 05:58:49 2008 GMT
Subject:
countryName = US
stateOrProvinceName = New York
organizationName = TidBITS
commonName = www.tidbits.com
emailAddress = webmaster@tidbits.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
38:68:9D:9D:3F:B8:9C:C3:20:5E:EB:44:CF:F8:9B:D3:A1:B5:82:CB
X509v3 Authority Key Identifier:
keyid:A5:2F:7D:A1:25:C5:9E:50:5D:A3:57:B0:A7:D4:F4:F6:DC:66:3F:CB
DirName:/C=US/ST=New York/L=Ithaca/O=TidBITS/CN=ca.tidbits.com/emailAddress=webmaster@tidbits.com
serial:94:16:46:00:6F:79:CC:4B
Certificate is to be certified until Mar 31 05:58:49 2008 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
Your signed certificate is:
-rw-r--r-- 1 julia julia 6734 Apr 1 01:58 www.tidbits.com.20070401.crt
pepperbook:~/CA/tidbits julia$
6. Check a certificate -- I have nothing further to suggest beyond the pointers in Part 3.
7. Install a certificate in a server -- Both cert.command and sign.command append the root certificate to the signed certificate, which makes configuring server software slightly simpler by avoiding a third file (the CA certificate) which otherwise must be used alongside the server certificate.
8. Trust a certificate in a browser -- Both cert.command and sign.command append the root certificate to the signed certificate, to make it easier to trust the root certificate.
9. Test an SSL/TLS connection -- I have nothing further to suggest beyond the pointers in Part 3.