Can Caddy be used in front of roundcube webmail?

1. Caddy version (caddy version): 2.4.6

2. How I run Caddy: Running caddy in an LXD container.

a. System environment:

Ubuntu server 20.04, running LXD 4.0.4

b. Command:

caddy run  and caddy reload

c. Service/unit/compose file:

N/A

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddyfile or JSON config:

www.example.com {
        root * /usr/share/caddy
}

cctv.example.com {
        reverse_proxy 192.168.1.45:8080
}

cloud.example.com {
        reverse_proxy 192.168.1.235:80
}

mail.example.com/mail {
        reverse_proxy 192.168.1.230:443
}

3. The problem I’m having:

The issue I am having, is 1: The first www.example.com entry does not load the basic index.html file in the root path specified, just gives me a blank page.

Problem #2:
The roundcube webmail server will not load correctly. It loads a blank page as well, but shows the roundcube icon in the tab of chrome.

May be a problem that I have only been using caddy for a total of 45 minutes so far?

4. Error messages and/or full log output:

No error messages or log to provide yet. Trying to figure out how to access the log, not even sure it is producing one since I did not use the log directive. Sorry!

5. What I already tried:

Have tried changing the uri, removing it, just adding /, also tried to get it to proxy to port 80, nothing helps. I have also changed a setting in the nginx config on the mail server to have it listen on port 80.

Tried adding https:// to the proxy path, so not sure if this is a syntax error on my part, or that I need to add more directives to the Caddyfile. The other sites behind Caddy are working great so far. Have yet to test the CalDAV/WebDAV features yet, but trying to get them all working for a baseline to work from.

Thanks!

6. Links to relevant resources:

Update: Problem 1 solved!

Just needed the file_server directive.

www.example.com {
        root * /usr/share/caddy
        file_server
}

One down, one to go.

Ok, finally found the log, and combed it over pretty good, here is a section that stands out as clues, hoping this adds a bit more detail. First thing I notice it is failing to validate the cert on the webmail node, also looks like an error for the reverseproxy.

Here is what I have:

