The 2038 Problem
|Broken Time? - Roeland van der Hoorn|
Lots of application functions and system libraries keep track of the time using a 32-bit signed integer, which has a maximum value of around 2.1 billion. It's good for a bit more than 68 years worth of seconds.
Things are likely to get weird 2.1 billion seconds after the epoch on January 19th, 2038.
As the binary counter rolls over from 01111111111111111111111111111111 to 10000000000000000000000000000000, the sign bit gets flipped. The counter will have changed from its farthest reach after the epoch to its farthest reach before the epoch. time will appear to have jumped from early 2038 to late 1901.
Things might even get weird within the next year (January 2018!) as systems begin encounter freshly minted CA certificates with expirations after the epoch rollover (it's common for CA certificates to last for 20 years.) These certificates may appear to have expired in late 1901, over a century prior to their creation.
NTP's 2036 ProblemNTP has a similar, but not-quite-the-same epoch problem. It keeps track of seconds in an unsigned 32-bit value, so it can count twice as high as the problematic UNIX counter (yay!) but NTP's epoch is set 70 years earlier: 1 January 1900 (boo!) The result is that NTP's counter will roll over about 2 years before the UNIX counter.
Practically speaking, NTP's going to be fine for reasons having to do with it being primarily concerned about small offsets in relative time, and it only having to be within 68 years of correct on startup in order to sync up with an authoritative time source.
So What's Up With This Router?
Here's a weird thing I stumbled across recently. Time calculations with dates in 2036 are going wrong but they're unrelated to NTP:
router#show crypto pki certificates test-1 CA Certificate Status: Available Certificate Serial Number (hex): 14 Certificate Usage: Signature Issuer: cn=test-2 Subject: cn=test-2 Validity Date: start date: 02:38:26 UTC Mar 17 2017 end date: 00:00:00 UTC Jan 1 1900 Associated Trustpoints: test-1
But this one looks okay:
router#show crypto pki certificates test-2 CA Certificate Status: Available Certificate Serial Number (hex): 12 Certificate Usage: Signature Issuer: cn=test-1 Subject: cn=test-1 Validity Date: start date: 02:37:31 UTC Mar 17 2017 end date: 06:28:15 UTC Feb 7 2036 Associated Trustpoints: test-2
The real expiration dates of these certificates is just one second apart:
$ openssl x509 -in test-1.crt -noout -enddatenotAfter=Feb 7 06:28:16 2036 GMT
$ openssl x509 -in test-2.crt -noout -enddatenotAfter=Feb 7 06:28:15 2036 GMT
Here's the actual certificate data and import procedure used for this experiment in case you feel inclined to test:
crypto pki trustpoint test-1 enrollment terminal crypto pki authenticate test-1 -----BEGIN CERTIFICATE----- MIIBeDCCASKgAwIBAgIBFDANBgkqhkiG9w0BAQUFADARMQ8wDQYDVQQDDAZ0ZXN0 LTIwIBcNMTcwMzE3MDIzODI2WhgPMjAzNjAyMDcwNjI4MTZaMBExDzANBgNVBAMM BnRlc3QtMjBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDUjEccGNjjtv8lKNnvGpta Z4x8LB82D2JJwTcvA5blUI2nr4vF41RqG0ifZ+Qtyqo+ntSD2QzDu3LKdSUw46if AgMBAAGjYzBhMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBQ2NpEF0FG/g3ryNgU7Skjbm4IGHTAfBgNVHSMEGDAWgBQ2NpEF0FG/g3ry NgU7Skjbm4IGHTANBgkqhkiG9w0BAQUFAANBAIVyT+iBimH7c/jtBrFGmKq+7YdM eMwf9I/En/TAUqtte7QGLNRyTgBJvGgN/uc0KUjlZ5D6G/kxTwDtzse2Uow= -----END CERTIFICATE----- quit crypto pki trustpoint test-2 enrollment terminal crypto pki authenticate test-2 -----BEGIN CERTIFICATE----- MIIBeDCCASKgAwIBAgIBEjANBgkqhkiG9w0BAQUFADARMQ8wDQYDVQQDDAZ0ZXN0 LTEwIBcNMTcwMzE3MDIzNzMxWhgPMjAzNjAyMDcwNjI4MTVaMBExDzANBgNVBAMM BnRlc3QtMTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDUjEccGNjjtv8lKNnvGpta Z4x8LB82D2JJwTcvA5blUI2nr4vF41RqG0ifZ+Qtyqo+ntSD2QzDu3LKdSUw46if AgMBAAGjYzBhMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBQ2NpEF0FG/g3ryNgU7Skjbm4IGHTAfBgNVHSMEGDAWgBQ2NpEF0FG/g3ry NgU7Skjbm4IGHTANBgkqhkiG9w0BAQUFAANBAIjboo8wtehMpOReLw01tW8MLYzl rtpwYVGoHCVVpXU+s7YQtfR1pt5ZVHZ8OVeP8SoTtoS+5k97aWgBZ+hu8/M= -----END CERTIFICATE----- quit