How To Setup a CA

Original Version by Ian Alderman
Updated by Zach Miller

Introduction

You can set up a Certificate Authority (CA) in multiple different ways. Our first pass here will be to set up a very simple, one-level CA for use with the SSL authentication method in Condor. Building on this knowledge, we will then set up a multi-level CA that could be used for the GSI authentication method in Condor (and other software that uses GSI).

Our goal was to establish a multi-level CA. The difference between a multi-level CA and a single-level CA is that in a single-level CA, the root key is also the signing key for host and user certificates. We wanted to establish a root key which we could use to sign (and revoke if necessary) several signing keys which will be used for different purposes. So, if a local PKI is represented a tree where nodes are keys and edges are certificates, a single-level tree is height two and has just one non-leaf node, while our tree is height three and has a single root node, and several second level nodes. We will use the OpenSSL command line tool for most of this process.

Customize the configuration file for easy data entry

While this step isn't strictly necessary for the following process, doing it makes subsequent steps a bit easier, and increases the chances of getting things right, and consistent. You could start with a copy of the default openssl.cnf file, and modify the defaults to suit your installation. Later on, you'll have to make other changes, so you may just want to get them all at once. Here's our customized openssl.cnf. To see what we've changed scroll to the section labeled [ req_distinguished_name ] and examine the lines with the suffix _default. For example, our altered section reads as follows:

[ req_distinguished_name ]              
countryName                     = Country Name (2 letter code)
countryName_default             = US
countryName_min                 = 2
countryName_max                 = 2

stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = Wisconsin

localityName                    = Locality Name (eg, city)
localityName_default            = Madison

0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = University of Wisconsin -- Madison

1.organizationName              = Second Organization Name (eg, company)
1.organizationName_default      = Computer Sciences Department

organizationalUnitName          = Organizational Unit Name (eg, section)
organizationalUnitName_default  = Condor Project

commonName                      = Common Name (eg, YOUR name)
commonName_max                  = 64

emailAddress                    = Email Address
emailAddress_max                = 40

A Single-level CA

Create the CA root key and self-signed certificate

Create the keypair:

openssl genrsa -des3 -out root-ca.key 1024

	Generating RSA private key, 1024 bit long modulus
	..............++++++
	..........++++++
	e is 65537 (0x10001)
	Enter pass phrase for root-ca.key:
	Verifying - Enter pass phrase for root-ca.key:

You will be asked for a password which will be the CA password, and then you'll be asked for that password again. The output of this command, the file root-ca.key, contains an RSA keypair which is encryped using the password you supply. So, for someone to use this key to create new certificates (either host or client), they'll need BOTH this file and the password.

Use the key to sign itself:

openssl req -new -x509 -days 3650 -key root-ca.key -out root-ca.crt -config openssl.cnf

	Enter pass phrase for root-ca.key:
	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) [Wisconsin]:
	Locality Name (eg, city) [Madison]:
	Organization Name (eg, company) [University of Wisconsin -- Madison]:
	Second Organization Name (eg, company) [Computer Sciences Department]:
	Organizational Unit Name (eg, section) [Condor Project]:
	Common Name (eg, YOUR name) []:ROOT CA
	Email Address []:

This reads, "create a new, self-signed X.509 certificate valid for ten years, for the keypair in the file root-ca.key, and place the output in the file root-ca.crt."

You will be prompted to input identifying information for the certificate. It's important not to use single quotes in the responses due to a quirk in the Globus implementation: for example don't use a Common Name such as "Alice's CA". If you have customized the configuration file as suggested above, the defaults you specified there will make this step easier. The openssl req command recognizes that the request is for a self signed certificate, and automatically applies suitable options, such as setting the "CA:TRUE" bit.

Don't use an email address. This avoids this interaction bug in signing policy files.

Now, let's take a look at the certificate we generated:

openssl x509 -noout -text -in root-ca.crt

Finally, we need to put these certificates and keys into a directory where our config file can find them for future use. Here is a perl script to create the directory heirarchy you will need.

Run it like this:

perl mk_new_ca_dir.pl CondorSigningCA1 mv root-ca.crt CondorSigningCA1/signing-ca-1.crt mv root-ca.key CondorSigningCA1/signing-ca-1.key

