Peter M. Jansson wrote: > Make sure you enable session caching, and disable all the low-capability > ciphers.
Peter, I tried using your configuration and am still seeing the same problem. See below for more details... Rob Mayoff wrote: > If no packets are reaching the server machine, then the problem has > nothing to do with AOLserver or nsopenssl. Let me start by giving more details about the problem I'm seeing, now that I've had some time to experiment further... I wanted to setup nsopenssl, and use some certificates that I was using before on nsssl (let me call these the "original certificates"). I read a post by Scott Goodwin in this list explaining that the certificate format is the same, and that at most the nsssl key file would need to be unencrypted to work with nsopenssl (my original key files were already unencrypted). The original certificates were issued for, say, domain abc.com. This abc.com server will now be migrated to a different hardware configuration, in which I will use nsopenssl/nsssle. I'm using the original certificates, for internal testing purposes only, in a development machine with a different domain name, eg, xyz.com. So, there is the issue of name mismatch between the certificates and the domain name of the requests. However, as far as I know, this should at most cause a "security warning" to be displayed by the browsers when first accepting the certificate (all browsers except IE 5.x/6.x on Win95/98 do display such a warning). I have tried several combinations of nsopenssl/nsssl and certificates, with varying results, which I summarize below: * nsssl with the original certificates: works fine on all browsers/platforms. Just for reference, these certificates also work fine in a BigIP F5 doing hardware encryption. * nsopenssl (versions 1.1 and 2.0) with the original certificates: works fine on all browsers except for IE 5.x/6.x on Windows 95, 98 and ME (which give the "The page cannot be displayed... Cannot find server or DNS Error" error). IE 5.x/6.x works fine on Windows 2000 and NT. Because of access restrictions to the machines involved, I could not install tcpdump, so I could not confirm that IE doesn't even try to access the server. However, I'm pretty sure it doesn't, because the error is immediately displayed, with no responde time involved; also, I get the exact same behavior when I simply disconnect the network cable from the browser PC before I attempt to connect to an https page, indicating that no network activity is attempted. One more interesting detail about this configuration: if I edit the hosts file in windows 95/98 and map abc.com (the domain for which the certificates were issued) to the IP of the development machine, when I access the development machine using the "fake" domain name (so that the domain in the certificate matches the domain in the http request), it suddenly works fine even with IE 5.x/6.x. * nsopenssl (versions 1.1 and 2.0) with test certificates generated by me using openssl utilities: works fine on all browsers/platforms. Given this, it's now clear to me that the problem lies in a combination of using nsopenssl with the original certificates (with mismatched domain names), but I still can't understand why it would work on some browsers and not others... it's very probably some kind of bug in the Win95/98 certificate-handling code, but since that platform constitutes the majority of the service's userbase, I can't really afford to have it not working for them. For now, I've resorted to a different solution (using nsssle with 40-bit certificates), but I still need to figure out what was wrong with the original setup, and get it to work... Any ideas, given this new information? Thanks, Nuno
