nanuna website trust certificate renewal

From Nanuna internal
Jump to: navigation, search

Obtaining certificate files

Apache on nanuna uses trust certificates from InCommon. These certificates have a defined lifetime. At least a month before they expire, InCommon will send email to the email address they have on record for that certificate. The address they currently have on record is Here is an example of an expiration warning email:

From: Certificate Services Manager
Subject: WARNING: Expiration Notice: InCommon SSL certificate for

Date: September 29, 2014 at 4:11 PM
To: requesterSSL

Your InCommon SSL certificate for will expire soon. Date and time of expiration:
10/13/2014 23:59:59 GMT. Certificate Details: Common Name : Subject Alternative
Names : Number of licenses : SSL Type : InCommon SSL Term : 3 Year(s) Server : Apache/ModSSL Requested :
10/13/2011 16:41:05 GMT Approved : 10/14/2011 00:53:47 GMT Expires : 10/13/2014 23:59:59 GMT Order
Number : 10847435 Self-Enrollment Certificate ID : 79796 Comments : Certificate Manager Cert : Yes To
renew your certificate, submit a new CSR at
action=enroll. When the new CSR is approved, it will not revoke the existing certificate. The existing
certificate will expire normally.

Note that embedded in the warning email is a URL for where the renewal process begins. In the above example the address is This site requires two items: 1, an access code and 2, an E-mail address.

The access code is the supplied by OIT. Last time we renewed, it had not changed from three years prior. The code should be kept private. It is stored in the UAF group in KeePass as Nanuna InCommon Trust Certificate Access Code.

The E-mail address is also stored in KeePass, and as noted above, is This group address is used to improve odds that someone in that list paying attention.

In order to complete the renewal request a Certificate Signing Request (CSR) must be created. For background on how to do this, InCommon recommends this site:

Here is an example of how to run it on nanuna. The bolded parts are what needs entered. Otherwise, the defaults are accepted:

jemcgill@nanuna:~$ mkdir cert
jemcgill@nanuna:~$ cd cert
jemcgill@nanuna:~/cert$ ls
jemcgill@nanuna:~/cert$ openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out nanuna.csr  
Generating a 2048 bit RSA private key
writing new private key to 'myserver.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) [AU]:US
State or Province Name (full name) [Some-State]:Alaska
Locality Name (eg, city) []:Fairbanks
Organization Name (eg, company) [Internet Widgits Pty Ltd]:University of Alaska Fairbanks
Organizational Unit Name (eg, section) []:Geophysical Institute
Common Name (e.g. server FQDN or YOUR name) []
Email Address []:                   

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
jemcgill@nanuna:~/cert$ ls
myserver.key  nanuna.csr
jemcgill@nanuna:~/cert$ cat nanuna.csr

Once you have the CSR, you can go back to, sign in, and fill out the requested fields.

Within a day or two, InCommon will send email saying the SSL certificate request was approved. In a separate message they will send links to various forms of certificates for download. Download them all, and put them in a secure (permission 400) on nanuna. Then send email to the nanuna system admins to let them know they are ready.

Updating certificate

Next SSL certificate update: 10/5/2017.

Explanation of Incommon files:

X509-Base64Encoded file contains all certs: root, intermediate2, intermediate1, nanuna
Certificate-only file contains only nanuna's cert
Intermediates-root-only contains root, intermediate2, intermediate1
Intermediates-root-only-reverse contains intermediate1, intermediate2, root

The file "Intermediates-root-only-Reverse" file is the same as the "root-only" except the certificates are listed in reverse order.

Note that there are now 2 intermediate certificates. The certificates are placed under /etc/apache2/ssl, and create symlinks to the certificates using the 8-byte hash value with a ".0" appended:

openssl x509 -noout -hash -in ca-certificate-file.crt
ln -s ca-certificate-file.crt hash.0

We then need configure Apache to use the new certificates via the directives:

SSLCertificateFile /etc/apache2/ssl/cert-X.crt
SSLCertificateKeyFile /etc/apache2/ssl/key-X.crt
SSLCACertificateFile /etc/apache2/ssl/interm-X.crt

for the certificate, key, and (intermediate) certificate authority (intermediate1 followed by intermediate2), respectively. The root certificate is accessible in your browser. As of the last update, there are now 2 intermediate certificates, so both need to go in the interm-X.crt file.

Here is a quick summary of the SHA fingerprints:

1. Nanuna Certificate
96 E4 D8 16 67 48 CE 9E 78 5E D3 2E CC F8 D8 56 07 06 5B 2D

2. Intermediate Certificates (2):

InCommon RSA Server
F5 FB 01 DE A6 E5 9C A6 DD 05 70 54 F4 A3 FF 72 DD E1 D5 C6
UserTrust RSA Certification Authority
EA B0 40 68 9A 0D 80 5B 5D 6F D6 54 FC 16 8C FF 00 B7 8B E3

3. Root Certificate (in browser)

AddTrust External CA Root
02 FA F3 E2 91 43 54 68 60 78 57 69 4D F5 E4 5B 68 85 18 68

Useful link as of 12/19/2014 for finding out information of Incommon certificates:

The latest version of major browsers (Firefox, Chrome, Safari, and Internet Explorer) should be checked to ensure that the SSL certificate works properly. Internet Explorer and Safari tend to be a bit more lenient than Firefox, so they can be used to help debug issues validation of SSL certificates, for example by checking the fingerprint against the command:

 openssl x509 -noout -fingerprint -in ca-certificate-file
Personal tools