Using the Root CA to Sign Certificates

Users

User certificates have the user name as the CN, and their email address. OpenSSL allows you to create a key and a certificate signing request in one step:

openssl req -newkey rsa:1024 -keyout zmiller.key -config openssl.cnf -out zmiller.req

	Generating a 1024 bit RSA private key
	....................++++++
	..++++++
	writing new private key to 'zmiller.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.
	-----
	Country Name (2 letter code) [US]:
	State or Province Name (full name) [Wisconsin]:
	Locality Name (eg, city) [Madison]:
	Organization Name (eg, company) [University of Wisconsin -- Madison]:
	Second Organization Name (eg, company) [Computer Sciences Department]:
	Organizational Unit Name (eg, section) [Condor Project]:
	Common Name (eg, YOUR name) []:Zach Miller
	Email Address []:zmiller@cs.wisc.edu

Then sign it, remembering the signing key password:

openssl ca -config openssl.cnf -out zmiller.crt -infiles zmiller.req

	Using configuration from openssl.cnf
	Enter pass phrase for ./CondorSigningCA1/signing-ca-1.key:
	Check that the request matches the signature
	Signature ok
	Certificate Details:
	        Serial Number: 1 (0x1)
	        Validity
	            Not Before: Apr 29 15:15:17 2008 GMT
	            Not After : Apr 29 15:15:17 2009 GMT
	        Subject:
	            countryName               = US
	            stateOrProvinceName       = Wisconsin
	            localityName              = Madison
	            organizationName          = University of Wisconsin -- Madison
	            organizationName          = Computer Sciences Department
	            organizationalUnitName    = Condor Project
	            commonName                = Zach Miller
	        X509v3 extensions:
	            X509v3 Basic Constraints: 
	                CA:FALSE
	            Netscape Comment: 
	                OpenSSL Generated Certificate
	            X509v3 Subject Key Identifier: 
	                58:51:B5:B5:C4:8B:74:A5:43:22:5B:1B:27:F6:7E:F3:A8:60:07:32
	            X509v3 Authority Key Identifier: 
	                keyid:95:AE:11:9A:6C:3A:07:F5:6C:4A:CB:A8:5A:77:15:C5:02:30:08:37
	                DirName:/C=US/ST=Wisconsin/L=Madison/O=University of Wisconsin -- Madison/O=Computer Sciences Department/OU=Condor Project/CN=ROOT CA
	                serial:ED:11:AB:0C:05:2F:6B:84
	
	Certificate is to be certified until Apr 29 15:15:17 2009 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

Hosts

Host certificates have the hostname as the CN (this is required for Globus), and the email address of the requester.

openssl req -newkey rsa:1024 -keyout host_omega.key -nodes -config openssl.cnf -out host_omega.req

	Generating a 1024 bit RSA private key
	..............++++++
	.++++++
	writing new private key to 'host_omega.key'
	-----
	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) [Wisconsin]:
	Locality Name (eg, city) [Madison]:
	Organization Name (eg, company) [University of Wisconsin -- Madison]:
	Second Organization Name (eg, company) [Computer Sciences Department]:
	Organizational Unit Name (eg, section) [Condor Project]:
	Common Name (eg, YOUR name) []:omega.cs.wisc.edu
	Email Address []:zmiller@cs.wisc.edu

