Bug 623494

Summary: CRL cert "next update time" seems to be hardcoded for 24hr
Product: [Community] Candlepin Reporter: wes hayutin <whayutin>
Component: candlepinAssignee: Dmitri Dolguikh <dmitri>
Status: CLOSED NOTABUG QA Contact: wes hayutin <whayutin>
Severity: medium Docs Contact:
Priority: medium    
Version: 0.5CC: anadathu, dmitri
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-21 15:29:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description wes hayutin 2010-08-11 22:39:04 UTC
pinsetter.org.fedoraproject.candlepin.pinsetter.tasks.CertificateRevocationListTask.schedule = 0 0/3 * * * ?


Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: /CN=10.16.120.131/C=US/L=Raleigh
        Last Update: Aug 11 22:33:00 2010 GMT
        Next Update: Aug 12 22:33:00 2010 GMT
        CRL extensions:
            X509v3 Authority Key Identifier: 
                keyid:76:5F:97:A5:C4:B8:A5:0F:BA:E8:E1:18:A9:35:71:FD:8F:B0:90:67
                DirName:/CN=10.16.120.131/C=US/L=Raleigh
                serial:80:D4:49:9D:A0:18:29:B4

            X509v3 CRL Number: 
                10


Shouldnt the "Next Update:" reflect the actual setting in candlepin.conf?
Not sure if this is by design, but I wanted to double check and open a bug.

Comment 1 Dmitri Dolguikh 2010-09-21 15:29:29 UTC
From rfc 3280:

5.1.2.5  Next Update

   This field indicates the date by which the next CRL will be issued.
   The next CRL could be issued before the indicated date, but it will
   not be issued any later than the indicated date.  CRL issuers SHOULD
   issue CRLs with a nextUpdate time equal to or later than all previous
   CRLs.  nextUpdate may be encoded as UTCTime or GeneralizedTime.

The above behaviour is not a bug according to RFC.