Dec 17 17:32:27 caddy caddy[182]: {"level":"error","ts":1639762347.6534753,"logger":"http.log.error","msg":"x509: cannot validate certificate for 192.168.1.230 because it doesn't contain any IP SANs","request":{"remote_addr":"x.x.147.194:55370","proto":"HTTP/2.0","method":"GET","host":"mail.example.com","uri":"/","headers":{"Accept-Encoding":["br, gzip, deflate"],"Sec-Ch-Ua":["\" Not A;Brand\";v=\"99\", \"Chromium\";v=\"96\", \"Google Chrome\";v=\"96\""],"Sec-Ch-Ua-Mobile":["?0"],"Sec-Ch-Ua-Platform":["\"Windows\""],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"],"Sec-Fetch-Site":["none"],"Accept-Language":["en-US,en;q=0.9"],"Upgrade-Insecure-Requests":["1"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-User":["?1"],"Sec-Fetch-Dest":["document"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","proto_mutual":true,"server_name":"mail.example.com"}},"duration":0.038544006,"status":502,"err_id":"i4thwmwve","err_trace":"reverseproxy.statusError (reverseproxy.go:886)"}

192.168.1.230 is the webmail node that I can not get to load. Will keep plugging away at it, just wanted to share some of the log.
Thanks!

Well I tried messing with header_up and really messed it up! The syntax has me lost on this directive apparently. I can’t share what I tried, as I had to ditch the file and roll back to the backup Caddyfile since it took down all of the sites. But I went off the example for header_up.

Here is the example:

reverse_proxy https://example.com {
	header_up Host {upstream_hostport}
	header_up X-Forwarded-Host {host}
}

Here is my hacked version of the example I used and failed:

mail.example.com {
        reverse_proxy https://mail.example.com {
        header_up Host {443}
        header_up X-Forwarded-Host {mail.example.com}
}

Too chicken to mess with this again, will have to wait I guess after hours. I am pretty well lost at this point.

It seems it has issue with the upstream server (webmail) certificate lacking IP SAN’s. It has a certbot certificate, will I have to configure it to just listen on port 80 then? Is there a way to proxy to HTTPS backend hosts? Sorry to blast the questions, just lost at this point.

Thanks

Easy, panicking won’t help you make progress here. Might be best to take a break and come back when you’ve had a chance to approach it with a fresh mind.

For instance, why are you wrapping {443} and {mail.example.com} in curly braces? I guess it’s because you only looked at the examples without understanding what they do.

(This is why I’m against having examples in our docs, by the way.)

Tokens in curly braces are placeholders, kinda like variables: Caddyfile Concepts — Caddy Documentation

Why are you setting a Host header of 443? Surely that is not what you intend, right?

Again, I think it would be best to calm down and read the documentation, then try things out in a safe place before changing your production configs.

As for your certificate error, Caddy is trying to connect to the backend without SNI because the address is an IP, 192.168.1.230. If the backend doesn’t present a certificate with that IP, it won’t pass verification on the TLS client. You’ll need to make sure that Caddy connects with the right SNI if you don’t specify a hostname in the address: reverse_proxy (Caddyfile directive) — Caddy Documentation - Certbot will not fix this for you.

Thanks Matt, yes it’s always fun learning the syntax on the fly lol

Actually I found one of your other syntax examples in another thread while reading up on the x509 error code. and it did work, but I think I have something wrong as caddy no longer seems to be running with a systemctl status check.

Here is the “skip tls” entry that has it loading now:

mail.example.com {
        reverse_proxy 192.168.1.230:443 {
        transport http {
        tls
        tls_insecure_skip_verify
    }
}

So I am learning, just slowly. all of the websites load fine, but caddy is not happy.

Dec 17 18:39:32 caddy systemd[1]: caddy.service: Main process exited, code=killed, status=9/KILL
Dec 17 18:39:32 caddy systemd[1]: caddy.service: Failed with result 'signal'.

It’s all in learning fun, and this setup is not in production yet just to clarify, once I have a complete understanding how to make all of the apps work correctly, then I will work on implementing it on the production side. As you can tell, I have some bumps to sort out. :smile:

Thanks for your input!

1 Like

Caddy will print out config errors to the logs when it fails to start up. See this page in the docs to see how to use Caddy as a service, including the right command to see the logs:

In this case, you have more opening { than closing } so the Caddyfile adapter isn’t happy.

I think this might be what you’re looking for:

mail.example.com {
	reverse_proxy https://192.168.1.230:443 {
		transport http {
			tls_insecure_skip_verify
		}
	}
}

You don’t need to specify tls if you used https:// on the upstream address.

Keep in mind that using tls_insecure_skip_verify turns off all security offered by using HTTPS/TLS when proxying, it’s effectively the same as using HTTP in terms of security, but with extra encryption overhead.

Thank you Francis, I had a feeling I was missing a critical element.

The tls_insecure_skip was only to see if it would work. Sort of like turning off authentication just to test it.

I think I need to use the tls_server_name for the tls handshake - if I am following the documentation so far.

Something I plan to try later on:

mail.example.com {
	reverse_proxy https://192.168.1.230:443 {
		transport http {
			tls_server_name mail.example.com
		}
	}
}

Hey if a moron like me can get this up and running, it proves how easy Caddy is to configure right?

Again, thanks for the input, the support here is top notch!

2 Likes

After going over the documentation and reviewing the log a few times, and a little trial and error - this is what I came up with, and this is what is working for me:

mail.example.com {
        reverse_proxy https://192.168.1.230 {
                transport http {
                        tls_server_name mail.example.com
                }
                header_up Host {upstream_hostport}
                header_up X-Forwarded-Host {host}
        }
}

Almost like I know what I am doing, haha NOT!

I have to compliment the developers of Caddy, this has been less of a learning curve than other apps, and I am NOT a developer, my day job is infrastructure/network guy, so I am way out of my wheelhouse with this stuff. Thanks for all the help on this!

4 Likes

Cool, glad you got it working. Thanks for the nice remarks! There is a lot to learn about how systems and networks work too, and then we try to make that easy to manage in Caddy.

1 Like

Matt, it is MUCH appreciated!! It is REALLY helpful to have tools such as Caddy to help bridge the gap for people in my situation where I have to put my hands on all seven layers of the OSI model and just make it work. Many thanks!!

Have a Merry Christmas if I don’t bug you guys again.

2 Likes

Merry Christmas to you too :slight_smile: :christmas_tree:

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.