Reverse proxy and server for wordpress

1. Caddy version (caddy version):

v2.0.0 h1:pQSaIJGFluFvu8KDGDODV8u4/QRED/OPyIR+MWYYse8=

2. How I run Caddy:

I’d like to run caddy in two jails.
In the first, as a substitute for the reverse proxy in use.
In the second, as a file server for a wordpress site.

a. System environment:

FreeBSD 12.1-RELEASE-p1
The server is supposed to be able to serve some sites.
The reverse proxy should choose the end point based on the URL of the site being accessed.
The same server (same IP) have several sites with certificates issued by Letsencrypt.

b. Command:

caddy run

d. My complete Caddyfile or JSON config:

for the reverse proxy, just for one site, in one jail at 127.0.0.87, where port 80 and 443 are redirected to via packet filtering.

mysite.pt {
        reverse_proxy https://127.0.0.89:8089
}

for the end point in another jail.

mysite.pt:8089 {
                root * /usr/local/www/apache24/data/wordpress
                encode gzip zstd
                php_fastcgi unix//var/run/php-fpm/sockets/php-fpm.sock
                file_server
}

3. The problem I’m having:

At the end point, cannot get the certificate and the get request for the index.php of the wordpress site returns nothing.

4. Error messages and/or full log output:

{"level":"info","ts":1598741349.9697716,"msg":"using adjacent Caddyfile"}
{"level":"info","ts":1598741349.9767356,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
{"level":"info","ts":1598741349.9773576,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1598741349.9788928,"logger":"tls","msg":"cleaned up storage units"}
{"level":"info","ts":1598741349.9790525,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["mysite.pt"]}
{"level":"info","ts":1598741349.9793897,"msg":"autosaved config","file":"/root/.config/caddy/autosave.json"}
{"level":"info","ts":1598741349.9794214,"msg":"serving initial configuration"}
2020/08/29 23:49:09 [INFO][cache:0xc0006ee780] Started certificate maintenance routine
2020/08/29 23:49:09 [INFO][mysite.pt] Obtain certificate; acquiring lock...
2020/08/29 23:49:09 [INFO][mysite.pt] Obtain: Lock acquired; proceeding...
2020/08/29 23:49:10 [INFO][mysite.pt] Waiting on rate limiter...
2020/08/29 23:49:10 [INFO][mysite.pt] Done waiting
2020/08/29 23:49:10 [INFO] [mysite.pt] acme: Obtaining bundled SAN certificate given a CSR
2020/08/29 23:49:11 [INFO] [mysite.pt] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3333333333
2020/08/29 23:49:11 [INFO] [mysite.pt] acme: use tls-alpn-01 solver
2020/08/29 23:49:11 [INFO] [mysite.pt] acme: Trying to solve TLS-ALPN-01
2020/08/29 23:49:15 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3333333333
2020/08/29 23:49:16 [INFO] Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3333333333
2020/08/29 23:49:16 [ERROR] error: one or more domains had a problem:
[mysite.pt] acme: error: 400 :: urn:ietf:params:acme:error:tls :: remote error: tls: internal error, url: 
 (challenge=tls-alpn-01 remaining=[http-01])
2020/08/29 23:49:18 [INFO] [mysite.pt] acme: Obtaining bundled SAN certificate given a CSR
2020/08/29 23:49:19 [INFO] [mysite.pt] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2222222222
2020/08/29 23:49:19 [INFO] [mysite.pt] acme: Could not find solver for: tls-alpn-01
2020/08/29 23:49:19 [INFO] [mysite.pt] acme: use http-01 solver
2020/08/29 23:49:19 [INFO] [mysite.pt] acme: Trying to solve HTTP-01
2020/08/29 23:49:19 http: TLS handshake error from 127.0.0.87:11253: no certificate available for '127.0.0.89'
2020/08/29 23:49:20 http: TLS handshake error from 127.0.0.87:32586: no certificate available for '127.0.0.89'
2020/08/29 23:49:20 http: TLS handshake error from 127.0.0.87:14488: no certificate available for '127.0.0.89'
2020/08/29 23:49:24 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2222222222
2020/08/29 23:49:24 [INFO] Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2222222222
2020/08/29 23:49:24 [ERROR] error: one or more domains had a problem:
[mysite.pt] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Invalid response from https://mysite.pt/.well-known/acme-challenge/7eDjRQj2Fa3iGUV1uHWQsbIlfqNOwHsSE0n61iDjDe8 [80.211.147.82]: 502, url: 
 (challenge=http-01 remaining=[])
2020/08/29 23:49:26 [ERROR] attempt 1: [mysite.pt] Obtain: [mysite.pt] error: one or more domains had a problem:
[mysite.pt] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Invalid response from https://mysite.pt/.well-known/acme-challenge/7eDjRQj2Fa3iGUV1uHWQsbIlfqNOwHsSE0n61iDjDe8 [80.211.147.82]: 502, url: 
 - retrying in 1m0s (16.486135307s/720h0m0s elapsed)...
{"level":"info","ts":1598741417.0728834,"msg":"shutting down","signal":"SIGINT"}
2020/08/29 23:50:17 [INFO][cache:0xc0006ee780] Stopped certificate maintenance routine
{"level":"info","ts":1598741417.0737278,"logger":"admin","msg":"stopped previous server"}
{"level":"info","ts":1598741417.0737565,"msg":"shutdown done","signal":"SIGINT"}

5. What I already tried:

I’ve been searching in the forum, the documentation for examples and documentation.

6. Links to relevant resources:

There’s been many significant changes since v2.0, I recommend upgrading to v2.1.1

I’m a bit confused - are those logs from your Caddy instance that is proxying or from the fastcgi one?

If it’s from the fastcgi one, my recommendation is to remove the domain from the site label and just use :8089 there, and reverse_proxy over http, not https.

Caddy will not be able to issue a certificate if ports 80 and 443 are not publicly accessible (which your wordpress fastcgi instance seems to not be), unless you use the ACME DNS challenge, which would be overkill in this situation I think.

But maybe I’m misunderstanding, the information isn’t perfectly clear to me.

1 Like

Thanks @francislavoie.

That solved the issue.

There was also another problem because wordpress was not applying the styles.
This was not an issue regarding caddy, at least directly, as it was happening with other reverse proxy and three other web servers.
Still, to whom it may be useful, since we’re dealing with https to http redirection and the problem was solved with a https config change, I got the solution from

SSL breaks wordpress CSS topic.

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