This bug will block one IdM use case of Bug 886645 - marking it as blocker of this RFE.

By default, the CA is not supposed to issue certs beyond its own expiration date.

The way to bypass the CA validity constraint is to manually turn on the "Bypass CA notAfter constraint:" check box at the agent approval page of the request.

I have added the line

    policyset.caCertSet.2.default.params.bypassCAnotafter=true

to /var/lib/pki/pki-tomcat/ca/profiles/ca/caCACert.cfg and restarted pki-tomcatd@pki-tomcat and then renewed the certificate. The renewed certificate still has the same expiration date as the old certificate.

Anyway, I don't think the constraint makes sense when renewing the self-signed root CA certificate, because it makes the renewed certificate useless, given that the usual reason for the renewal is that the certificate is nearing its expiration date. IMO in this case the renewed certificate should be allowed to have expiration date past the expiration date of the original certificate by default.

Hi Jan.
First, I'd like to explain that we made sure that the "bypass" capability can only be manually enabled by the agent on a per-request basis as a security measure to not violate the policies by accident.
Therefore, adding the bypassCAnotafter=true in the enrollment profile for automatic approval was intentionally left out by design.

After talking to Nathan, I will loosen it and add such "bypass" capability in the CAValidityDefault.

Hi Jan,
Could you please attach your renewal profile and include any special instruction (if needed) so I can test against my patch?
Thank you.

Created attachment 945248 [details]
CA cert profile

> Hi Jan.
> First, I'd like to explain that we made sure that the "bypass" capability
> can only be manually enabled by the agent on a per-request basis as a
> security measure to not violate the policies by accident.
> Therefore, adding the bypassCAnotafter=true in the enrollment profile for
> automatic approval was intentionally left out by design.

I see, makes sense.

> 
> After talking to Nathan, I will loosen it and add such "bypass" capability
> in the CAValidityDefault.

Does this mean that it would be possible to specify bypassCAnotafter in the profile after all?

IMO what I suggested (check if cert is self-signed and is renewing itself => automatically allow bypassCAnotafter) might be more useful, but the decision is yours of course.

> Could you please attach your renewal profile and include any special
> instruction (if needed) so I can test against my patch?
> Thank you.

