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 List openssl-users@openssl.org Automated List Manager majord...@openssl.org
