The C++ compiler in Microsoft's Visual Studio 2005 (and later) makes time_t a 64-bit number when compiling 32-bit code. Older compilers, such as Visual C++ 6.0, make time_t a 32-bit number, which would cause year 2038 issues.
Brant Thomsen -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jim Adams Sent: Thursday, June 05, 2008 3:43 PM To: openssl-users@openssl.org Subject: RE: 2038 date limit What OS did you have this problem on? I use Openssl 0.9.7m on Windows to generate certificates, and I was able to generate certs beyond 2038 with no problem. I did not experience a problem until I tried to generate one that lasted beyond 2106, when the entire 32-bit number overflows. So Windows does not appear to have a signed/unsigned int problem such as you report. Jim Adams -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: Thursday, June 05, 2008 4:33 PM To: openssl-users@openssl.org Subject: Re: 2038 date limit On Thu, Jun 05, 2008, Chris Kottaridis wrote: > When trying to make a certificate for 30 years seems you run into the > 2038 date limitation. Seems the code converts date to a signed int in > seconds since 1970 and now that we are within 30 years of the 2038 limit > we get hit by it. Using a date of (30 * 365) from now: > > notBefore=Mar25 19:33:38 2008 GMT > notAfter=Feb 10 13:05:22 1902 GMT > > Clearly it wrapped around and subtracted 68 years from 1970 instead of > adding 68 years. > > Is there a plan to remove this limitation ? > > I am seeing this on openssl-0.9.7m. > As has been mentioned this is caused by the time representation of the underlying OS. OpenSSL relies on the OS routines to convert the time_t value to appropriate date fields. If the time_t value wraps around you get the above behaviour. Changing this is would involve including independent date routines which don't have this restriction. I did start on this some time ago but other higher priority tasks (e.g. paid ones!) took over. Note however that this doesn't affect OpenSSLs ability to *verify* date fields in the far future. The technique used avoids time_t issues and it should happily handle any date. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
