CRL scheduler adds extra CRL generation at midnight for daily schedules

[pki-bot]

This issue was migrated from Pagure Issue #572. Originally filed by nkinder (@nkinder) on 2013-03-26 04:49:04:

• Closed as Fixed
• Assigned to jmagne (@jmagne)
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=919570

---

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.

[pki-bot]

Comment from awnuk (@awnuk) at 2013-10-01 21:35:46

Related to
[[br]]
https://bugzilla.redhat.com/show_bug.cgi?id=919556
[[br]]
https://bugzilla.redhat.com/show_bug.cgi?id=919570

[pki-bot]

Comment from mharmsen (@mharmsen) at 2014-09-26 00:59:48

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

[pki-bot]

Comment from mharmsen (@mharmsen) at 2015-01-15 00:56:51

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

[pki-bot]

Comment from mharmsen (@mharmsen) at 2015-02-24 23:32:36

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

[pki-bot]

Comment from jmagne (@jmagne) at 2015-05-05 22:51:26

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.

[pki-bot]

Comment from jmagne (@jmagne) at 2015-05-05 23:19:37

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

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

[pki-bot]

Comment from jmagne (@jmagne) at 2015-05-07 02:08:50

Patch checked in with fix, closing.

[pki-bot]

Comment from nkinder (@nkinder) at 2017-02-27 14:08:05

Metadata Update from @nkinder:

• Issue assigned to jmagne
• Issue set to the milestone: 10.2.4