Tomcat Reverse Proxy and SSL - not all files served via SSL

[canoodle]

Hello,
thanks for this cool webserver with let’s encrypt build in! (the way to go for all other webservers out there!

now my problem:

requirements:

vhost + proxy + SSL (let’s encrypt) for tomcat docker instance.

caddy.conf looks like:

domain1.com, www.domain2.com, domain3.com {
    proxy / http://172.18.0.3:8080 {
        websocket
        transparent
    }
}

everything works pretty smooth thanks for that…

but the SSL-Browser-Lock turns from green to “warning”, because for some reason not all files are transfered via SSL or requested by firefox browser via SSL?

how can i force caddy to redirect/serve all files via SSL?

thanks!

PS: the funny thing is… browser seems to request this file (logo) unencrypted and then a second time encrypted?

for details:
caddy is running inside a docker instance like this:

docker run -it --name=alpine-caddy-tomcat-proxy --entrypoint /startup.sh -p 80:80 -p 443:443 --net=example-net --ip 172.18.0.4 image:tag

/startup.sh looks like:

/bin/sh
/usr/sbin/caddy -conf /etc/caddy/caddy.conf

PS: not sure if closing port 80 via docker is the right solution, but i might try that.

[comp500]

This is due to the server that you are proxying linking something as HTTP. Caddy automatically redirects this request to the HTTPS equivalent, so that’s why you see two requests.

You’ll need to fix the tomcat instance or the website running on it to use HTTPS links to stop this problem.

[Whitestrake (Matthew Fay)]

Good reply by @comp500. You could also make Caddy more permissive (serve the same files on HTTP as HTTPS, rather than forcing upgrades), by duplicating your site labels and prepending them with both schemes, e.g. http://example.com, https://example.com. I’d probably just leave it, though; more secure is almost always better, and the double request is a really minor delay.

@canoodle

PS: not sure if closing port 80 via docker is the right solution, but i might try that.

This is inadvisable. The results of this would be:

1. The request for the logo would happen only once, rather than twice, and it would result in a timeout, and your logo would not be displayed in the page unless it was cached.
2. Caddy would be unable to manage new certificates using LetsEncrypt while TLS-SNI validation is disabled due to security concerns unless you add DNS validation.

[canoodle]

Thanks for the quick reply… so it is a problem of Java-Application running on Tomcat using/generating absolute http://domain.com/simeapplet links?

if it would use relative links this problem would not exist? (it is only with the logo… so that’s my guess absolute vs relative)

[comp500]

Yes, they need to be https:// links.
Absolute links will work fine as long as they have https:// URLs, however I prefer to use relative links, as you don’t have to change them when you change domain.

[canoodle]

Thanks for your support.

It was actually a hardcoded link “LOGO SETTINGS” that was possible to be fixed, by changing the absolute http://domain.com/path/logo.png url to https

nothing wrong with caddy