Profile attached (it's the default caCACert.cfg with the bypass line added).

I'm doing the renewal using IPA 4.1 ipa-cacert-manage command. I can test your patch myself, if you can provide RPMs to me.

Created attachment 945442 [details]
revised CAValidityDefault class that handles bypassCAnotafter

Attached is the the CAValidityDefault.class that you can plug into your Dogtag instance without swapping out the whole rpm.  Once you are happy with the behavior, I will roll that into the official src and build for real.

Instruction on applying the plugin class:
* go to <Dogtag inst directory>/ca/webapps/ca/WEB-INF/classes
* mkdir -p com/netscape/cms/profile/def
* put the class in there

I took a look of your caCACert.cfg and find it very curious.  There is no authentication or authorization specified, which means that it is a manual approval.  I'm curious how you manually approve it with IPA?  Do you actually send in a 2nd call as an agent to approve it?

The following is what I'd do to do renewal the right way:
* cd <Dogtag inst directory>/ca/profiles/ca
* create a file called caCACertRenewal.cfg
(the following is my example of how I tested it)
content of my caCACertRenewal.cfg
----
desc=This certificate profile is for renewing CA signing certificates.
name=Renewal: auto-renew CA signing certificates
visible=false
enable=true
enableBy=admin
renewal=true
# note this means you will need to have a user that has his cert in the 
# Certificate Manager Agents group
# You could configure it different for example:
#   auth.instance_id=UserDirEnrollment
#   authz.acl=group="Subsystem Group"
#  that means you need to be a user in the "Subsystem Group"
auth.instance_id=AgentCertAuth
input.list=i1
input.i1.class_id=serialNumRenewInputImpl
output.list=o1
output.o1.class_id=certOutputImpl
-----I added comments above for your info-----
* now add the new profile in the CS.cfg
profile.caCACertRenewal.class_id=caEnrollImpl
profile.caCACertRenewal.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caCACertRenewal.cfg
then search for "profile.list=" and add "caCACertRenewal.cfg" to the end of the list

* now make sure caCACert.cfg has the following line:
policyset.caCertSet.2.default.params.bypassCAnotafter=true

* restart the server

* point your application to the caCACertRenewal profile and provide the CA signing cert's serial number.  Provided you pass the authentication and authorizaiton, it will renew the cert for you based on the serial number you provided.

Once you are happy, you should add grace period to make sure the CA signing cert is not renewed prematurely by mistake (by default, we did not add that in the caCACert.cfg, because we did not expect people to do auto-renewal with CA signing certs!)
* edit your caCACert.cfg
add
policyset.caCertSet.11.constraint.class_id=renewGracePeriodConstraintImpl
policyset.caCertSet.11.constraint.name=Renewal Grace Period Constraint
## that means one is not allowed to renew 1/2 year before expiration
## and 30 days after expiration -- you can adjust that
policyset.caCertSet.11.constraint.params.renewal.graceBefore=182
policyset.caCertSet.11.constraint.params.renewal.graceAfter=30
policyset.caCertSet.11.default.class_id=noDefaultImpl
policyset.caCertSet.11.default.name=No Default
Change the following line:
policyset.caCertSet.list=1,2,3,4,5,6,8,9,10
to
policyset.caCertSet.list=1,11,2,3,4,5,6,8,9,10

Again, I don't know how your ipa does the approval (seeing the apparent missing auths and authz parameters in the profile), so the above is just for your info.

I hope I didn't miss anything.  let me know how it goes.

oops.  copy/paste issue.  The line in my last comment:
then search for "profile.list=" and add "caCACertRenewal.cfg" to the end of the list
should read
then search for "profile.list=" and add "caCACertRenewal" to the end of the list

(In reply to Christina Fu from comment #8)
> Attached is the the CAValidityDefault.class that you can plug into your
> Dogtag instance without swapping out the whole rpm.  Once you are happy with
> the behavior, I will roll that into the official src and build for real.
> 
> Instruction on applying the plugin class:
> * go to <Dogtag inst directory>/ca/webapps/ca/WEB-INF/classes
> * mkdir -p com/netscape/cms/profile/def
> * put the class in there

Unfortunately that did not fix the issue for me, using the caCACert.cfg profile I have attached.

> I took a look of your caCACert.cfg and find it very curious.  There is no
> authentication or authorization specified, which means that it is a manual
> approval.  I'm curious how you manually approve it with IPA?  Do you
> actually send in a 2nd call as an agent to approve it?

Yes, that is how IPA (or rather certmonger's dogtag-ipa-renew-agent-submit helper) does it. IPA creates an agent user called "IPA RA" on install and uses it internally for approvals.

> Again, I don't know how your ipa does the approval (seeing the apparent
> missing auths and authz parameters in the profile), so the above is just for
> your info.

Thanks, I appreciate it.

ok, I see.  That confirmed my suspicion.  IPA uses what we would call "Manual approval" instead of taking advantage of the "auto-approval" mechanism. 
"Manual approval" takes on a different code path.

What you need to do is to add the extra input parameter when you send in the 2nd (approval) request: (You might have to play around with it... not sure if you need quotes around "true" or not)
bypassCAnotafter=true

When crafted correctly in the approval request, that parameter should work with the existing code without patch.

Let me know how it works out.

The procedure recommended by Christina is working.  Jan mentioned that he would still like to see  some support for renewing the CA signing certificate.  We will need to discuss this RFE further, but this can be pushed out to RHEL 7.2 for the time being since we won't be doing anything additional for RHEL 7.1.

Per discussions in the RHEL 7.3 Triage meeting of 01/06/2016: RHEL 7.4.

Upstream ticket:
https://fedorahosted.org/pki/ticket/1725

Per RHEL 7.5.z/7.6/8.0 Triage:

cfu: close RHEL bug CLOSED UPSTREAM, keep upstream ticket in FUTURE