Puppet, OpenSSL and the Year 2038

It would appear that 32 bit versions of OpenSSL (tested up 0.9.8g) suffer from the Year 2038 bug (http://en.wikipedia.org/wiki/Year_2038_problem).

To recap, this is where the internal representation of time (time_t), a 32 bit signed integer that is the number of seconds since the epoch (00:00:00 UTC on January 1, 1970). This means the maximum time you can represent on a 32 bit system is 03:14:07 19/01/2038. OpenSSL apparently uses time_t internally rather than something more functional.

That upper limit does not apply to 64 bit OpenSSL where time_t is 64 bits. We have a somewhat larger margin.

The upshot of this is that you should not be asking Puppet to work with certificates that pass beyond that date in 2038 if you use any 32 bit systems (with the current OpenSSL libraries).

In practice this means the ca_ttl parameter cannot be larger than (03:14:07 19/01/2038 – now). At the time of writing, 30y will cause a failure.

A fix for OpenSSL to use another internal representation of time/date than 32 bit time_t would fix this problem without having to go to 64 bit.

To reproduce this with Puppet:

puppetca --ca_ttl=30y --ssldir=/var/tmp/catest --generate hopeless.nohoper.com

And directly with OpenSSL (accept all the defaults):

openssl req -new -x509 -keyout key1.pem -out cert1.pem -days 10000
openssl req -new -x509 -keyout key2.pem -out cert2.pem -days 12000
openssl x509 -noout -text -in cert1.pem
openssl x509 -noout -text -in cert2.pem

Key1 is the control (which works), and Key2 is the one which will give an error. What should expire in the year 2040 actually expires in the year 1904.

Puppet is at the mercy of the third-party libraries here.