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.
Related to [[br]] https://bugzilla.redhat.com/show_bug.cgi?id=919556 [[br]] https://bugzilla.redhat.com/show_bug.cgi?id=919570
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:
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.
Go to the ca's pkiconsole and select : Certificate Manager -> CRL Issuing Points -> MasterCRL.
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.
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
[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
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.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.