#572 CRL scheduler adds extra CRL generation at midnight for daily schedules
Closed: Fixed None Opened 11 years ago by nkinder.

CRL scheduler adds extra CRL generation at midnight for daily schedules.

For example if
ca.crl.MasterCRL.dailyUpdates=17:44,17:46
CRL should be generated at 17:44 and 17:46 today and every day after.

Instead CRLs are generated at 17:44, 17:46, and midnight.


proposed Milestone: 10.2.3 - Per Dogtag 10.2.3 meeting of 09/25/2014

Per Dogtag 10.2.X meeting of 01/14/2015: Milestone 10.2.2

Per 10.2.2 Triage meeting of 02/24/2015: 10.2.3

Have duplicated the problem pretty easily. It comes down to when we have a one day schedule of a set of update times. Say there are two entries, those updates happen normally. The next thing the system does is attempt to calculate the next update time. In this case it should be the first entry of the schedule plus one day of time.

What is actually happening is the system calculates this next update time to be precisely 12:00 AM, the next day, and does not account for the schedule. After the bogus update happens at midnight, the rest of the schedule appears to operate normally.

I have found the area in the code causing this and am testing an experimental fix. Results of tests and patch to come.

How to duplicate and test:

  1. Perform a manual crl generate from the agent interface because the code to be tested relies heavily upon the "lastUpdate" which will appear in the logs. Do this to have a nice launching off point.

  2. Go to the ca's pkiconsole and select : Certificate Manager -> CRL Issuing Points -> MasterCRL.

  3. Check "updateCRL at: " and give a schedule such as : 15:03, 15:10 .. This gives us a chance to watch the two regularly scheduled updates happen.

  4. When the first event triggers, have a look at the CA's "debug" log and note the following or similar entry:

[CRLIssuingPoint-MasterCRL]: findNextUpdate: Wed May 06 15:10:00 PDT 2015 delay: 86301873

  1. Wait for the 15:00 even to happen. When that triggers at the end of that cycle, we should see one more similar entry.

[CRLIssuingPoint-MasterCRL]: findNextUpdate: Wed May 06 15:03 PDT 2015 delay: 86301873

That is the correct behavior after the fix. We want the next update to be at the first entry of the daily schedule , but tomorrow. The current bug would print out this value as something like:

Wed May 06 00:00:00 or similar to indicate midnight. This is not what we want.

Very simple patch for this:

    // Get V2 or V1 CRL

@@ -1653,7 +1653,7 @@ public class CRLIssuingPoint implements ICRLIssuingPoint, Runnable {
int j = i - mDailyUpdates.elementAt(mCurrentDay).size();
int nDays = 1;
long t = 0;

  • if (mDailyUpdates.size() > 1) {

  • if (mDailyUpdates.size() >= 1) {
    while (nDays <= mDailyUpdates.size()) {
    int nextDay = (mCurrentDay + nDays) % mDailyUpdates.size();
    if (j < mDailyUpdates.elementAt(nextDay).size()) {

The "mDailyUpdates.size()" indicates how many days the schedule accounts for. The basic case, and the one showing the bug is when the schedule takes place strictly during one day. When this occured the calculated next update did not take into account the first member of the schedule tomorrow, and simply spit out "tomorrow" or midnight.

Patch checked in with fix, closing.

Metadata Update from @nkinder:
- Issue assigned to jmagne
- Issue set to the milestone: 10.2.4

7 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/1142

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Login to comment on this ticket.

Metadata