Need help migrating tomcat reverse proxy from caddy v1 to caddy v2

trying to migrate a working caddy v1 config to caddy v2

1. Caddy version (caddy version):

caddy v2 from docker hub pull caddy
caddy version
v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

caddy v1 also used to be from docker hub
caddy --version
Caddy 0.10.10 (unofficial)

← already tried to upgrade within Alphine Linux but then get error message:

2. How I run Caddy:

v1
/usr/sbin/caddy -conf /etc/caddy/caddy.conf

a. System environment:

host ist CentOS7 + docker

caddy v1 is running in the one year ago default “docker pull caddy” Alpine Linux container

caddy v2 will be installed inside Debian 10 docker container

b. Command:

c. Service/unit/compose file:

d. My complete Caddyfile or JSON config:

reverse proxy

caddy1 config

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

3. The problem I’m having:

caddy won’t start.

"Activating privacy features…2020/08/24 10:40:55

registration error: acme: Error 403 - urn:acme:error:unauthorized

Account creation on ACMEv1 is disabled

Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555

See End of Life Plan for ACMEv1 - API Announcements - Let's Encrypt Community Support

for details."

4. Error messages and/or full log output:

5. What I already tried:

6. Links to relevant resources:

HELP! :slight_smile:

Did you read the upgrade guide?

Hello,

yes so,

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

caddy accepts the config:

/usr/bin/caddy run --config /etc/caddy/Caddyfile-reverse-proxy

2020/08/26 08:46:58.495 ERROR http.log.error dial tcp 172.18.0.3:8080: connect: connection refused {“request”: {“method”: “GET”, “uri”: “/”, “proto”: “HTTP/2.0”, “remote_addr”: “37.81.222.155:40994”, “host”: “domain.com”, “headers”: {“User-Agent”: [“Mozilla/5.0 (X11; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0”], “Accept”: [“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8”], “Accept-Language”: [“en-US,en;q=0.5”], “Accept-Encoding”: [“gzip, deflate, br”], “Upgrade-Insecure-Requests”: [“1”], “Te”: [“trailers”]}, “tls”: {“resumed”: false, “version”: 772, “ciphersuite”: 4865, “proto”: “h2”, “proto_mutual”: true, “server_name”: “domain.com”}}, “duration”: 0.000854817, “status”: 502, “err_id”: “jnaaxd0e9”, “err_trace”: “reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:411)”}
2020/08/26 08:46:58.736 ERROR http.log.error dial tcp 172.18.0.3:8080: connect: connection refused {“request”: {“method”: “GET”, “uri”: “/favicon.ico”, “proto”: “HTTP/2.0”, “remote_addr”: “37.81.222.155:40994”, “host”: “domain.com”, “headers”: {“User-Agent”: [“Mozilla/5.0 (X11; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0”], “Accept”: [“image/webp,/”], “Accept-Language”: [“en-US,en;q=0.5”], “Accept-Encoding”: [“gzip, deflate, br”], “Te”: [“trailers”]}, “tls”: {“resumed”: false, “version”: 772, “ciphersuite”: 4865, “proto”: “h2”, “proto_mutual”: true, “server_name”: “domain.com”}}, “duration”: 0.001012693, “status”: 502, “err_id”: “646yftxvp”, “err_trace”: “reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:411)”}
2020/08/26 08:47:05.022 ERROR http.log.error dial tcp 172.18.0.3:8080: connect: connection refused {“request”: {“method”: “GET”, “uri”: “/”, “proto”: “HTTP/2.0”, “remote_addr”: “179.43.169.182:59754”, “host”: “www.domain.com”, “headers”: {“User-Agent”: [“Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20100101 Firefox/10.0”], “Accept-Encoding”: [“gzip”]}, “tls”: {“resumed”: false, “version”: 772, “ciphersuite”: 4865, “proto”: “h2”, “proto_mutual”: true, “server_name”: “www.domain.com”}}, “duration”: 0.000658902, “status”: 502, “err_id”: “ejwsvv6bi”, “err_trace”: “reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:411)”}
2020/08/26 08:47:05.113 ERROR http.log.error dial tcp 172.18.0.3:8080: connect: connection refused {“request”: {“method”: “GET”, “uri”: “/”, “proto”: “HTTP/2.0”, “remote_addr”: “179.43.169.182:59754”, “host”: “www.domain.com”, “headers”: {“User-Agent”: [“Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20100101 Firefox/10.0”], “Accept-Encoding”: [“gzip”]}, “tls”: {“resumed”: false, “version”: 772, “ciphersuite”: 4865, “proto”: “h2”, “proto_mutual”: true, “server_name”: “www.domain.com”}}, “duration”: 0.000757006, “status”: 502, “err_id”: “2d3t6ywek”, “err_trace”: “reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:411)”}

