Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/72cfcfa0bd1e867537fcc788512e5fca20708b83
ipa-4-2:
https://fedorahosted.org/freeipa/changeset/3973da56d334040d9fee88d52c38265066debd56

Honza,

How can I test this?

Do I need to test cert renewal for ipaCert?  Or check that the ipakra user is indeed created in DS?

Thanks,
Scott

You need to check that ipa-kra-install works after the CA admin certificate is expired. You can find the certificate + private key in /root/ca-agent.p12.

I guess the easiest way to make it expired is to change system time. The certificate is valid for 2 years, which is the same as most certmonger-tracked certificates. In order not to break certificate renewal by the time change, you first need to change the time to 2 years minus ~2 weeks in the future, let certmonger renew the certificates, then change the time to a few days after the CA admin certificate expiration date.

Ok, I attempted to run this verification and ran into a problem.

      [1/7]: configuring KRA instance
    Failed to configure KRA instance: Command ''/usr/sbin/pkispawn' '-s' 'KRA' '-f' '/tmp/tmppcz59P'' returned non-zero exit status 1
    See the installation logs and the following files/directories for more information:
      /var/log/pki-ca-install.log
      /var/log/pki/pki-tomcat
      [error] RuntimeError: KRA configuration failed.
     
    Your system may be partly configured.
    Run ipa-kra-install --uninstall to clean up.
     
    KRA configuration failed.


That was after cert renewal. 

From /var/log/pki/pki-tomcat/kra/debug:

[07/Sep/2017:15:22:03][http-bio-8443-exec-3]: Found data for 'sslserver'
java.lang.NullPointerException

/var/lib/pki/pki-tomcat/ca/conf/CS.cfg had the following properties:

ca.sslserver.cert
ca.sslserver.nickname
ca.sslserver.tokenname

But, it did not contain:

ca.sslserver.certreq

So, this looks like I hit bug #1258630  while trying to verify this bug.  Marking this one as depends on that.

Adding Endi to bug since he helped me troubleshoot the issue above.

Ok, with the fix for bug #1258630 and using the workaround from that bug (listed below) I was able to see this work.

http://pki.fedoraproject.org/wiki/Subsystem_Certificate_Cache

Verified.

Version ::

pki-ca-10.2.5-6.el7.noarch
ipa-server-4.2.0-11.el7.x86_64

Results ::

Installed IPA server first.

[root@master ~]# openssl pkcs12 -in /root/ca-agent.p12 -out /root/ca-agent.pem
Enter Import Password:
MAC verified OK
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
Verify failure
[root@master ~]# openssl x509 -in /root/ca-agent.pem -noout -enddate
notAfter=Sep 12 15:03:38 2017 GMT

So will move date to Aug 29th for 2 weeks prior.

[root@master ~]# date
Wed Sep 23 13:22:23 CDT 2015
[root@master ~]# date 082915032017
Tue Aug 29 15:03:00 CDT 2017

[root@master ~]# sleep 500; date; getcert list|egrep -i "status|expires"
Tue Aug 29 15:11:29 CDT 2017
	status: MONITORING
	expires: 2019-08-19 20:07:03 UTC
	status: MONITORING
	expires: 2019-08-19 20:06:12 UTC
	status: MONITORING
	expires: 2019-08-19 20:06:23 UTC
	status: MONITORING
	expires: 2035-09-23 15:03:36 UTC
	status: MONITORING
	expires: 2019-08-19 20:05:43 UTC
	status: MONITORING
	expires: 2019-08-19 20:05:18 UTC
	status: MONITORING
	expires: 2019-08-30 20:05:10 UTC
	status: MONITORING
	expires: 2019-08-30 20:05:03 UTC

[root@master ~]# pki-server subsystem-cert-update ca sslserver
-----------------------------------------
Updated "sslserver" subsystem certificate
-----------------------------------------
  Cert ID: sslserver
  Nickname: Server-Cert cert-pki-ca
  Token: Internal Key Storage Token
  Certificate: <base64blob>
  Request: <base64blob>

Then following the link from above, I went ahead and followed the directions to fix all the missing requests.

[root@master ~]# pki-server subsystem-cert-update ca ocsp_signing
--------------------------------------------
Updated "ocsp_signing" subsystem certificate
--------------------------------------------
  Cert ID: ocsp_signing
  Nickname: ocspSigningCert cert-pki-ca
  Token: Internal Key Storage Token
  Certificate: <base64blob>
  Request: <base64blob>

[root@master ~]# pki-server subsystem-cert-update ca subsystem
-----------------------------------------
Updated "subsystem" subsystem certificate
-----------------------------------------
  Cert ID: subsystem
  Nickname: subsystemCert cert-pki-ca
  Token: Internal Key Storage Token
  Certificate: <base64blob>
  Request: <base64blob>

[root@master ~]# pki-server subsystem-cert-update ca audit_signing
---------------------------------------------
Updated "audit_signing" subsystem certificate
---------------------------------------------
  Cert ID: audit_signing
  Nickname: auditSigningCert cert-pki-ca
  Token: Internal Key Storage Token
  Certificate: <base64blob>
  Request: <base64blob>

Then, I finally tried ipa-kra-install.
[root@master ~]# ipa-kra-install -p Secret123 -U

===================================================================
This program will setup Dogtag KRA for the IPA Server.


Configuring KRA server (pki-tomcatd). Estimated time: 2 minutes 6 seconds
  [1/8]: configuring KRA instance
  [2/8]: create KRA agent
  [3/8]: restarting KRA
  [4/8]: configure certmonger for renewals
  [5/8]: configure certificate renewals
  [6/8]: configure HTTP to proxy connections
  [7/8]: add vault container
  [8/8]: apply LDAP updates
Done configuring KRA server (pki-tomcatd).
Restarting the directory server
The ipa-kra-install command was successful

[root@master ~]# rpm -q ipa-server 
ipa-server-4.2.0-11.el7.x86_64

[root@master ~]# date
Fri Sep 15 15:13:52 CDT 2017

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2362.html