Package: gnutls-bin
Version: 3.5.8-5+deb9u3
Severity: important
Hi,
Seems certtool (at least the version shipped with Debian Stretch) has a
year 2038 problem on 32-bit architectures.
We have a program that generates SSL certificates with 20 year validity
for communication within an internal network, and it started failing today.
To reproduce (on i386 arch):
Designs
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
gnutls' API relies on the libc provided time_t type and as such it inherits its limitations on 32-bit systems. There are some attempts to tackle that issue in glibc at:
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
While gnutls could work-around the issue and provide a 2038 safe time_t replacement, I'm not sure whether that would make much difference on a system which is not 2038k safe.
My recommendation would be to use 64-bit systems, or 32-bit systems with a libc which provides a 64-bit time_t, to generate certificates valid for longer than 2038, or utilize the never-expire time which is (time_t)(-1) if applicable.
While gnutls could work-around the issue and provide a 2038 safe time_t replacement, I'm not sure whether
that would make much difference on a system which is not 2038k safe.
I do really think that gnutls should be 2038 safe regardless of what glibc the user has.
Most other applications will not experience the 2038 problem until it is actually 2038.
But you do need to able to deal with long lived certificates long before that.
And while this bug report is about the inability to create certificates myself past 2038, how does gnutls deal with certificates used by others with expiration dates past 2038?
Note that there are already root CA certificates in the wild with dates like that:
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
As far as never-expiring certificates go, is that an option universally supported by SSL implementations?
And while this bug report is about the inability to create certificates myself past 2038, how does gnutls deal with certificates used by others with expiration dates past 2038?
Note that there are already root CA certificates in the wild with dates like that:
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
All dates are capped to the 2038 in systems with 32-bit time_t. Thus these certificates will continue to work until then.
As far as never-expiring certificates go, is that an option universally supported by SSL implementations?
It should be. It is a date far in the future (year 9999)
One way to "solve" this issue is to document certtool (and underlying API) behavior and the solution, which is to use an environment with 64 bit time_t values for explicitly setting a date beyond 03:14:07 UTC on 19 January 2038.