This will most likely go through the agent-authenticated interfaces, so that we can request that a new version of a certificate will be issued, given the serial number of the certificate which is to be replaced.

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.

Replying to [comment:2 nkinder]:

• 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.

Would it look alright if ipa-server-install has to run getcert start-tracking with the -c dogtag-renewal option when telling certmonger to watch these certificates? We could wrap it up in a dogtag-renewal-getcert utility a la ipa-getcert, but at some point I think we're going to want to stop adding new things to everyone's $PATH unnecessarily.

• We might need to add a pre-hook to shutdown the CA before writing to the NSS database.

Per ticket #9, 0.57 introduced a -B flag which works similarly to the way the -C flag is handled, so that's ready.

IPA:
- Needs to configure certmonger to track the proper certs and use the appropriate enrollment provider.

I guess something along the lines of getcert start-tracking -c dogtag-renewal -B stop-the-server -C start-the-server ... will need to be added to the setup process. The name dogtag-renewal is open to change if anyone has a preference for something else.

• 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.

The commands will roughly be running getcert start-tracking with flags for the new values: -c to change to the dogtag-renewal CA from the dogtag-fetch "CA", and probably -C to change the command to a script which also stores the newly-issued certificate in the directory.

I think it is right and proper for ipa-server-install to tell certmonger to start tracking the certificates.

For the pre-hook we'll need to look carefully at the init/systemd scripts to be sure that when the script returns we can be assured that the NSS database is closed.

In an attempt to hopefully avoid painting myself into a corner in terms of naming things, this setup (dogtag in an IPA configuration, preferring renewal to new-certificate-enrollment whenever possible, approving its own requests using the agent certificate) is now called the dogtag-ipa-renew-agent CA, and will show up with that name by default in the list of known configurations when you run "getcert list-cas" against a sufficiently-new version of certmonger.

IPA's needs should be satisfied by 0.58, but I'll leave this ticket open while/until we figure out how non-agent and/or non-renewal cases should work. Notes so far:

1. Non-agent renewal and non-renewal.
   a. Submit using existing profileSubmit interface, since it's not authenticated.
   b. Keep polling using checkRequest, also not authenticated, while we're "pending".
   c. If the request state goes to "complete", fetch the new certificate.
2. Agent non-renewal.
   a. Submit using existing profileSubmit interface, since it's not authenticated.
   b. Review and approve using defaults? What if we need to provide actual values to fill in the certificate extensions? Where would they come from?
   c. Fetch the new certificate.