Here are my (raw) notes on what is needed from certmonger (and what is needed on the IPA side):

Certmonger:

• Needs to talk to Dogtag directly.
• Dogtag has renewal profile that should work as is now, but we may find work is needed in Dogtag.
• Agent-renewal - authenticate as agent and supply serial number of certificate you want to renew. We should go this route, as it might allow renewal outside of validity period.
• Should have a dogtag-renewal CA model and a dogtag-fetch CA model. The renewal will be done on the IPA server where CRL generation takes place for shared certs. The fetch will be done on the other servers. Non-shared certificates will be renewed on each IPA server.
• After renewal or fetch, new cert will be put in NSS database(s), then run a script to restart necessary services.
• We might need to add a pre-hook to shutdown the CA before writing to the NSS database.

IPA:

• Needs to configure certmonger to track the proper certs and use the appropriate enrollment provider.
• Need to write post-scripts for restarting services. We might possibly need to modify Tomcat config.
• Need to add documentation describing the true "master" IPA server (CRL generation and renewal of shared certificates). Will need to describe procedure to promote another server in case this "master" dies.
• Post-script for renewal server that stores new serial number in LDAP.
• Enrollment provider for certmonger needed to fetch new certificate based off of old serial number.

How a new shared certificate is delivered to all other replicas? It is not enough to stick it into the NSS DB. It should be also placed into LDAP and replicated, right?

Replying to [comment:3 dpal]:

How a new shared certificate is delivered to all other replicas? It is not enough to stick it into the NSS DB. It should be also placed into LDAP and replicated, right?

The certificates are already replicated via Dogtag's cloning functionality, which we will reply upon for distribution. Certmonger on the replicas simply needs to fetch the new shared certificates on the replicas via the Dogtag interfaces, which will be handled in the IPA provided enrollment provider. Certmonger will then deal with updating the NSS databases and restarting the appropriate services via pre/post scripts.

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=835643

From Nalin:

certmonger's development head should be in a state where you can start using the "dogtag-ipa-renew-agent" CA. I still need to clean up some of the error diagnostic code so that it's useful when things aren't working perfectly, but it shouldn't affect how you interface with it

I'd advise against renewing your agent cert until you've got tooling to add the new one to the list of agents.

I have 0.58 built but I was under the impression that I'd use start-tracking and tell certmonger to use a different helper to do the renwal, in this case dogtag-ipa-renew-agent-submit. I don't see a way to set the helper in start-tracking though.

The detail that it's calling dogtag-ipa-renew-agent-submit to talk to the CA is a detail of how it talks to a CA that it calls dogtag-ipa-renew-agent, and you'd pass the CA's name in as the argument to the -c flag, so try adding -c dogtag-ipa-renew-agent to your command line.

-c isn't available to start-tracking

/usr/bin/ipa-getcert start-tracking -d /var/lib/pki-ca/alias/ -n 'subsystemCert cert-pki-ca' -c dogtag-ipa-renew-agent 
start-tracking: invalid option -- 'c'

The ipa-getcert command is basically getcert with -c IPA hard-coded into its argument list, so it has no use for the -c flag. Try /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n 'subsystemCert cert-pki-ca' -c dogtag-ipa-renew-agent instead.

Ok, that did the trick. I now have that cert monitored. I had to use the -P option to set the PIN since dogtag stores its PIN information in token:PIN format which isn't understood by certmonger (nor, perhaps, should it).

Have some manual success. I was able to twiddle the date and this subsystem cert was successfully renewed.

Configuring renewal is a rather complex endeavor.

One server is designated as the master. This is the server that will actually perform the renewals. The actual renewal is handled by certmonger. A new CA type, dogtag-ipa-renew-agent, is used to communicate directly with dogtag and renew the certificates. A post-update command is used to restart dogtag once the updated certificate is retrieved. This update script also adds the certificate to a new location in IPA, cn=$nickname,cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. Each entry may either not exist or hold only a single certificate. Only the most recent certificate is stored.

IPA will provide another new CA type to certmonger, dogtag-ipa-retrieve-agent-submit. This will be used by subordinate CAs to check this for an updated certificate. If an updated certificate is available then it is installed and dogtag restarted. If not then certmonger will go into the state CA_WORKING and check every 8 hours until an updated certificate is available.

The certmonger command ipa-getcert is really a shortcut for 'getcert list -c IPA'. To see all certificates that certmonger is tracking one needs to run 'getcert list' and pay close attention to the value of CA:.

The following dogtag certificates from /var/lib/pki-ca/alias are renewed on the master and retrieved by subordinates:

• auditSigningCert cert-pki-ca
• ocspSigningCert cert-pki-ca
• subsystemCert cert-pki-ca

The RA agent certificate, ipaCert in /etc/httpd/alias, is also tracked by certmonger and stored in LDAP. It is a special case in its own right. When this certificate is updated the certificate needs to be added to the entry uid=ipara,ou=People,o=ipaca in the dogtag LDAP server. The description attribute also needs to be updated to reflect the most current serial number. If this isn't done then IPA will be unauthorized to communicate with dogtag.

The full command to track a server on the master is:

# /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias/ -n 'subsystemCert cert-pki-ca' -c dogtag-ipa-renew-agent -P 820819542786

The value for -P is the pin for the internal database. It can be found in /var/lib/pki-ca/conf/password.conf.

To track the ipaCert run:

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

Tracking on the subordinate certificates is similar. We cheat and use -T which is normally the profile to renew using as a way to pass in the nickname.

The full command to track a server on a subordinate is:

# /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n "auditSigningCert cert-pki-ca" -c dogtag-ipa-retrieve-agent-submit -C '/usr/lib64/ipa/certmonger/restart_pkicad "auditSigningCert cert-pki-ca"' -P 429077983620 -T "auditSigningCert cert-pki-ca"

On upgrade the certificate tracking will need to be added. We determine which kind of tracking by trying to identify the master, currently defined as the first CA installed. It is possible that this CA no longer exists which means that user intervention would be required.

Each dogtag installation also has a tomcat SSL cert with the nickname 'Server-Cert cert-pki-ca'. This is renewed per-server using certmonger.

To test that certificate renewal you can force certmonger to request a new certificate with:

# getcert list

Pick an ID

# getcert resubmit -i <id>

Repeat this until it returns to the MONITORING state:

# getcert list -i <id>

On the master confirm that the certificate in cn=$nickname,cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX exists.

# ldapsearch -x -b 'cn=auditSigningCert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com'

Use certutil to verify that a new certificate was added:

# certutil -L -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' | grep Serial
Serial Number: 15 (0xf)[[br]]
Serial Number: 5 (0x5)

On a clone CA you can do the same thing. To test that the renewal must happen on the master first you can pick a nickname and run the resubmit on the clone first. The status should go into CA_WORKING.

Once a certificate is available on the master then renewing on the clone should work the same way.

You can also try moving time forward such that certmonger automatically triggers renewal. Care is required because the certificate expiration dates vary widely. You'll need to move forward in time slowly, renewing one certificate a time. By default certmonger will attempt to renew a certificate a week in advance.

master: 03837bf