That is great news, Dr. Hensen.
In our test with openssl 0.9.7e, the behavior of certificate expiration
date calculation does not seem to be consistent across different OS.
For instance, when we use openssl to generate pem files on Windows and
MacOS X with system time set beyond 2012, we get di
To those interested in the year 2038 issues
I've just added some experimental code to HEAD (which will be OpenSSL 0.9.9).
This should make sensible things happen when longer expiry dates are used
during certificate creation.
Let me know of any issues.
At some point this could be backported.
Seriously, if we use openssl version 0.9.7 to generate a certificate
on MacOS and set the end day to from now, i.e. set 'default_days'
to but do not have 'default_enddate' in the config,
we get
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Befo
On Mon, Oct 06, 2008 at 10:19:08AM -0500, Michael S. Zick wrote:
> On Mon October 6 2008, Thomas J. Hruska wrote:
> > Philipp Gühring wrote:
> > > Hi,
> > >
> > > The biggest Problem with the Y2038 problem I see is that most people
> > > believe that it will go away due to the migration to 64 Bit
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 infamo
On Monday 06 October 2008 11:19:08 Michael S. Zick wrote:
> A more likely possibility -
> All of the crypto-locks on the physical facilities will not work,
> nor any of the access cards - nobody will be able to get in.
> Meaning the world will be effectively, totally disarmed.
Or even better: "eff
On Mon October 6 2008, Thomas J. Hruska wrote:
> Philipp Gühring wrote:
> > Hi,
> >
> > The biggest Problem with the Y2038 problem I see is that most people
> > believe that it will go away due to the migration to 64 Bit machines.
> > But this isn't going to happen. We have to start fixing 2038 no
Philipp Gühring wrote:
Hi,
The biggest Problem with the Y2038 problem I see is that most people
believe that it will go away due to the migration to 64 Bit machines.
But this isn't going to happen. We have to start fixing 2038 now, also
for all our 32 Bit platforms, 16 Bit platforms and 8 Bit pl
Hi,
> 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?
We just experienced exactly the same problem, and would be happy if it
got solved by OpenSSL.
There is a workaround available for this specific problem:
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
10 matches
Mail list logo
