Year 2038 and CA certificate
Felix Brack (Mailinglist)
My PKI is currently running on a 32 bit machine with Open SSL version
0.9.8 suffering from the Y2038 bug. Another 64 bit machine does not show
that bug.
What I need for now is a CA certificate for signing which should have a
validity that extends beyond 2038, say 2050. I can create such a
certificate on the 64 bit machine, no problem. If I use this certificate
on the 32 bit machine to sign certificates created on the 32 bit
machine, will this work, i.e. will the Y2038 bug not show up as long as
the certificate I am signing expires before the critical date? Or: will
Open SSL on the 32 bit machine deal correctly with the signing
certificate that expires 2050, even though it can't create such a
certificate?
many thanks Felix
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Dr. Stephen Henson
> Hello,
>
> My PKI is currently running on a 32 bit machine with Open SSL
> version 0.9.8 suffering from the Y2038 bug. Another 64 bit machine
> does not show that bug.
>
> What I need for now is a CA certificate for signing which should
> have a validity that extends beyond 2038, say 2050. I can create
> such a certificate on the 64 bit machine, no problem. If I use this
> certificate on the 32 bit machine to sign certificates created on
> the 32 bit machine, will this work, i.e. will the Y2038 bug not show
> up as long as the certificate I am signing expires before the
> critical date? Or: will Open SSL on the 32 bit machine deal
> correctly with the signing certificate that expires 2050, even
> though it can't create such a certificate?
>
Yes all versions of OpenSSL should correctly verify any date in a certificate.
If you use OpenSSL 1.0.0 or later you shoudln't see the 2038 issue on any
platform because OpenSSL uses its own internal date routines to bypass the
limitations of system routines.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
Felix Brack (Mailinglist)
Hello Steve,
Many thanks for the answer; good to know that this will work.
I know that OpenSSL 1.0.0 has this bug fixed for 32 bit systems too. As
I don't wont to 'pollute' the Debian system running Open SSL 0.9.8 I
will not compile the new Version myself. I will therefore have to wait
until - at least until it appears in backports.
Felix
Dr. Stephen Henson
> On 10.10.2011 13:14, Dr. Stephen Henson wrote:
> >
> >If you use OpenSSL 1.0.0 or later you shoudln't see the 2038 issue on any
> >platform because OpenSSL uses its own internal date routines to bypass the
> >limitations of system routines.
> >
>
> I know that OpenSSL 1.0.0 has this bug fixed for 32 bit systems too.
> As I don't wont to 'pollute' the Debian system running Open SSL
> 0.9.8 I will not compile the new Version myself. I will therefore
> have to wait until - at least until it appears in backports.
>
It is unlikely to appear in an official 0.9.8 backport because it is
substantial new code and only bugfixes and security fixes appear in letter
release changes now.
Jakob Bohm
> On Mon, Oct 10, 2011, Felix Brack (Mailinglist) wrote:
>
>> On 10.10.2011 13:14, Dr. Stephen Henson wrote:
>>> If you use OpenSSL 1.0.0 or later you shoudln't see the 2038 issue on any
>>> platform because OpenSSL uses its own internal date routines to bypass the
>>> limitations of system routines.
>>>
>> I know that OpenSSL 1.0.0 has this bug fixed for 32 bit systems too.
>> As I don't wont to 'pollute' the Debian system running Open SSL
>> 0.9.8 I will not compile the new Version myself. I will therefore
>> have to wait until - at least until it appears in backports.
>>
> It is unlikely to appear in an official 0.9.8 backport because it is
> substantial new code and only bugfixes and security fixes appear in letter
> release changes now.
>
which provides
packages compiled from the sources for the next Debian release (such as the
sources for openssl 1.0.0) compiled and packaged for use on the current
stable
release. Packages in "backports" typically have version numbers such as
"1.0.0e-2~bpo60+1", indicating the first attempt to recompile the "1.0.0e-2"
beta package for Debian 6.0.
Depending on perceived need and available volunteers, the Debian backports
repository for Debian squeeze (which officially ships only openssl
0.9.8) may
one day contain a ready to install openssl 1.0.0 or later package that
can be
used on a computer running Debian squeeze.
Such a "backport" 1.0.0 package would be used only by other "backport"
packages and locally compiled software, not by any official updates to
the packages in the stable Debian 6.0 release.