On Thu, Oct 02, 2008, Alex Chen wrote: > When we use openssl to generate the certificate, we add a certain time, > i.e. thirty years, to the time when the certificate is created. > It is 2008 now and this makes the expiration date 2038. Unfortunately this > triggers the infamous year 2038 problem > http://en.wikipedia.org/wiki/Year_2038_problem > This means new installation will get the expiration date in 1901. > > How does openssl address this problem? Is there a patch so that it does > not set the expiration date beyond the 2038 wrap around time? >
OpenSSL can currently check expiry dates on any certificate date even well outside the time_t range. The problem arises in the certificate creation routines which take the current time (as time_t) add a number of seconds to it to get the expiry date and then convert to ASN1_TIME format (which can represent years form 0000 to 9999). If time_t is signed then adding large values can make it negative and cause the 2038 issue. The best solution IMHO is to add some OS independence to the OpenSSL time handling routines in the places where it is needed. So you can add larger time offsets and get the correct date in certificates. I've got some prototype code which does the basics but not had time to add the necessary additional bits for OpenSSL. 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]
