Hodie VII Kal. Aug. MMVI est, Visolve Security Consulting Group scripsit: > Hi Bob, > > > I have been trying to find documentation on the maximum value > > that the "days" argument will accept for an SSL generated certificate. > > The *days* argument in openssl will work fine upto a Maximum value of > *11499* in positive values. > > If the days specified is beyond the value 11499, the parameter "Not After" > date internally goes in negative. Thus on Certificate Verification, the > certificate is considered as *Expired*
Congratulations, you've encountered the "Year 2038" bug in advance :) In fact, the command-line openssl uses a time_t type variable to update the certificate time, and time_t is probably a signed 32bits type on your platform. That means you won't be able to go past "Jan 19, 2038 04:14:07" as a date with your current method. It's not exactly a *bug*, it's already known by the core team developers, as you can find some "FIXME" comments in the date/time manipulation functions. They probably have more useful things to do, but you can help them (and everybody else) on this point: - add necessary functions to get/set/compare/convert/update ASN1_TIME, ASN1_UTCTIME, and ASN1_GENERALIZEDTIME entities, maybe using (struct tm) types whenever possible (that way, you'll have a much larger margin), - modify the command-line tool to make use of these functions, instead of relying on arithmetic with time_t types. -- Erwann ABALEA <[EMAIL PROTECTED]> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