PS: thanks for caddy :slight_smile:

we are having a baby it’s tough X-D to concentrate on anything and almost no time to get anything done
PS: also /etc/caddy/Caddyfile is now the default file

and will be loaded per default?

unless --config /etc/caddy/another-file

is specified?

1 Like

That’s correct. The default CMD in docker uses /etc/caddy/Caddyfile:

Is your new Caddy container running in the same Docker network as your old one? You config should work just fine as long as Caddy has network access to your backend service.

Congrats! :smile:

I’m mobile so haven’t had a chance to read into this too much but just wanted to say I really like the table formatting for the log lines! Also congratulations on the baby!

thanks! :slight_smile:

great community here

it is very strange

from host to client it is possible to connect to the tomcat docker container

telnet 172.18.0.2 8080
Trying 172.18.0.2...
Connected to 172.18.0.2.
Escape character is '^]'.

but from container caddy v2 to container tomcat it is not possible

telnet 172.18.0.2 8080
Connected to 172.18.0.2
Connection closed by foreign host

strange :thinking:

yes they are all on the same network example-net

Typically when I use Docker I just use the container names when proxying rather than the IP. Docker will wire up the internal DNS service to resolve the container names to the actual IP address of the container. Give that a shot.

that was funny, yes it is possible to

ping ContainerName

now it also works with ip… can’t really say what happened X-D

  1. went back to snapshot of host, where caddy v1 still used to work (installed 2 years ago)

  2. updated host CentOS 7 to latest (also updated caddy:latest to latest)

  3. changed ssh port
    maybe
    firewall-cmd --reload
    did then the magic trick?

  4. then created new container caddy:latest

    docker run -it --name=caddy2-proxy_v1 -p 80:80 -p 443:443 --net=example-net --ip 172.18.0.4 caddy:latest

    then login

    docker exec -it caddy2-proxy_v1 sh

    alpine linux upgrade to latest and install telnet

    apk update
    apk upgrade --available;
    apk add busybox-extras

  5. modified caddy file

    vi /etc/caddy/Caddyfile

    domain2.com, www.domain.com, domain.com
    reverse_proxy 172.18.0.2:8080

  6. stop caddy
    caddy stop

    start caddy interactively to see the debug messages

    /usr/bin/caddy run --config /etc/caddy/Caddyfile

  7. it works :slight_smile:

have just one hickup with domain2.com:

2020/08/29 21:05:16 [INFO] [domain2.com] acme: Obtaining bundled SAN certificate given a CSR
2020/08/29 21:05:17 [INFO] [domain2.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/6856721113
2020/08/29 21:05:17 [INFO] [domain2.com] acme: Could not find solver for: tls-alpn-01
2020/08/29 21:05:17 [INFO] [domain2.com] acme: use http-01 solver
2020/08/29 21:05:17 [INFO] [domain2.com] acme: Trying to solve HTTP-01
2020/08/29 21:05:24 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/6856721113
2020/08/29 21:05:24 [INFO] Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/6856721113
2020/08/29 21:05:24 [ERROR] error: one or more domains had a problem:
[domain2.com] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Invalid response from https://domain2er.com/somepage.html/.well-known/acme-challenge/MdUxit-BJbV_be3qll_YHXtvDl5W3xcMaJdAb54mEJM [134.119.234.XXX]: “\n\n\n\n\n\n\n”, url:
(challenge=http-01 remaining=[])
2020/08/29 21:05:26 [ERROR] attempt 1: [domain2.com] Obtain: [domain2.com] error: one or more domains had a problem:
[domain2.com] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Invalid response from https://domain2er.com/somepage.html/.well-known/acme-challenge/MdUxit-BJbV_be3qll_YHXtvDl5W3xcMaJdAb54mEJM [134.119.234.XXX]: “\n\n\n\n\n\n\n”, url:

  • retrying in 1m0s (27.220196258s/720h0m0s elapsed)…

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