Caddy to provide TLS connection to an API that is behind a domain - hosted on AWS


1. Version of Caddy I am using (2.7.5)

2. How I am running Caddy:

I have an Api solution. It is built and deployed onto Amazon ECS via it’s own Dockerfile. In the Dockerfile, I expose port 80. It is working, of course without TLS.

I have another Dockerfile in which I use Caddy builder image to build caddy-dns/route53 module using xcaddy command. This seems to be working as I am able to get the image running in Amazon ECS. The ECS task has Here is the content of the caddy dockerfile:

# syntax=docker/dockerfile:1

FROM caddy:2.7.5-builder-alpine AS builder
RUN xcaddy build --with

FROM caddy:2.7.5

COPY Caddyfile /etc/caddy/Caddyfile
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

WORKDIR /etc/caddy

RUN caddy fmt --overwrite

The Caddyfile looks like this:

} {
   tls {
      dns route53
      protocols tls1.2 tls1.3
   reverse_proxy simpleauthentication:80

I have reviewed the log I get for the caddy ECS and I saw that it successfully obtained the certificated and downloaded it and everything.

3. Log output:

Below is the last few steps in the log. The log is huge:

{"level":"debug","ts":1700077395.7016873,"logger":"tls.cache","msg":"added certificate to cache","subjects":[""],"expiration":1707849794,"managed":true,"issuer_key":"","hash":"5ea0d6fdf2b975f859b7ef35ee40e8a677151812ede32e5f175af105dd2078b6","cache_size":1,"cache_capacity":10000}

{"level":"info","ts":1700077395.5694242,"logger":"tls.obtain","msg":"certificate obtained successfully","identifier":""}

Caddy image is running under linux arm64 CPU architecture in Amazon ECS.

4. Problem I am having:

The problem is, although the certificate is obtained, downloaded and cached, when I navigate to my API url via https I get connection refused error on the browser. I cannot figure out what is the problem.

5. What I’ve already tried:

I have amended the caddy docker file and added


The same issue. :frowning:

Please help.

Thanks a lot.

I figured it out!!!

In Amazon Route53, by mistake, I assigned the public DNS of the API container to the subdomain that I wanted Caddy to generate TLS for. This was causing network error 502. What I should have done was for the subdomain to point at the Caddy server instead, which is also a container with a public DNS.

In my Caddyfile, as shared above, I incorrectly configured reverse_proxy by pointing it to the API container name. This must be the actual DNS or IP address of the API container instead.

After applying the fixes above, my API was redirected to HTTPS with valid TLS.

I passed both my subdomain and the API container DNS in the Caddyfile via environment variables.

I hope this helps others.

Thanks a lot.

Using the container name would work if the container is in the same Docker network as Caddy (because Docker’s DNS resolver would resolve it). If it’s not, then yes it’s true you’d need to take a different approach.

Both containers were/are in the same network (VPC in AWS). They both under the same cluster and have the same subnets. But, still Caddy could not find the container by its name. I quite like the container name approach more than the second one. Any advice please? Thanks

AWS networks and Docker networks are not the same. They’re completely separate concepts.

Sorry, I don’t use AWS so I can’t help you with AWS networking.

You could use Docker Swarm or Kubernetes or whatever to set up a Docker network that spans multiple servers.

But that’s outside the scope of these forums. This isn’t a Caddy problem at this point, it’s a networking problem.