It's a Linux 2.6.21 based system.
I think the issue comes into play here in x509.c:
x509_gmtime_adj(X509_get_notAfter(x),(long),60*60*24*days);
where days is an int and X509_gmtime_adj has it's second parameter
defined as a long.
and I believe int's and longs are 32 bits on this machine.
Thanks
Chris Kottaridis ([EMAIL PROTECTED])
================================================
On Thu, 2008-06-05 at 17:42 -0400, Jim Adams wrote:
> 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]
