jida...@jidanni.org writes:

> Andrew, I found I needed to use
> SSLOptions
> {
>  expiration-time = 20y
> }
> as 100y started causing big nightmares a few weeks after installation.
> I am guessing that perhaps values beyond the brink of Unix Time in 2038
> aren't dealt with, causing false expiration detection and system
> lockouts looping etc. at some truncated value of some time value.

If you are on a 64-bit system the time_t value will be 64 bits and
there shouldn't be the 2038 problem (provided that all system
libraries and x509 certificates can handle 64-bit time).  On a 32-bit
system the problem does exist with extremely long expiration times
like you say.

This patch should fix the problem by setting the expiration time to
the upper limit on 32-bit systems.  There will be a side-effect though
of causing all your certificates created on 32-bit machines to expire
at the same time in 2038.

-------------------- certificates.c patch --------------------
--- certificates.c      2009/03/13 19:28:37     1.34
+++ certificates.c      2010/03/28 08:51:02
@@ -937,10 +937,13 @@
 {
  gnutls_x509_crt_t crt;
  unsigned char buffer[4*RSA_BITS]; /* works for 256 bit keys or longer. */
+ time_t expiration,now;
  size_t buffer_size=sizeof(buffer);
  int fd,err;
  const char *errmsg_hostname;
 
+ now=time(NULL);
+
  if(fake_hostname)
     errmsg_hostname=fake_hostname;
  else if(server_hostname)
@@ -1012,7 +1015,7 @@
 
  /* Set the key serial number (unique) */
 
- sprintf((char*)buffer,"%08lx%08lx",(unsigned long)time(NULL),(unsigned 
long)getpid());
+ sprintf((char*)buffer,"%08lx%08lx",(unsigned long)(now&0xFFFFFFFF),(unsigned 
long)getpid());
 
  err=gnutls_x509_crt_set_serial(crt,buffer,strlen((char*)buffer));
  if(err<0)
@@ -1026,11 +1029,16 @@
 
  /* Set the activation and expiration times */
 
- err=gnutls_x509_crt_set_activation_time(crt,time(NULL));
+ err=gnutls_x509_crt_set_activation_time(crt,now);
  if(err<0)
    {PrintMessage(Warning,"Could not set the certificate activation time for 
'%s' [%s].",errmsg_hostname,gnutls_strerror(err));return(11);}
 
- 
err=gnutls_x509_crt_set_expiration_time(crt,time(NULL)+ConfigInteger(SSLCertExpiry)*24*3600);
+ if(sizeof(time_t)==4 && 
ConfigInteger(SSLCertExpiry)>((0x7FFFFFFF-now)/(24*3600)))
+    expiration=0x7FFFFFFF;
+ else
+    expiration=now+ConfigInteger(SSLCertExpiry)*24*3600;
+
+ err=gnutls_x509_crt_set_expiration_time(crt,expiration);
  if(err<0)
    {PrintMessage(Warning,"Could not set the certificate expiration time for 
'%s' [%s].",errmsg_hostname,gnutls_strerror(err));return(12);}
 
-------------------- certificates.c patch --------------------

When testing this patch I noticed that gnutls won't allow an
expiration time of 0x7FFFFFFF but instead limits it to 0x7FE80EEB.

Using the WWWOFFLE certificate page for the newly created fake
certificate I see this:

        Validity:
                Not Before: Sun Mar 28 09:19:16 UTC 2010
                Not After: Thu Dec 31 23:23:23 UTC 2037

Instead of the expected: Tue Jan 19 03:14:07 UTC 2038.

I tracked this down to code within gnutls that limits the time:

-------------------- gnutls common.c --------------------
  /* In order to work with 32 bit
   * time_t.
   */
  if (sizeof (time_t) <= 4 && etime.tm_year >= 2038)
    return (time_t) 2145914603; /* 2037-12-31 23:23:23 */

-------------------- gnutls common.c --------------------

-- 
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop                             a...@gedanken.demon.co.uk
                                      http://www.gedanken.demon.co.uk/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to