https://issues.apache.org/bugzilla/show_bug.cgi?id=47808
--- Comment #11 from Eric Covener <[email protected]> 2009-09-09 15:18:38 PDT --- (In reply to comment #10) > (In reply to comment #9) > > > But your debug outputs show that the nextUpdate field of your CRL is empty > > > which is IMHO bad. So I guess your CRL needs fixing as well. > > > > This is permitted by RFC3280 and openssl can generate the CRL without this > > field. > > > > TBSCertList ::= SEQUENCE { > > version Version OPTIONAL, > > -- if present, MUST be v2 > > signature AlgorithmIdentifier, > > issuer Name, > > thisUpdate Time, > > nextUpdate Time OPTIONAL, > > revokedCertificates SEQUENCE OF SEQUENCE { > > Thanks for the info, but how should mod_ssl behave in this case? My patch > would > cause it to error out. Should we treat the CRL as expired or valid or what? Whoops, it's more complicated, section 5.0: Conforming CAs are not required to issue CRLs if other revocation or certificate status mechanisms are provided. When CRLs are issued, the CRLs MUST be version 2 CRLs, include the date by which the next CRL will be issued in the nextUpdate field (section 5.1.2.5), include the CRL number extension (section 5.2.3), and include the authority key identifier extension (section 5.2.1). later: This profile requires inclusion of nextUpdate in all CRLs issued by conforming CRL issuers ... The behavior of clients processing CRLs which omit nextUpdate is not specified by this profile. Iff there's no "version" extension in the CRL I suspect we should treat nextUpdate == NULL as valid, but version >1 and nextUpdate == NULL looks like it should be configurable -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
