We are using an AWS ELB as a means to route to multiple EC2 instances. Currently we are using IIS/ARR to provide routing to local Tomcat instances. ARR (Application Request Routing) is the main reason for this setup so we can route traffic to the correct tomcat instance.
I would like to rip out IIS and replace it with Caddy but I am running into an issue where HTTPS doesn’t seem to be routing correctly. When performing a HTTP request I do get a server response header of “Caddy” before it redirects to HTTPS which when that happens I get a 502 from aws alb.
The only thing I can see right now with Wireshark is that a TLSv1.2 handshake initiates from the AWS ALB IP address “Client Hello” and the response back from the Caddy server is “Alert (Level: Fatal, Description: Internal Error)”
I am able modify the HOSTS file on the server and successfully access the tomcat site through Caddy just fine; including SSL termination.
One thing that was happening with the letsencrypt issuance was that it wasn’t working unless I set it to http. But the cert was issued and I know it’s terminating fine.
If you’re talking about the errors directive; I just added it in and nothing is shown in that log. The access logs via the “log” directive also does not show anything.
It does use SNI. Using IIS/ARR it works fine so I’m not fully understanding why this isn’t; mainly because I see Caddy respond with a response header when using http but as soon as the flip to HTTP happens it no longer works; the AWS/ALB gives a 502 and on the Caddy server I see the attempted handshake for TLS 1.2 but it errors out. I’ve verified that caddy/tomcat is working fine by accessing the site via a browser on the local server that has Caddy/Tomcat.
Also the process log (-log /path/to/caddy.log) given as a flag. Alternately to stdout if you’ve got something else logging the program’s output. You haven’t actually specified how you’re actually running Caddy in this environment, so I’m not sure what’s appropriate.
Anyway, If Caddy’s breaking somehow, that’s likely where we’ll see an error or panic, and it’s also where we’ll see non-site-specific errors, since errors and log are both specific to the site you configure them for.
Up until now I wasn’t running any switches with Caddy. So thank you for pointing me down the right path. I added in the -log switch and found the issue. The ALB does support SNI but on the frontend; but maybe not on the backend.
This is from the logs:
2020/03/20 08:41:59 http: TLS handshake error from 10.2.5.126:31486: no certificate available for ‘’
2020/03/20 08:41:59 http: TLS handshake error from 10.2.5.75:45732: no certificate available for ‘’
2020/03/20 08:42:01 http: TLS handshake error from 10.2.5.126:31576: no certificate available for ‘’
2020/03/20 08:42:01 http: TLS handshake error from 10.2.5.75:45838: no certificate available for ‘’
2020/03/20 08:42:06 http: TLS handshake error from 10.2.5.126:31648: no certificate available for ‘’
2020/03/20 08:42:06 http: TLS handshake error from 10.2.5.75:45874: no certificate available for ‘’
2020/03/20 08:42:11 http: TLS handshake error from 10.2.5.126:31686: no certificate available for ‘’
2020/03/20 08:42:11 http: TLS handshake error from 10.2.5.75:45914: no certificate available for ‘’
2020/03/20 08:42:16 http: TLS handshake error from 10.2.5.126:31736: no certificate available for ‘’
2020/03/20 08:42:16 http: TLS handshake error from 10.2.5.75:45982: no certificate available for ‘’
2020/03/20 08:42:21 http: TLS handshake error from 10.2.5.126:31808: no certificate available for ‘’
2020/03/20 08:42:21 http: TLS handshake error from 10.2.5.75:46046: no certificate available for ‘’
I added on -default-sni switch and forced it to the specific site and it works!
However since we host around 15 - 20 sites I need a better solution. I guess I could always just use a self-signed cert and be done with it but it would be nice to utilize the letsencrypt certs that are auto issued.