Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Openssl/certificate issue on i386

    Scheduled Pinned Locked Moved General pfSense Questions
    1 Posts 1 Posters 853 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • ?
      Guest
      last edited by

      Hi,

      not sure where this fits best so I decided to stick it into "General" for now :)

      I'm running 2.1-BETA1 (i386) on a couple of soekris6501 boxes for some time now and am quite happy with it. At the moment I'm using IPSec to connect to my private network while on the road and just started to look into OpenVPN as alternative (seems to be easier to manage and maintain) where I ran into a very strange problem that took some time to fully comprehend.

      The Problem I saw:
      My OpenVPN Client (Tunnelblick on a Mac OS X Laptop) kept complaining about the Server Certificate beeing expired. Since I just created the CA/Server Cert/User Cert literally a minute before the first logon attempt I was initially not trusting the error message until I finally checked the expiry date of the Cert on the commandline of another machine, and indeed it was expired.

      Hunting for the problem it turned out that in a 32-bit environment openssl-0.9.8 has a bug that leads to an overflow of a 32-bit data structure if one tries to create certificates with expiry dates > some day in 2038.

      From the openSSL changelog (http://www.openssl.org/news/changelog.html) under "Changes between 0.9.8n and 1.0.0  [29 Mar 2010]":
      *) New function OPENSSL_gmtime_adj() to add a specific number of days and
          seconds to a tm structure directly, instead of going through OS
          specific date routines. This avoids any issues with OS routines such
          as the year 2038 bug. New *_adj() functions for ASN1 time structures
          and X509_time_adj_ex() to cover the extended range. The existing
          X509_time_adj() is still usable and will no longer have any date issues.
          [Steve Henson]

      Workarounds:

      • create a certificate with expiry before that date (what I choose to do)
      • use amd64 (tricky to do with a soekris6501 and beyond my level of expertise at the moment)

      I thought I'll post that here just in case somebody else is wondering why the heck a freshly created certificate is expiring so quickly ;)

      Cheers
      A.

      1 Reply Last reply Reply Quote 0
      • First post
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.