Caddy-docker-proxy: Connection Refused: "type":"urn:ietf:params:acme:error:connection"

[the-bort-the]

Crossposting from the Caddy community forum to see if this could be a true bug nor not
I’m trying to complete the setup and configuration of caddy-docker-proxy I found here 1. I have used the exact same docker-compose.yml and Dockerfile.

I have used my own domain in place of course. The caddy container is running, updating my A record within Cloudflare, but ultimately shows a few errors as seen in the title of the post with more presented below.

I have used their Caddyfile as mine as well. Lastly I have implemented the adguard container as shown in the same github repo.

Basically I want to use my domain and caddy-docker-proxy to get a certificate for any other applications that are started using a docker-compose.yml (adguard, pihole, jellyfin, etc.)

error from logs:
{"level":"error","ts":1731613001.0729275,"logger":"tls.issuance.acme.acme_client","msg":"challenge failed","identifier":"adguard.itsacomputer.com","challenge_type":"http-01","problem":{"type":"urn:ietf:params:acme:error:connection","title":"","detail":"REDACTED PUBLIC IP: Fetching http://adguard.itsacomputer.com/.well-known/acme-challenge/wWj13Yl89YUWhJkKn_qyQiahgTXiSM5ukmfJuzLR7JQ: Connection refused","instance":"","subproblems":[]}} {"level":"error","ts":1731613001.0730493,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"adguard.itsacomputer.com","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 400 urn:ietf:params:acme:error:connection - REDACTED PUBLIC IP: Fetching http://adguard.itsacomputer.com/.well-known/acme-challenge/wWj13Yl89YUWhJkKn_qyQiahgTXiSM5ukmfJuzLR7JQ: Connection refused"}

caddyfile:

{
  debug
}
{
	admin localhost:2019
	email my@email.com
	dynamic_dns {
		provider cloudflare {
			zone_token {env.zone}
			api_token {env.api}
		}
		domains {
			itsacomputer.com @
		}
		ip_source simple_http https://icanhazip.com
		check_interval 15m
        versions ipv4
	}
}

dockerfile:

ARG GOLANG_VERSION=1.22.1
ARG ALPINE_VERSION=3.19

FROM golang:${GOLANG_VERSION}-alpine${ALPINE_VERSION} as gobuild
ARG GOLANG_VERSION
ARG ALPINE_VERSION

WORKDIR /go/src/github.com/caddyserver/xcaddy/cmd/xcaddy

RUN apk add --no-cache git gcc build-base; \
    go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest

RUN xcaddy build \
    --output /go/src/github.com/caddyserver/xcaddy/cmd/caddy \
    --with github.com/lucaslorentz/caddy-docker-proxy/v2 \
    --with github.com/mholt/caddy-dynamicdns \
    --with github.com/caddy-dns/cloudflare

FROM alpine:${ALPINE_VERSION}

RUN apk add --no-cache ca-certificates curl tzdata; \
    rm -rf /var/cache/apk/*;

EXPOSE 80 443 2019

ENV XDG_CONFIG_HOME /config
ENV XDG_DATA_HOME /data

COPY --from=gobuild /go/src/github.com/caddyserver/xcaddy/cmd/caddy /usr/bin/

HEALTHCHECK --interval=10s --timeout=5s --start-period=5s CMD curl -fsS http://127.0.0.1:2019/config -o /dev/null || exit 1

ENTRYPOINT ["/usr/bin/caddy"]
CMD ["docker-proxy"]

[francislavoie]

That error is that Caddy is trying to get a TLS cert for your domain using the ACME HTTP challenge, which requires port 80 to be open and forwarded. Let's Encrypt is not able to connect to your server, so something with your networking setup is not correct.

[the-bort-the]

I am running OpenWRT on my modem/router and I know this might be out of scope for here, but I exposed 80 and 443 and believe the issues still persists:

/etc/config/firewall:

config redirect
	option name 'HTTP-Forward'
	option src 'wan'
	option src_dport '80'
	option dest 'lan'
	option dest_ip '192.x.x.x'
	option dest_port '80'
	option target 'lan'
	option proto 'tcp'
	option enabled '1'

config redirect
	option name 'HTTPS-Forward'
	option src 'wan'
	option src_dport '443'
	option dest 'lan'
	option dest_ip '192.x.x.x'
	option dest_port '443'
	option target 'lan'
	option proto 'tcp'
	option enabled '1'

Then heading to https://letsdebug.net/, I'm seeing these errors. Seeing the error regarding no record is confusing as I have the A record being created by the dynamic dns plugin being created as part of the dockerfile.

[IssueFromLetsEncrypt](https://letsdebug.net/itsacomputer.com/2284460#IssueFromLetsEncrypt-Error)
Error
A test authorization for itsacomputer.com to the Let's Encrypt staging service has revealed issues that may prevent any certificate for this domain being issued.
no valid A records found for itsacomputer.com; no valid AAAA records found for itsacomputer.com

[NoRecords](https://letsdebug.net/itsacomputer.com/2284463#NoRecords-Fatal)
Fatal
No valid A or AAAA records could be ultimately resolved for itsacomputer.com. This means that Let's Encrypt would not be able to connect to your domain to perform HTTP validation, since it would not know where to connect to.
No A or AAAA records found.

[francislavoie]

You have a DNS record for * which means subdomains of that domain like *.itsacomputer.com but not itsacomputer.com itself. You need a @ record for the apex domain.

[the-bort-the]

This seemed to be the fix. Coupled with the redirect and port forwarding rules, adding the @ was the key. While great, I'm assuming there isn't a way to achieve the same effect, but without exposing ports to the internet. Is there a chance to use the caddy.tls: internal as seen here? I assuming based on earlier comments, ports must be exposed and forwarded.

	dynamic_dns {
		provider cloudflare {env.api_token}
		domains {
			mydomain.com *
			mydomain.com @ //added as per suggestion for the apex domain
		}

[francislavoie]

Is there a chance to use the caddy.tls: internal as seen here?

Yes you can do that and have no requirement of your site being publicly accessible. But you'd have to install Caddy's root CA cert on your client machines for them to trust connections to Caddy. See https://caddyserver.com/docs/running#local-https-with-docker