Vaede, Roger (Contractor) wrote:
I cannot upgrade to IPA 3.0 at this time, these are live machines.
I only want to renew only the primary server the one that has an expired 
How can I tell if the server is running on CA?

If you do a search like this:

# ldapsearch -LLL -Y GSSAPI -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com cn

You'll get a listing, per-master, of the services on it. Look for the CA service.

Some of the certificates are common among multiple CA replicas, and some are machine-specific. They can be renewed only one one master and then copied to the others, this is why I asked.

As you'll see, this process is rather hairy and prone to error. I've done this any number of times on an IPA 3.x server while I worked on automating it but AFAIK never on a 2.x one. In theory it should work the same. In theory.

The first thing you'll need to do is get a newer version of certmonger, at least certmonger-0.61-3.el6.

IIRC you are currently tracking a bunch of bogus certs in certmonger. I'd one by one stop tracking them:

# getcert list | grep Request

for each cert do

# getcert stop-tracking -i <request_id>

Next, you need to determine the PIN for the CA NSS database:

# grep internal= /var/lib/pki-ca/conf/password.conf

Now we need to tell certmonger about all the CA certificates it needs to renew

for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca"
/usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n \"${nickname}\" -c dogtag-ipa-renew-agent -P <internal pin>

We also need to renew the agent certificate that IPA uses to authenticate:

# /usr/bin/getcert start-tracking -d /etc/httpd/alias -n ipaCert -c dogtag-ipa-renew-agent -p /etc/httpd/alias/pwdfile.txt

Use "getcert list" to confirm that these 5 certs are now being tracked and note the Request IDs.

Now time for the wayback machine, go back to when these certs are all still valid. I'd recommend a day or two before the earliest expiration.

You can force a renewal with:

 # getcert resubmit -i <request_id>

Do this for each one. Each should end up in a MONITORING state.

Double-check that the audit certificate has a trust of u,u,Pu. If not you can fix this with:

# certutil -M -n "auditSigningCert cert-pki-ca" -d /var/lib/pki-ca/alias -t u,u,Pu

Ok, now things get really fun. The dogtag configuration file has a base64-encoded copy of most of these certificates in it. You'll need to update those by hand.

What I'd recommend is for each nickname in /var/lib/pki-ca/alias do:

certutil -L -d /var/lib/pki-ca/alias -n <nickname> -a > /tmp/nickname

Then edit /etc/pki-ca/CS.cfg and find the cert entry for each one and replace the blobs. The option names are like ca.audit_signing.cert, ca.ocsp_signing.cert, etc. It should be fairly straightforward. There are 5 certs you need to replace.

Here are the nicknames and values:

'auditSigningCert cert-pki-ca': 'ca.audit_signing.cert'
'ocspSigningCert cert-pki-ca': 'ca.ocsp_signing.cert'
'caSigningCert cert-pki-ca': 'ca.signing.cert'
'subsystemCert cert-pki-ca': 'ca.subsystem.cert'
'Server-Cert cert-pki-ca': 'ca.sslserver.cert'

Note that the output from certutil will be in PEM format, with headers and broken on a 64-character line. You'll need to drop the header/footer and make them into a single line.

Backing up this file in advance would be a good idea.

Now you can try to restart the CA to see what happens. It should come up fine:

# /sbin/service pki-cad restart

For the ipaCert value in /etc/httpd/alias you have another job to do. The certificates allowed to authenticate are stored in the CA LDAP database. You'll need to use ldapmodify to fix things up.

Start by looking at the new value for ipaCert. You need to do two things:

# certutil -L -d /etc/httpd/alias -n ipaCert

Note the value of serial number.

Next you need the base64-encoded value of the cert like before:

# certutil -L -d /etc/httpd/alias -n ipaCert -a

Again you'll need to drop the header/footer and combine this into a single line.

Next see what is already there with:

# ldapsearch -x -h localhost -p 7389 -D 'cn=directory manager' -W -b uid=ipara,ou=People,o=ipaca

You need to replace the serial number in the description attribute with the new one. The serial number is the 2nd number. The format of the description line is:

2;<serial number>;<issuer subject>;<subject>

The change is going to look something like:

# ldapmodify -x -h localhost -p 7389 -D 'cn=directory manager' -W
dn: uid=ipara,ou=People,o=ipaca
changetype: modify
add: usercertificate;binary
usercertificate;binary: MII...=
replace: description
description: 2;9;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.COM
<extra blank line to finish>
^D to exit

Now tackle the Apache and 389-ds certs:

# /usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-REALM -n Server-Cert -p /etc/dirsrv/slapd-REALM/pwdfile.txt

# /usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt

# /usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt

Use getcert to check the status of these and resubmit as needed. It may be that certmonger will notice they are near expiration time and renew automagically.

Restart those services:

# /sbin/service httpd restart
# /sbin/service dirsrv restart

Return to present day.

Now test to see if the new certs are working:

# kinit admin
# ipa cert-show 1

This simple command actually exercises everything fairly well.

If you've done everything right, and I managed to not miss a step, it should return the cert and you're done. Further testing might include adding a test host and generating a certificate for it.

In the future, when these certificates expire again, you'll still have to do some of this manual labor. The certificates themselves should renew ok, but you'll need to update the configuration files and the o=ipara entry manually.


Thanks for your help on this Rob.


-----Original Message-----
From: Rob Crittenden []
Sent: Wednesday, October 30, 2013 5:07 PM
To: Vaede, Roger (Contractor); ''
Subject: Re: [Freeipa-devel] certificate renewal

Vaede, Roger (Contractor) wrote:
There are two location of the alias:
In the backup:  /etc/httpd/alias/
In the one that has expired:  /var/lib/pki-ca/alias

These are separate entities and will need to be dealt with seprately.
/var/lib/pki-ca/alias is the NSS database that contains the certificates for 
the CA itself. With the subsystem certs being expired it means that the CA 
itself is basically dead in the water because nothing can talk to it.

We're really moving into some uncharted waters here. I don't really want to 
recommend upgrading to 3.0 just to get the certs renewed, though there are lots 
of other good reasons to upgrade. I don't know what will happen if we try to 
renew the certs using the 3.0 method on a 2.x server.

So you've got two IPA masters. Are you running the CA on both or only on one? 
It makes a difference in how we do the renewal because it will be more complex 
if you have it on both (not a show stopper).

I *think* we can use the latest certmonger to do the majority of the heavy 
lifting. The basic process will be to update those bits, go back in time, the 
tell it to start tracking the CA certs one by one and get them renewed. We'll 
need to do the same with some other certs, some of which are in 
/etc/httpd/alias and some of which are in /etc/dirsrv/slapd-REALM/. If you have 
another instance of the CA we'll need to extract some of the renewed certs and 
import them on the other side. Then we return to present time.

So let me know what your environment looks like and I'll try to come up with 
some steps to do the renewal.


Freeipa-devel mailing list

Reply via email to