Re: Year 2038 problem
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 different expiration dates if we specify the 'default_days' to but do not specify 'default_enddate' in the config file. The Windows certificate contains proper expiration date while the MacOS certificate wraps the certicate expiration date back to 1900. Hopefully your fix will make the behavior consistent as well. Alex Dr. Stephen Henson wrote: 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. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Year 2038 problem
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. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Year 2038 problem
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: openssl ca -in CSR.csr -batch -enddate 400102030405Z 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 platforms. Best regards, Philipp Gühring __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Year 2038 problem
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 platforms. Best regards, Philipp Gühring Oh...you mean like these problems (disclaimer: Found on the Internet and taken out of context): the magical year 2038 should ring some bells. You know - when all 32-bit clocks roll around to 0. Computers that work tend to not get replaced. Some line of code might be, 'if (lasttime time()) LaunchNuclearMissile();' thrown in perhaps as a dummy line that some engineer thought would be funny. It seems the (linux) world will enter a time tunnel in the year 2038 and spit us back to 1901. http://www.2038bug.com/index.html ... So, while 2038 is a fair way off, the main jist of the 2038bug.com site is for programmers to take this into account especially when programming for ... *nix powered nuclear bomb timers / anything that runs on long term chips for domestic use or whatever. It's also been widely reported that the bug might cause nuclear missiles to launch themselves. Accidentally launching a nuclear missile isn't exactly as easy as setting off your smoke detector The Trident fleet is 14 boats with 12 deployable and armed with the only new missile now being purchased, the Lockheed Trident D5. ... Trident is being service-life extended until 2038 when it will be replace with a new design. A very interesting discussion. Does anyone have some information on future US deployments and a possible replacement of the MM-III? I heard something about a replacement planned for 2038. Just some stuff to think about as we code our way to 2038. Launch that nuclear missile! -- Thomas Hruska __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Year 2038 problem
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 now, also for all our 32 Bit platforms, 16 Bit platforms and 8 Bit platforms. Best regards, Philipp Gühring Oh...you mean like these problems (disclaimer: Found on the Internet and taken out of context): Having spent a few years in testing development fuze and guidance systems... Don't worry about that one. If you are seriously concerned, move at least 150 miles away from any of the A-List cities. ;) (50 mile error allowance, 50 mile 100% kill zone, plus room to hide.) 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. Mike the magical year 2038 should ring some bells. You know - when all 32-bit clocks roll around to 0. Computers that work tend to not get replaced. Some line of code might be, 'if (lasttime time()) LaunchNuclearMissile();' thrown in perhaps as a dummy line that some engineer thought would be funny. It seems the (linux) world will enter a time tunnel in the year 2038 and spit us back to 1901. http://www.2038bug.com/index.html ... So, while 2038 is a fair way off, the main jist of the 2038bug.com site is for programmers to take this into account especially when programming for ... *nix powered nuclear bomb timers / anything that runs on long term chips for domestic use or whatever. It's also been widely reported that the bug might cause nuclear missiles to launch themselves. Accidentally launching a nuclear missile isn't exactly as easy as setting off your smoke detector The Trident fleet is 14 boats with 12 deployable and armed with the only new missile now being purchased, the Lockheed Trident D5. ... Trident is being service-life extended until 2038 when it will be replace with a new design. A very interesting discussion. Does anyone have some information on future US deployments and a possible replacement of the MM-III? I heard something about a replacement planned for 2038. Just some stuff to think about as we code our way to 2038. Launch that nuclear missile! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Year 2038 problem
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: effectively disarmed, totally. If only it was an intentional DoS. I for one would gladly take the credit for such a bug. Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Year 2038 problem
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 infamous year 2038 problem http://en.wikipedia.org/wiki/Year_2038_problem This means new installation will get the expiration date in 1901. 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? OpenSSL can currently check expiry dates on any certificate date even well outside the time_t range. The problem arises in the certificate creation routines which take the current time (as time_t) add a number of seconds to it to get the expiry date and then convert to ASN1_TIME format (which can represent years form to ). If time_t is signed then adding large values can make it negative and cause the 2038 issue. The best solution IMHO is to add some OS independence to the OpenSSL time handling routines in the places where it is needed. So you can add larger time offsets and get the correct date in certificates. I've got some prototype code which does the basics but not had time to add the necessary additional bits for OpenSSL. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Year 2038 problem
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 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 platforms. Best regards, Philipp Gühring Well, that and the problem that it is so hard to get anyone to think about time formats w.r.t. any time other than right now. Already the idea 31 years from now is inexpressible. Oh...you mean like these problems (disclaimer: Found on the Internet and taken out of context): Having spent a few years in testing development fuze and guidance systems... Don't worry about that one. If you are seriously concerned, move at least 150 miles away from any of the A-List cities. ;) (50 mile error allowance, 50 mile 100% kill zone, plus room to hide.) 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. So long as *none* of the parties fix their clocks first. We must not have a clock-width gap! :-) -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is intuitive he means the exact opposite. pgpVIwE2R3Rwk.pgp Description: PGP signature
Re: Year 2038 problem
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 Before: Oct 6 20:41:18 2008 GMT Not After : Jan 15 14:13:02 1900 GMT Switch to version 0.9.7e works better, but it still fails if we set the system clock in 2010. It means for applications that only want to have the maximum validity by specifying days when they generate 'self-signed' certificate, the certificate will either fail now, or in a couple of years. This is not a problem we can casually brush off assuming it is not going to happen before we are all retired. Alex On Oct 6, 2008, at 9:43 AM, Mark H. Wood wrote: 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 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 platforms. Best regards, Philipp Gühring Well, that and the problem that it is so hard to get anyone to think about time formats w.r.t. any time other than right now. Already the idea 31 years from now is inexpressible. Oh...you mean like these problems (disclaimer: Found on the Internet and taken out of context): Having spent a few years in testing development fuze and guidance systems... Don't worry about that one. If you are seriously concerned, move at least 150 miles away from any of the A-List cities. ;) (50 mile error allowance, 50 mile 100% kill zone, plus room to hide.) 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. So long as *none* of the parties fix their clocks first. We must not have a clock-width gap! :-) -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is intuitive he means the exact opposite. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Year 2038 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/Year_2038_problem This means new installation will get the expiration date in 1901. 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? Alex __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
