[SOLVED] Zimbra Proxy - 2 questions

[rlomba]

Hi Gurus,

I've put up a multi-nodes installation (LDAP, MTA, Mbox, and Proxy) for Proof of Concept. I'm now testing. But there are a couple of things that are not clear to me... Can anyboby pls shed some light on the following?

1) Is it possible to configure the Proxy Server so that it redirects connections to the Administrative Console, running on the Mailbox Server and reachable at port 7071 https?

Right now it works well for the "end user" login screen... But I'd like not to expose the backend Mbox server to the outside world directly, when it comes to using the Administrative Interface.

Workarounds welcome

2) I'd also like to buy a commercial SSL certificate for the secure communications. Where do I have to generate the Certificates Request, given that I'm in a proxyied environment?

On the Proxy Server? Or maybe on the Mailbox Server?

And where do I deploy the certificate that the CA will deliver to me?

Thank you very much for any help and/or insight.

[rlomba]

Hello again,

can anybody help with my questions please?

Even a "no you can't do it" would be ok, if the Admin Console can't be proxyed...

Regarding question 2 I'm still puzzled, it would be great to hear from somebody doing ssl via Proxy (ActiveSync dislikes self signed certificates on many devices... Therefore putting up the right certificate obtained with the correct Certificate Request from the right machine is very important, probably)

Thanks...

[rlomba]

Ok, both the issues have been resolved...

1) Proxying Administrative Console

In the end, I put up 2 public IP Addresses. The first one is responding to ports:

80 http
443 https
143 imap
993 imaps
110 pop
995 pops
7071 https

The firewall routes all the ports EXCEPT 7071 to the Proxy Server. Port 7071, despite answering on the same Public IP, is routed to a different internal machine (the Mailbox Server).

Doing so, using the same FQDN in my browser, I can reach both the end users login screen (transparently going through the Proxy) AND the Administrative Console login screen (bypassing the proxy).

The SSL Certificate that I bought have been deployed both on the Proxy Server AND on the Mailbox Server, therefore is resulting valid when I connect in https, both to the End User login screen and the Admin Login screen.

The only con is that the Mailbox Server is directly exposed, ok, just on one single SSL port and with a different name, but still it's not the top. Anyway, it's working.

The second Public IP that I put up is for the MTA/SMTP Server: not proxyed (but it has to be like that), answering on ports:

25 SMTP
465 SMTPs

All good, all working.

2) Certificates

I bought an UCC Certificate from GoDaddy (I noticed they are quite popular amongst the Forum's users). It works very well. What I did is:

- I generated a Certificate Request from the Admin Console, specifying it would be for ALL the Servers (LDAP, MTA, Mbox, Proxy).

- Using the CR, I generated the final Certificate at GoDaddy. I took care to specify 2 different SANs (Subject Alternative Names): one was the FQDN that I use in the browser to get to the Webmail Login, and the other one is for the SMTP Server.

Doing so, when I configure whatever Mail Client, I can use secure connections both for the Incoming and Outgoing Servers. The Certificate will be OK on both of them (of course, it has to be deployed an ALL the Servers that will be accepting connections from outside with THAT PARTICULAR FQDN).

The procedure to deploy the Certificate was a bit tricky. I had to:

- Leave all the Services active on ALL the Servers (it is MANDATORY to leave the LDAP running, otherwise the Certificates deployed on the other Servers cannot be stored in the LDAP Database when deployed, causing a big mess).

- Copy the following files from the MBOX Server (the one originally used to create the Certificate Request) on ALL the other Servers:

/opt/zimbra/ssl/zimbra/commercial/commercial.csr
/opt/zimbra/ssl/zimbra/commercial/commercial.key

- Then, one by one, I had to log in to all the servers and put the Certificate Files downloaded from GoDaddy in a directory, e.g. "/root/certs":

cp gd_bundle.crt /root/certs
cp mydomain.com.crt /root/certs

- At this point, on ALL the Servers, deploy the Certificates (as root):

cd /root/certs
/opt/zimbra/bin/zmcertmgr deploycrt comm ./mydomain.com.crt ./gd_bundle.crt

- NOW, A KEY STEP: As the Certificate Authority has changed, this command has to be run as root on ALL the Servers. Failure to do so will cause a blocking error at the next reboot, and no Zimbra service would start!!

/opt/zimbra/java/bin/keytool -import -alias new -keystore /opt/zimbra/java/jre/lib/security/cacerts -storepass changeit -file /opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt

(it has to be typed as it is, password is exactly "changeit", it looks like it's a default)...

- Finally, on ALL the Servers, back to user zimbra and:

su - zimbra
zmcontrol stop
zmcontrol start

Hope this is going to be of help to somebody sooner or later.

[sinopeach]

Are you using the zimbra proxy node? I am in the same boat. Esecially for designated domain "admins" who are presented with a "Domain Admin" link in their normal web screen. Clicking here tries to connect to port 7071 on the proxy node - which is a dead end....

[sinopeach]

Could the Domain Administration link be changed too as an option?

The best option would be a command to put into nginx (zimbra proxy) a new rule for 7071 back to a storage node... in the same way that POP3, IMAP and HTTP/S is done..

[rlomba]

Regarding the Domain Administration link, for people connecting from OUTSIDE, the firewall setup I described previously solves the problem.

The public IP can be accessed from outside using the same URL for both the User Login (that will be redirected to the Proxy) and the Admin Login (in this case, the firewall will route to the Mailbox server, but the URL in the browser won't change).

Therefore, there's no need to change the Admin Link in no parts: it's dynamic, so it keeps the name that's in the URL. And, when connecting from outside (this is what happens in my case), all is already ok.

If you need this inside your intranet, maybe you can just bypass the proxy and connect straight to the Mbox server... So the URL won't definitely change, you just use the Server Name in your private DNS...

[sinopeach]

Well we run as an ASP. No such thing as internal or external. So you ran standard zimbra proxy on the proxy node with 2 ip's? Bound one IP to the zimbra stack and the other you place normal iptables rules in there to redirect?

[rlomba]

No, it's a bit different. Please read more carefully, it should be sufficiently clear that I was talking about a firewall mapping between 2 public IPs (one for the webmail/adminconsole/pop server, the other one for the SMTP/MTA server).

The first IP is routed to the Proxy Server, OR directly to the Mailbox Server for port 7071 only.

The second IP is routed one-to-one to the MTA Server.

So, there are 3 Servers behind the firewall (Proxy, Mailbox, MTA). Each of them has just 1 private IP. It's just a question of mapping rules in the front firewall.

[sinopeach]

OK - so no front firewall in out scenario.... I think I need to look at making nginx rules. Guess I need to open a ticket. Your thread was the only info I have found. Which is suprising as I would assume most people would face this issue for larger deployments....

[sinopeach]

Back to this again.

FYI @ rlomba - if your instructions were sufficiently clear - I wouldn't have had to write the last few lines... :-s

What I am getting to now - is a straight port forward - however that won't scale with the deployment we are doing where each and every geographical installation will need to be configured.

One possible better way would be to change the actual link in the code for the page and put a correct single "admin node" within an entire cluster.