Re: Load balancer and Security Certificates

[Ryan Fox <rfox@findlay.edu>]

Tim Ross wrote:
> Hi All,
>
> We are working through our move to Zimbra here at Cal Poly and have 
> run into a little snag with Security Certs.  Initially we had wanted 
> to use the http proxy that came out with Zimbra 5.0.5, but even in 
> 5.0.6 and 5.0.7 the web proxy still has a few issues that make it 
> unusable for us.  So, we are using a load balancer in front of two 
> mailstore servers in our Test environment.  We have a VIP 
> (example.calpoly.edu) that the load balancer responds to on port 443.  
> We have a security cert for example.calpoly.edu on the load balancer 
> that works fine.  The load balancer then chooses one of the two mail 
> servers (by least connections) and forwards the connection request to 
> the mailstores.  We have tried a couple different setups with the load 
> balancer and mail servers and even purchased two Thawte certs for the 
> two machine names on the mailstores.  The two things we are trying to 
> accomplish are keeping a https (443) connection to the mailstore 
> servers and not receiving cert warnings in the browsers.  We have 
> tried terminating SSL on the load balancer and using 
> zimbraMailMode=redirect on the mail servers, and we've also tried just 
> passing the connection through the load balancer on 443 to the 
> mailstore servers.  Each way we still receive cert warnings if you are 
> directed to the mailstore server that does not contain your mailbox 
> and you are redirected by Zimbra to the other mailstore server.  The 
> cert warning happens because the connection comes in as 
> example.calpoly.edu and the box is expecting the machine name on the 
> cert.  We thought that buying Thawte certs with the box names might 
> resolve this issue, but it did not.
>
> Have any of you dealt with this issue and found the magic combination 
> or setting?  We are considering perhaps a virtual host on the 
> mailstores that would tell the box that it should respond to 
> example.calpoly.edu requests.  Another possibility was putting 
> example.calpoly.edu in the "Subject Alternative Name" field on the CSR 
> we generate for the Thawte cert.

Not that it is the most graceful solution to your problem, but we 
switched to using a single wildcard cert '*.findlay.edu' about a year 
ago, and it has been wonderful.  No reports of clients not accepting it, 
saved a whole bunch of money versus thawte, and it doesn't expire for 3 
years.  The provider we chose was Digicert, who seemed like the only one 
that would license the cert for use on unlimited servers (another one we 
looked at was also a wildcard, but you were supposed to license it per 
server.. good for vhosting I guess). 

The only downside I found is that the cert isn't signed directly by a 
root ca cert included with browsers.  (Keep reading, it turns out OK.)   
But instead, a browser included root ca cert (entrust) signed digicert's 
root ca cert, which signed ours.  So, in configuring web servers and 
such for the cert, you have to include the entire chain.  The browser 
follows the chain up to a root ca cert that it trusts, so all is well.  
It's slightly more difficult, but still not tough.  If you want an 
example, https://www.findlay.edu uses that cert, so you can look at the 
details and check out the chain.

http://www.digicert.com/wildcard-ssl-certificates.htm is their site (no, 
I really not a salesman, I've just been very happy with it). 

Ooh.. just saw Steve Hillman's reply of the same thing.  lol.  OK, 
enough selling. :)

Ryan


begin:vcard
fn:Ryan Fox
n:Fox;Ryan
org:The University of Findlay;Information Technology Services
adr:128 Old Main;;1000 Main St;Findlay;OH;45840;USA
email;internet:rfox@findlay.edu
title:Network Systems Manager
tel;work:419-434-4348
x-mozilla-html:TRUE
version:2.1
end:vcard