[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cobalt-users] Solution for SSL bug
- Subject: [cobalt-users] Solution for SSL bug
- From: "Robert Davis" <rdavis@xxxxxxxxxxx>
- Date: Wed May 30 18:36:40 2001
- List-id: Mailing list for users to share thoughts on Cobalt products. <cobalt-users.list.cobalt.com>
Ahoy
> Problems on RAQ 4
> When Using https ( Thawte Certificate)
> 90% of time OK - 10% gives 404 page not found errors (irrespective of
> Browser type)
> Nearly always works OK second time round after browser refresh.
>
> Sure I saw something about this being to do with a 'Keep Alive' setting
> - but can`t remember where I saw it.
>
Had this problem before. Solved it. Forgot how. Got it again on a different
cert.
Applied to Thawte for the answer. I received these instructions from Thawte
today:
___________________________
Please try this in your SSL virtual host section,
--
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
--
This information, and plenty more from the openssl-users list,
http://www.mail-archive.com/openssl-users@xxxxxxxxxxx/
____________________________
The problem stems from a bug in schannel.dll. When the server is NT IIS and
the browser is not MS or when the browser is MS and the server is not then
schannel.dll will sometimes choose the wrong key upon reconnect. See
http://support.microsoft.com/support/kb/articles/Q249/8/63.asp .
It is not an IE bug, though frequently mis-identified as such. It is a
Windows DLL
bug. Therefore, it would also occur when Netscape encounters a cert on an NT
IIS
server. The key is: if the server is MS and the browser is not, or if the
browser is MS
and the server is not, then the problem happens intermittently. But, as
relatively few
servers are NT and so few browsers are Netscape, it will almost always be
found
when using IE 5 or 5.5. Win9x, NT4, and Win2K are affected. WinME is not.
I find from old httpd.conf files that I previously solved this same deal by
simply
putting
KeepAlive Off
in the virtual host section. I devised that fix because the error can be
persuaded
to occur 90% of the time if you simply park at the secure page for 30
seconds (as one
might do when filling out a credit card form) before proceeding to the next
link. And
that fix works also.
Aloha
Davis