But not necessarily so so as regards renegotiation.
SSL has a concept of session resuming. The first thing exchanged during an ssl session is the previously negotiated session-id - the startup of these resumed sessions is a lot cheaper than an initial ssl negotiation.
Some of the better load balancers can take advantage of this session-id to ensure a client's ssl session, and subsequent resumed sessions go to the same backend node.
It should be noted that using the same certificate on multiple servers requires that the related private key is on each server too. commercial webservers tend not to be too positive about this, they take the high ground quoting best practice security etc etc, but I can't help feeling its more to do with pushing more business to the CA's than anything else.
just so long as you remember that anyone with the private key can decode all your SSL traffic, so take some care over protecting the key from prying eyes.
Jeff wrote:
if you have two servers behind a load-balancer, you have to make sure that once a client starts an HTTPS conversation with one server, all subsequent requests are served by the same server.True. AFAIK there are no versions of MSIE that correctly support the keepalive setting, to unless you are willing to put up with the mysterious-1-page-in-5-is-just-blank problem you have to turn keepalive off, and every request gets renegotiated.-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Owen Boyle Sent: 10 May 2002 09:02 To: [EMAIL PROTECTED] Subject: Re: Certificates and Apache/modssl Greg Jones wrote:All- We are planning on using commercial load balancing software for twoserversrunning apache with modssl. Does Apache with modssl require that eachserverhave its own certificate or can I use the same certificate on bothserverssince they'll be answering to the same virtual ip? Also, will mycertificatebe based on the virtual ip or the ip of the server. Users will alwaysget tothe web servers via virtual IP.The certificate is assigned to a fully-qualified domain name, not to an IP address. The idea is that when the browser goes to www.acme.com, it expects to see a certificate containing "www.acme.com" - thus proving that the site is really www.acme.com. This is authentication which is the second but equally important aspect of SSL that everyone forgets about... (the first aspect is encryption). Therefore, as long as both your servers are serving the same site, they can have the same certificate (indeed, they *should* have the same cert). There is one other problem, however. Remember that the public-key/private-key encryption is used only to negotiate the session-key. Once that has been established, the client and server communicate using the session-key and the certificate is forgotten. Now, if you have two servers behind a load-balancer, you have to make sure that once a client starts an HTTPS conversation with one server, all subsequent requests are served by the same server. In other words, if the session-key negotiation takes place on one server but the next request comes in to the second server, it will be encrypted with a key known only to the first server. I guess the solution would be to ensure requests are split on a client basis rather than request basis in the load balancer. Rgds, Owen Boyle ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