openssl ca -config openssl.cnf -out host_omega.crt -infiles host_omega.req

	Using configuration from openssl.cnf
	Enter pass phrase for ./CondorSigningCA1/signing-ca-1.key:
	DEBUG[load_index]: unique_subject = "yes"
	Check that the request matches the signature
	Signature ok
	Certificate Details:
	        Serial Number: 2 (0x2)
	        Validity
	            Not Before: Apr 29 15:18:20 2008 GMT
	            Not After : Apr 29 15:18:20 2009 GMT
	        Subject:
	            countryName               = US
	            stateOrProvinceName       = Wisconsin
	            localityName              = Madison
	            organizationName          = University of Wisconsin -- Madison
	            organizationName          = Computer Sciences Department
	            organizationalUnitName    = Condor Project
	            commonName                = omega.cs.wisc.edu
	            emailAddress              = zmiller@cs.wisc.edu
	        X509v3 extensions:
	            X509v3 Basic Constraints: 
	                CA:FALSE
	            Netscape Comment: 
	                OpenSSL Generated Certificate
	            X509v3 Subject Key Identifier: 
	                56:B9:56:A2:B1:BB:7B:61:0E:21:71:A1:BC:3E:CD:E2:79:DD:F1:75
	            X509v3 Authority Key Identifier: 
	                keyid:95:AE:11:9A:6C:3A:07:F5:6C:4A:CB:A8:5A:77:15:C5:02:30:08:37
	                DirName:/C=US/ST=Wisconsin/L=Madison/O=University of Wisconsin -- Madison/O=Computer Sciences Department/OU=Condor Project/CN=ROOT CA
	                serial:ED:11:AB:0C:05:2F:6B:84
	
	Certificate is to be certified until Apr 29 15:18:20 2009 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

Multi-level CAs

(If you just completed the single-level CA exercise above, you'll need to 'rm -rf CondorSigningCA1' before continuing)

Good Policy

For now we ignore the certificate revocation issues.

The key size must be determined: we used 1024 bits.

Two periods must be determined: the validity period of the root certificate, and the validity period of the signing certificate. For the first pass at the CA, we used twenty years (7300 days) for the former, and three years (1095 days) for the latter. Ten years (3650 days) may be more reasonable for the root key.

The security of the root key is critical, because it is so long lived, and because it can be used to revoke the signing key if necessary. So, we established the policy that the root key is never stored or decrypted on a machine which has an active network connection. I turn off my laptop's wireless connection, create the key, create a cd with just the key on it, burn the cd, and remove the key from the laptop. In the openssl directory, the key is a link to the cd filesystem. When I need to create a signing key, I turn off the network connection, put in the CD, create the key, eject the CD, then turn on the network connection.

There are two people who have copies of the root key CD and know the password.

We will not be disconnecting from the network or burning CDs for this HOWTO.

Create the CA root key and self-signed certificate

Create the keypair:

openssl genrsa -des3 -out root-ca.key 1024

	Generating RSA private key, 1024 bit long modulus
	...++++++
	................++++++
	e is 65537 (0x10001)
	Enter pass phrase for root-ca.key:
	Verifying - Enter pass phrase for root-ca.key:

Use the key to sign itself:

openssl req -new -x509 -days 3650 -key root-ca.key -out root-ca.crt -config openssl.cnf

	Enter pass phrase for root-ca.key:
	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) [Wisconsin]:
	Locality Name (eg, city) [Madison]:
	Organization Name (eg, company) [University of Wisconsin -- Madison]:
	Second Organization Name (eg, company) [Computer Sciences Department]:
	Organizational Unit Name (eg, section) [Condor Project]:
	Common Name (eg, YOUR name) []:ROOT CA
	Email Address []:

This reads, "create a new, self-signed X.509 certificate valid for ten years, for the keypair in the file root-ca.key, and place the output in the file root-ca.crt."

Don't use an email address. This avoids this interaction bug in signing policy files.

Preparing a directory structure for the root CA

In order to make use of two different CAs (i.e., our root CA in addition to our signing CA), OpenSSL needs either two openssl.cnf files, or one with multiple CA sections. We'll take the latter approach. This requires a directory heirarchy to store the different signing keys. (Note that the directory contents must reflect the settings in the openssl.cnf file you just downloaded.) You probably already downloaded it, but if not here's our modified replacement. You'll also want this perl script, which performs the following steps:

Create a directory for the bookkeeping files to reside.
Create a directory to store information about the certificates created.
Create and initialize a file that stores a count of the number of certificates created.
Create and initialize a file that stores a random seed.

In other guides that describe how to sign certificates, these steps are performed by the openssl script sign.sh.

Run the perl script and move the root-ca files into the new directory: perl mk_new_ca_dir.pl mv root-ca.crt CondorRootCA mv root-ca.key CondorRootCA

Creating the signing certificates

