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
-----------------------------------------------
#
# OpenSSL Configuration file for Condor Multi-level CA
# # This definition stops the following lines choking if HOME isn't
# defined.
HOME = .
RANDFILE = $ENV::HOME/.rnd ####################################################################
[ ca ]
default_ca = CA_default # The default ca section ####################################################################
[ CA_default ] dir = ./CondorSigningCA1 # Where everything is kept
certs = $dir/ca.db.certs # Where the issued certs are kept
#crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/ca.db.index # database index file.
new_certs_dir = $dir/ca.db.certs # default place for new certs. certificate = $dir/signing-ca-1.crt # The CA certificate
serial = $dir/ca.db.serial # The current serial number
#crl = $dir/crl.pem # The current CRL
private_key = $dir/signing-ca-1.key # The private key
RANDFILE = $dir/.rand # private random number file x509_extensions = usr_cert # The extentions to add to the cert # Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options # Extension copying option: use with caution.
# copy_extensions = copy # Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crl_extensions = crl_ext default_days = 365 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = md5 # which md to use.
preserve = no # keep passed DN ordering # A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match # A new one - quells a complaint from openssl ca
unique_subject = yes ####################################################################
[ CA_marginal ] dir = ./CondorSigningCA3 # Where everything is kept
certs = $dir/ca.db.certs # Where the issued certs are kept
#crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/ca.db.index # database index file.
new_certs_dir = $dir/ca.db.certs # default place for new certs. certificate = $dir/signing-ca-3.crt # The CA certificate
serial = $dir/ca.db.serial # The current serial number
#crl = $dir/crl.pem # The current CRL
private_key = $dir/signing-ca-3.key # The private key
RANDFILE = $dir/.rand # private random number file x509_extensions = usr_cert # The extentions to add to the cert # Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options # Extension copying option: use with caution.
# copy_extensions = copy # Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crl_extensions = crl_ext default_days = 365 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = md5 # which md to use.
preserve = no # keep passed DN ordering # A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match ###################################################################
[ CA_root ] dir = ./CondorRootCA # Where everything is kept
certs = $dir/ca.db.certs # Where the issued certs are kept
#crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/ca.db.index # database index file.
new_certs_dir = $dir/ca.db.certs # default place for new certs. certificate = $dir/root-ca.crt # The CA certificate
serial = $dir/ca.db.serial # The current serial number
#crl = $dir/crl.pem # The current CRL
private_key = $dir/root-ca.key # The private key
RANDFILE = $dir/.rand # private random number file x509_extensions = v3_ca # The extentions to add to the cert # Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options # Extension copying option: use with caution.
# copy_extensions = copy # Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crl_extensions = crl_ext default_days = 1095 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = md5 # which md to use.
preserve = no # keep passed DN ordering # A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match
unique_subject = yes # For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
localityName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional # For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional ####################################################################
[ req ]
default_bits = 1024
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert # Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret # This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings
# so use this option with caution!
string_mask = nombstr # req_extensions = v3_req # The extensions to add to a certificate request [ 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 = 64 # SET-ex3 = SET extension number 3 [ req_attributes ]
# challengePassword = A challenge password
# challengePassword_min = 4
# challengePassword_max = 20 # unstructuredName = An optional company name [ usr_cert ] # These extensions are added when 'ca' signs a request. # This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA. basicConstraints=CA:FALSE # Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing. # This is OK for an SSL server.
# nsCertType = server # For an object signing certificate this would be used.
# nsCertType = objsign # For normal client use this is typical
# nsCertType = client, email # and for everything including object signing:
# nsCertType = client, email, objsign # This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment # This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate" # PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always # This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move # Copy subject details
# issuerAltName=issuer:copy #nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName [ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment [ v3_ca ] # Extensions for a typical CA # PKIX recommendation. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always # This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true # Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign # Some might want this also
# nsCertType = sslCA, emailCA # Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy # DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF [ crl_ext ] # CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL. # issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always
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:
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.
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.
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