Re: How to handle Expired or not yet valid X.509 certificates - or simply is the system date wrong?
JoelKatz wrote: If a system does not have a reliable source of time, then it cannot reliably perform security operations other than verifying timestamped signatures. That should have been addressed when the system was designed. I have a similar, but propably foolish question: I'm running an OpenSSL server on an embedded system which, by design, has no reliable source of time. In fact, its internal system time (Unix time) is starting all over from 0 after a system boot. Now, the obvious solution to prevent client certificates from being rejected as not yet valid or expired is to set their related date properties accordingly when creating them. However, these certificates are also used for other purposes which still require them to possess correct validity date properties. In essence, my question now is: Is it possible to set up the server in a way, that client certificates are validated without regarding their validity dates? I'm aware of the fact that this is actually a security compromise, but from where I see it, there seems to be no other way for me. -- View this message in context: http://old.nabble.com/How-to-handle-%22Expired%22-or-%22not-yet-valid%22-X.509-certificates---or-simply-is-the-system-date-wrong--tp31211619p31539008.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How to handle Expired or not yet valid X.509 certificates - or simply is the system date wrong?
Hi, I though this was already discussed, but I cannot find pointers. When some entity verifies a certificate, finds a valid signature etc but the current date is not between Valid From to Valid To, meaning the certificate seems not yet valid or expired, what is recommended to do? I think, essentially, this should be application specific, but are there guide lines or common sense? In practice there could be issues with wrong sytem date / system clocks / time stamps, which could lead to bad situations, especially when users are not allowed to change the system date (for security reasons) and then failing to remotely administrate (because the peer rejects the actually valid certificate as expired or not yet valid). It cannot be assumed all entities are connected to the internet or any other external trusted time (except maybe an SSL protected one). Are there standards, recommendatations or any writings discussing such topics, in particular system date related topics? oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to handle Expired or not yet valid X.509 certificates - or simply is the system date wrong?
On 3/22/2011 9:07 AM, Steffen DETTMER wrote: When some entity verifies a certificate, finds a valid signature etc but the current date is not between Valid From to Valid To, meaning the certificate seems not yet valid or expired, what is recommended to do? It depends what you're doing. I think, essentially, this should be application specific, but are there guide lines or common sense? The basic idea is this: If the thing you're checking is from a past date, you can verify that date, and the certificate was valid on that date, then continue. If the operation is based on the current date, reject. In practice there could be issues with wrong sytem date / system clocks / time stamps, which could lead to bad situations, especially when users are not allowed to change the system date (for security reasons) and then failing to remotely administrate (because the peer rejects the actually valid certificate as expired or not yet valid). It cannot be assumed all entities are connected to the internet or any other external trusted time (except maybe an SSL protected one). If a system does not have a reliable source of time, then it cannot reliably perform security operations other than verifying timestamped signatures. That should have been addressed when the system was designed. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