Creating the signing certificates is nearly as easy. The certificates must be created with the "CA:TRUE" bit set, as noted above. First, we create the keypair for the signing key. This is similar to the step used to create the keypair for the root key, above.

openssl genrsa -des3 -out signing-ca-1.key 1024

	Generating RSA private key, 1024 bit long modulus
	..........++++++
	..................................++++++
	e is 65537 (0x10001)
	Enter pass phrase for signing-ca-1.key:
	Verifying - Enter pass phrase for signing-ca-1.key:

Now, instead of creating the request and signing it with the private key just created, as is done above, here we create a request in one step, and then sign it using the root key in another. First, we create the request. (Don't use an email address here either.)

openssl req -new -days 1095 -key signing-ca-1.key -out signing-ca-1.csr -config openssl.cnf

	Enter pass phrase for signing-ca-1.key:
	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) [Wisconsin]:
	Locality Name (eg, city) [Madison]:
	Organization Name (eg, company) [University of Wisconsin -- Madison]:
	Second Organization Name (eg, company) [Computer Sciences Department]:
	Organizational Unit Name (eg, section) [Condor Project]:
	Common Name (eg, YOUR name) []:SIGNING CA 1
	Email Address []:

Then, we sign the request, using the "-name" argument to specify the section in the altered openssl.cnf file:

openssl ca -config openssl.cnf -name CA_root -extensions v3_ca -out signing-ca-1.crt -infiles signing-ca-1.csr

Preparing a directory structure for the signing CA

Now, we can create a directory structure for the signing key, using the same perl script we used to create the root CA directory structure. This time, we give an argument to the script to tell it the name of the directory, corresponding to the directory name in the openssl.cnf file.

Run the perl script and copy the signing key files into new directory: perl mk_new_ca_dir.pl CondorSigningCA1 mv signing-ca-1.crt CondorSigningCA1 mv signing-ca-1.key CondorSigningCA1

Generating keys, signing requests, and certificates

(Same as above)

Users

User certificates have the user name as the CN, and their email address. OpenSSL allows you to create a key and a certificate signing request in one step:

openssl req -newkey rsa:1024 -keyout zmiller.key -config openssl.cnf -out zmiller.req

Then sign it, remembering the signing key password:

openssl ca -config openssl.cnf -out zmiller.crt -infiles zmiller.req

Hosts

Host certificates have the hostname as the CN (this is required for Globus), and the email address of the requester.

openssl req -newkey rsa:1024 -keyout host_omega.key -nodes -config openssl.cnf -out host_omega.req

openssl ca -config openssl.cnf -out host_omega.crt -infiles host_omega.req

Extras

There's a perl script for generating certs from an input file.

Check out Globus' GSI.

Other handy OpenSSL commmand line tools:

To get a hash:
openssl x509 -noout -hash -in host.crt
To get a subject:
openssl x509 -noout -subject -in host.crt
To see the whole cert:
openssl x509 -noout -text -in host.crt

Condor Configuration

See the manual, SSL Configuration

Generally, you'll want to use a single-level CA to setup easy SSL host-to-host authentication. You can share a single cert for all of your hosts and Condor daemons, or you can have one certificate per host. (You could in theory have one certificate per daemon per host if you wanted, but that's probably overkill). If you are going to use SSL authentication in Condor, you'll also want to read the manual section on security to learn how to enable it.

Quick Example (Condor Version 7.0.1):

If you generated just a single-level CA here's how you would configure Condor to use those certificates for daemon-to-daemon communication. Specify full paths to the crt and key files. Make sure the files are owned and readable only by the condor user.

SEC_DAEMON_AUTHENTICATION = REQUIRED SEC_DAEMON_AUTHENTICATION_METHODS = SSL ALLOW_DAEMON = ssl@unmappeduser AUTH_SSL_CLIENT_CAFILE = root-ca.crt AUTH_SSL_CLIENT_CERTFILE = host_omega.crt AUTH_SSL_CLIENT_KEYFILE = host_omega.key AUTH_SSL_SERVER_CAFILE = root-ca.crt AUTH_SSL_SERVER_CERTFILE = host_omega.crt AUTH_SSL_SERVER_KEYFILE = host_omega.key