Generating a Certificate Signing Request using OpenSSL
CSR generation for IIS7
Third Party Instructions for Generating a CSR here
Please note that InCommon is requiring that all CSRs be generated with a minimum of 2048 bits. If openssl is not configured to generate 2048 bit certificates by default, you will need to tell it to do so from the openssl command line with -newkey rsa:2048
If you have write access to the directory, change into the directory where you will generate your key pairs, ie /usr/local/apache/conf/ssl.csr, otherwise change to any directory where you have write access and you'll have to move the public.csr file later.
>>ssh splunk.uit.tufts.edu >>cd /home/InCommonCerts >>sudo mkdir "certificate-name-MONTH-DAY-YEAR" I.e. mkdir wildcard.hirshlibrary.tufts.edu-July-15-2015
Run the following command:
/usr/bin/openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout private.key -out public.csr
From here OpenSSL will ask you a series of questions that you will need to answer. Make sure that this information is correct for the Organization that will be reflected by the certificate. Make sure that you type in the full state, not the abbreviation. Also make sure that your Organization Name is set to Tufts University. Example:
Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:Massachusetts Locality Name (eg, city) []:Medford Organization Name (eg, company) [Internet Widgets Pty Ltd]:Tufts University Organizational Unit Name (eg, section) []:Tufts Technology Services Common Name (eg, YOUR name) []:infoboard.tufts.edu Email Address []:ess@tufts.edu Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Additional Note: If you are generating a wildcard certificate, use " * " in the common name. I.e. *.infoboard.tufts.edu
The most common error people make is with the "common name". The common name is the name of the machine or service that needs the certificate. In the example above, people will go to the website http://infoboard.tufts.edu, so the certificate needs to be named infoboard.tufts.edu, even though the actual server name is jasper.usg.tufts.edu.
You will notice that in the example, a Private key named private.key and a public key (CSR) named public.csr was created. Your Private Key is not Encrypted!!Make the file only readable by the administrative account (for Unix machines):
chmod 400 private.key
(optional) To encrypt your private key, run the following command. If you're not sure whether to encrypt your private key, email cert-admin@tufts.edu:
/usr/bin/openssl rsa -in private.key -des3 -out secureprivate.key
- You also will want to make the file only readable by the administrative account (for Unix machines): chmod 400 secureprivate.key.
You can now remove the un-encrypted private key file from your server. You can dump the information in the CSR back into text form by running the following command:
/usr/bin/openssl req -text -noout -in public.csr
- You have now created the Key pair that you will use for your server. You can now submit the CSR that you created.
Troubleshooting Errors with Certificate Requests
If the certificate doesn't seem to be in PEM format, run
/usr/bin/openssl x509 -in certificate.crt -noout -text
If that generates an error (using certificate.crt as the certificate file), then run:
/usr/local/openssl/bin/openssl pkcs7 -inform PEM -in certificate.crt -print_certs -out new-certificate.crt
- Then you can run the first command on new-certificate.crt, and confirm it worked.
Verifying a Certificate
Once you receive the certificate, you can verify that the information in the cert is correct by running the following command from any machine with openssl installed:
openssl x509 -noout -text -in <certificate file name>
To check the entire cert chain of a remote server:
openssl s_client -connect hostname:port -showcerts
This information mirrored from intranet.uit.tufts.edu (before edits and correction)