-
Notifications
You must be signed in to change notification settings - Fork 6
Renewing Authority Certificates
This documentation was created in 2013 to renew the original portal certificates. It may be incorrect but should provide a template for renewing certificates in 2018 when the current clearinghouse certificates (root, MA, SA, etc.) are set to expire.
Throughout this page you'll need to examine certificates. Use {{{openssl}}} as follows to get a textual representation of the certificate:
openssl x509 -text -noout -in /path/to/cert.pem
To renew the a clearinghouse root certificate, we need to create a new self-signed certificate with the same private key, subject DN, serial number, and extensions. This handy command does all of that:
# First, make a backup copy of the CA certificate
mv /usr/share/geni-ch/CA/cacert.pem /usr/share/geni-ch/CA/cacert-old.pem
# Now create a new certificate, good for a year
openssl x509 -in /usr/share/geni-ch/CA/cacert-old.pem -signkey /usr/share/geni-ch/CA/private/cakey.pem -days 365 -out cacert.pem
Now examine the certificate in {{{ cacert.pem }}} to verify that it has the following in common with the original:
- the same subject DN
- the same serial number
- extensions
- the URN in !SubjectAltName is the same
- it is a CA ("CA:TRUE")
If all of that is true, move the new certificate in place:
mv cacert.pem /usr/share/geni-ch/CA/cacert.pem
The command above will only create self-signed certificates. To renew the service certificates, we still need to use the same private key, subject DN, serial number, and extensions. It's just a little bit harder.
This block used to highlight the service information in red boxes. That isn't happening below. Look for the HTML "span" tags to see where those are.
!#html
<pre style="background: #f7f7f7; border: 1px solid #d7d7d7; margin: 1em 1.75em; padding: .25em;">
Certificate:
Data:
Version: 3 (0x2)
Serial Number: <span style="background: #fff; border: 2px outset #f00;">113</span> (0x71)
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=dagoola.gpolab.bbn.com
Validity
Not Before: May 23 17:04:42 2012 GMT
Not After : May 23 17:04:42 2013 GMT
Subject: <span style="background: #fff; border: 2px outset #f00;">O=dagoola, OU=authority, OU=sa, CN=63644f30-a4f9-11e1-a69c-000c29eccc53/[email protected]</span>
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:cf:ae:56:c6:e6:df:18:1f:04:8b:68:6b:f8:ab:
14:1e:74:35:38:ab:99:3a:85:f2:8b:2c:fd:e3:b6:
59:4f:60:40:71:57:79:82:1f:4b:ee:aa:b0:60:a7:
fe:b8:51:d2:3e:4b:36:ea:d6:6d:26:8b:92:73:78:
ac:18:c1:64:2a:b0:c4:f2:20:68:04:05:ad:9d:ac:
1b:a2:1c:34:db:b5:29:15:a6:15:99:8b:2b:6f:8a:
d0:3c:d3:66:1b:69:20:4e:c2:a5:25:e6:a0:85:b6:
d3:5a:b4:ee:5d:80:80:8b:2d:83:a6:63:e5:ba:33:
39:b1:d6:10:46:80:07:53:d1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
5F:39:77:03:47:DD:25:00:2D:A1:B7:F6:37:81:2C:FE:25:97:74:B8
X509v3 Authority Key Identifier:
keyid:9F:3E:0B:D2:1D:B8:03:BB:F1:97:38:93:D9:DD:5C:46:E6:69:00:1C
DirName:/CN=dagoola.gpolab.bbn.com
serial:BA:5A:9F:30:D5:B0:D2:E8
Authority Information Access:
2.25.305821105408246119474742976030998643995 - URI:https://example.geni.net/info.html
X509v3 Subject Alternative Name:
email:[email protected], <span style="background: #fff; border: 2px outset #f00;">URI:urn:publicid:IDN+dagoola+authority+sa</span>, <span style="background: #fff; border: 2px outset #f00;">URI:uuid:63644f30-a4f9-11e1-a69c-000c29eccc53</span>
X509v3 Basic Constraints:
CA:<span style="background: #fff; border: 2px outset #f00;">TRUE</span>
Signature Algorithm: sha1WithRSAEncryption
02:3e:89:55:bc:f7:f4:8e:1d:65:b0:aa:a8:f1:c9:a1:38:4e:
36:bd:8c:9c:3e:d6:d5:0a:d6:04:9b:36:ac:15:81:af:98:0e:
fc:ae:d3:ef:2f:2b:80:67:c8:da:cf:11:b3:fb:fb:f0:de:82:
40:75:5c:ac:6b:65:8c:4b:87:68:b4:ac:c6:f9:c5:85:11:00:
63:09:1e:58:ac:1d:b6:8d:14:6e:4a:8d:50:1a:59:b6:c3:a4:
d8:74:d5:31:38:61:15:e2:0c:de:35:e9:3c:af:d7:ea:90:ae:
a5:70:51:19:68:36:e6:e4:86:d0:ec:9a:16:21:5b:5a:61:83:
d9:36
- Extract information from the certificate - see above certificate for the highlighted information. Here it is in shell form:
Note: The UUID should have prefix "URI:urn:uuid:" not "URI:uuid:". This was a bug in the original service certificates
SERVICE_SERIAL="113"
# Note this is transformed from above to be in the form required by the openssl command below
SERVICE_SUBJECT="/O=dagoola/OU=authority/OU=sa/CN=63644f30-a4f9-11e1-a69c-000c29eccc53/[email protected]"
SERVICE_URN="URI:urn:publicid:IDN+dagoola+authority+sa"
# Note the addition of ":urn" to the UUID URI -- this corrects an error in the original service certs
SERVICE_UUID="URI:urn:uuid:63644f30-a4f9-11e1-a69c-000c29eccc53"
# Note case change -- not sure if it matters
SERVICE_CA="true"
SERVICE_KEY="/usr/share/geni-ch/sa/sa-key.pem"
SERVICE_CSR="/tmp/sa-req.pem"
EXT_FILE="/tmp/sa-ext.ini"
SERVICE_CERT="/tmp/sa-cert.pem"
-
Create a certificate signing request (CSR) with the correct subject DN:
openssl req -new -subj $SERVICE_SUBJECT -key $SERVICE_KEY -out $SERVICE_CSR
-
Create an extension file with the correct information for the X509 v3 Extensions:
echo "[geni]" > $EXT_FILE echo "subjectKeyIdentifier=hash" >> $EXT_FILE echo "authorityKeyIdentifier=keyid:always,issuer:always" >> $EXT_FILE echo "authorityInfoAccess = 2.25.305821105408246119474742976030998643995;URI:https://ch.geni.net/cainfo.html" >> $EXT_FILE echo "subjectAltName=email:copy,$SERVICE_URN,$SERVICE_UUID" >> $EXT_FILE echo "basicConstraints = CA:$SERVICE_CA" >> $EXT_FILE -
Sign the CSR with the root certificate:
openssl x509 -req -in $SERVICE_CSR -extfile $EXT_FILE -extensions geni -CA /usr/share/geni-ch/CA/cacert.pem \ -CAkey /usr/share/geni-ch/CA/private/cakey.pem -set_serial $SERVICE_SERIAL -out $SERVICE_CERT -
''After verifying the contents of the new certificate'', move the new certificate into place:
mv $SERVICE_CERT /usr/share/geni-ch/sa/sa-cert.pem
After the service certificates have been generated, copy the portal and km service certs to the Portal server
On CH Host:
cp /usr/share/geni-ch/portal/portal-*.pem /tmp
cp /usr/share/geni-ch/km/km-*.pem /tmp
scp /tmp/portal-*.pem /tmp/km-*.pem $PORTAL_HOST:/tmp
On Portal Host:
sudo cp /tmp/portal-*.pem /usr/share/geni-ch/portal
sudo cp /tmp/km-*.pem /usr/share/geni-ch/km
- Replace the CA and MA certificates in this bundle
The wiki page http://groups.geni.net/geni/wiki/GeniTrustAnchors has to be updated. The sections that need to be updated to reflect the change are
- The table row called GENI clearinghouse
- The attachment called geni-cert-bundle.tar.gz . This is a trust bundle that contains the certs from the GENI CA and GENI MA, Utah SA and Utah CH. All that needs to be done here is to update the GENI CA and MA pem files. Then re-create the bundle and upload it.
Updating the certificates at the Clearing House and the Portal is not the only thing. The backbone of the GENI - the CA / MA certificates is what is used by all GENI Entities/Aggregates/Tools for its Authz/Auth . The below listed parties have to be contacted to get the GENI CA cert updated on their end.
- Instageni Racks and Utah Stitch aggregate (Instageni Team at Utah) : Just provide them with the GENI CA cert. Once they update the bundle on their end, the cronjob on the racks should update the bundle nightly.
- Exogeni Racks(Exogeni Team at Renci) : They require both the CA and MA cert
- Test SCS (Xi at Maryland) : They require both the CA and MA cert
- Production SCS (AJ at Internet2) : They require both the CA and MA cert
- AL2S Aggregate Manager (AJ at Internet2) : They require both the CA and MA cert . They use the geni-cert-bundle from the wiki page mentioned.
- Monitoring Checkstore server (Kentucky Team): They require the CA cert file .
- GeniDesktop Tool (Kentucky Team): New tool cert had to be issued . Have to request for a CSR from them . Follow the doc to issue a new tool cert.
- GeniMon Tool (Kentucky Team): New tool cert had to be issued . Have to request for a CSR from them . Follow the doc to issue a new tool cert.
- Monitoring Checkstore Tool (Kentucky Team): New tool cert had to be issued . Have to request for a CSR from them . Follow the doc to issue a new tool cert.
To verify the MA certificate, we do the following:
openssl verify -CAfile ca1-cert.pem ma-cert.pem
What does this mean?
If we need to renew the panther certificates, we need to:
- create a new self-signed root certificate as above (but with the proper extensions)
- renew the service certificates using a similar method
- renew user certificates on demand as the need arises
- Early user certificates appear to expire in February, 2014, but we need to verify this.
- Both inside and outside certificates need to be renewed.
- We probably want to do outside certificates automatically, with no user involvement
- Users who have downloaded their outside certificates will automatically get a new one when they download
- Note: we probably want the new certificate available some weeks before the old one expires
- Note also: we probably should notify the user (via email (?) and the portal) that a new certificate is available for download
- Slice certificates also have to renewed. Currently there is a bug in the source code. Issue #605
- We (Hussam Nasir) has some script to do some of these, but cannot be published. Please contact him at [email protected] for these.