First, a big thanks to all devs and contributors to this magnificent project. It sure is fun to work with mailcow. I just stumbled across this project a few days ago and decided to give it a try. I'm not a pro, let alone a Linux guru, so I had various issues with certs and Nginx reverse proxy. I managed to solve all of the problems and ended up with a working instance of a mailcow dockerized behind an Nginx reverse proxy, eventually. Because of all the config involved in setting up Nginx and Let'sencrypt (yes, I'm lazy...), I decided to try [**Caddy server**](https://caddyserver.com/) as a reverse proxy, which I discovered recently. I remembered from my other projects, it was simple to install and it worked out-of-the-box. Caddy has reverse proxy included, HTTPS by default, automatic certs, and renewals. No fuss, almost no config :) I got a 2 core, 4GB RAM Ubuntu 20.04 cloud server at [Hetzner](https://hetzner.cloud/?ref=SIlebhiFcgeC) (aff. link), for a test. Apart from setting up the Caddy server, I followed the manuals in everything else in detail: [prerequisites, setting up docker and docker-compose, open ports and DNS settings.](https://mailcow.github.io/mailcow-dockerized-docs/prerequisite-system/) Instead of using acme-mailcow to handle the certs, I turned that option off in mailcow.conf. I added an additional server name (my.mail-domain.tld), with which I wanted to access my mailcow host (my.mailcow-host.tld), also. Then I changed HTTP and HTTPS ports and bindings. Here are all the changes I made to the mailcow.conf: `MAILCOW_HOSTNAME=my.mailcow-host.tld` . . `HTTP_PORT=8080` `HTTP_BIND=127.0.0.1` `HTTPS_PORT=8443` `HTTPS_BIND=127.0.0.1` . . `ADDITIONAL_SERVER_NAMES=my.mail-domain.tld` . . `SKIP_LETS_ENCRYPT=y` After `docker-compose pull` and `docker-compose up -d` I installed Caddy server like this: `echo "deb [trusted=yes] https://apt.fury.io/caddy/ /" | sudo tee -a /etc/apt/sources.list.d/caddy-fury.list sudo apt update sudo apt install caddy libnss3-tools` With Caddy installed I needed to config it as a reverse proxy. To do this I commented everything out in its config file located at /etc/caddy/Caddyfile and added the following: `my.mailcow-host.tld { reverse_proxy 127.0.0.1:8080 } my.mail-domain.tld { reverse_proxy 127.0.0.1:8080 }` I had to reload Caddy afterward with `caddy reload` in /etc/caddy . That was it! I just waited a minute or so for Caddy to generate certs. After a short wait, I headed to my.mailcow-host.tld and was presented with a secure, valid Let's encrypt protected mailcow login! The same was true for my.mail-domain.tld. After initial config and adding a mail-box for a user@mail-domain.tld I can confirm everything just works! I got myself **a working Mailcow-dockerized instance behind Caddy server reverse proxy** with automatic Let's encrypt. All this with almost no config and no hassle. Of course, none of this would be possible without a wonderful team behind Mailcow - Thank You again! Please note: 1. This was a test setup. I'm planning to go to production in a few weeks. 2. For this setup to work and for a Caddy server to be able to issue certs, all DNS records must be correct and must already propagate before the setup. 3. The link to Hetzner is an affiliate link. It will get you 20€ in cloud credits if you decided to go with them. And I'd receive a small commission :). To admins: remove if inappropriate. --Robert

Thanks for the how-to. I am wondering, how mailcow gets the certificates that caddy generated for the IMAP and SMTP ports, though. Does this really work?

Hello! Yes it works great all that time since the first post. I set up a production server with some email domains. As for certs: I created a simple bash script that copies .crt and .key files from caddy's letsencrypt location to corresponding .pem files in /opt/mailcow-dockerized/data/assets/ssl/ I also changed SKIP_LETS_ENCRYPT to yes in mailcow.conf so only caddy takes care of certs. I'm upgrading the server and mailcow regulary. Apart from a few minor issues averything works beautiful.

Great to hear. I will try to set it up here the same. How many domains do you use in Mailcow? I would have three. So, you let caddy generate all the certificates and just copy all of them over to Mailcow directory, thereby renaming them to pems? Do you keep the rest of the filenames the same, e.g. in you example: ` copy my.mailcow-host.tld.crt => cert.pem copy my.mailcow-host.tld.key => key.pem copy my.mailcow-domain.tld.crt => my.mailcow-domain.tld.cert.pem copy my.mailcow-domain.tld.key => my.mailcow-domain.tld.key.pem ` Like this?

Exactly. I use three domains, too. I let the first domain be the mail exchanger for all three domains. I only issue cert for the first domain but I'm sure your setup with more https domains should work just the same. Please report on your progress.

This setup also seems to be working fine for me, except autoconfig....if I add ``` autoconfig.mail-domain.tld { reverse_proxy 127.0.0.1:8080 } ``` to the caddy config, the xml autoconfig information points to my.mailcow-host.tld, whereas I was wanting it to point to my.mail-domain.tld. (I had copied the my.mail-domain.tld certs for use with dovecot.) I'll probably just turn autoconfig off for now since my personal domain only has a a few users so manual configuration is feasible. Alternatively I'll just use my principal my.mail-domain.tld domain for both dovecot and the mailcow web interface, and not use separate domains as in the OP. The caddy setup is still great since it is easy to add additional applications (e.g. a wordpress blog) to the cloud server. (Maybe it is also easy to run other applications using the NGINX proxy but I am only familiar with caddy. I would consider ditching caddy and reverting back to NGINX only if there was a tutorial on how to extend the existing mailcow-dockerized to add additional applications.)

Sorry, for reactivation a "old" thread. And hopefully, I did not tell anything wrong. But let your mailserver have the hostname/domain mail.mydomain.com, there you are running an email configuration for the mail-domain "mymail.com" (like info@mymail.com) then autodiscover.mymail.com should a CNAME to mail.mydomain.com If this is done, caddy should work with mail.mydomin.com audodiscover.mymail.com autoconfig.mymail.com { reverse_proxy 10.20.30.40:8080 } Obviously, there is no mymail.com domain (without auto*). And thats correct, as the mail-server (not mail-domain) is mydomain.com, not mymail.com. --> its correct if autoconfig configure mail.mydomain.com instead mymail.com. The domain-switch is done thru the login-name, which contains the mx-domain.

@"robertrud"#p2909 Hey there! Thank you very much for that tutorial. We from the mailcow team would like to see that reverse proxy config in the official mailcow documentation. So if you don't mind we would like to implement it. Or you can implement it either if you want to :) But yeah, if you don't have time to thats ok, but i'll ask for your permission anyways :) Kind regards Niklas (mailcow Dev)

Hey, nice to hear that! Please, go ahead, implement it! It would mean a lot to me. You are right about the time :), so it'd be the best if you could do it. Best regards Robert

Of interest is the new eventing system in caddy. I haven't tried it, but it should allow us to set up a certificate provisioning hook which could copy the new certs to the correct locations so that they can be used for the mailcow servers. https://github.com/caddyserver/caddy/pull/4984

Uh! That is awesome. I´ll take a look at that and prepare a script for that then which will be part of the Docs.

Caddy server reverse proxy how-to

iljur

iljur And yes, maybe a script executed as caddy-user is (and should) not be able to restart any containers after copying the certs.
So the cronjob way like proposed in mailcow docs seems like the proper way to go.

@Admins: Please feel free to edit/delete my comments.

ksylvan

There’s also this:

https://caddyserver.com/docs/json/apps/http/servers/listener_wrappers/proxy_protocol/

teodorescuserban

I was wondering if instead of restarting the contaiers you would only reload the processes inside (nginx, dovecot, postfix).
Wouldn’t that be enough to pick up the new certificates?
Nice job, btw!

« Previous Page