On Mon, Jan 14, 2002 at 09:26:22AM -0800, Eric Rescorla wrote:
> SSL does not require that the client and server have synchronized
> clocks, except in the loose sense that a certificate verifier's
> clock should have some relation to the real time in order to avoid
> falsely evaluating expiry.
>
> Exactly what behavior are you seeing that leads you to believe
> that this is a problem?
>
hrm, roughly, this is the segment I'm looking at:
there exists a client. the client has a clientKey, a
clientCert, and serverCert. The server has
signed the client's keys.
there exists a server, which has a serverKey, and a serverCert.
The server's keys have been signed by the overserver.
If the clocks are within say 30 minutes of each other the SSL handshake
will go through without a hitch and communications will flow smoothly.
However, if the clock is set quite a few hours away the SSL handshake
will not go through and the server will spit out an error in the theme
of "Function:SSL3_READ_BYTES Reason:sslv3 alert bad certificate SSL
alert number 42".
I wated quite a few hours on what I thought was an implementation
bug before a google search turned up some ssl guru on some mailing
list who was able to fix the problems of many list readers with a
mad cackle and a command to sync their clocks.
I don't think that this is the page, but it conveys the point:
http://www.google.com/search?q=cache:ANzi8NZ6htUC:www-unix.globus.org/mail_archive/discuss/msg00109.html+Reason:sslv3+alert+bad+certificate+SSL+alert+%0Anumber+42%0A%0A&hl=en
so I sync'd clocks and voila, it's all good. No explanation from our
books on SSL, the manpages, or from the code. We figure it's gotta be
something in the deep down that's requiring some sort of time sync,
perhaps some legacy anti-replay or something. The problem exists on
both unix and windows clients.
--adam
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
