I have two WordPress site that is in Docker containers and a Caddy server in docker that will serve as the reverse proxy for them but I don’t get a TLS certificate for the servers.
The Wordpress Docker img that is used is the wordpress:php7.2
And for Caddy i use abiosoft/caddy:latest
Looks like the issue you’re running into is happening well before anything involves the WordPress containers. It’s a LetsEncrypt validation problem.
Specifically, when LetsEncrypt is trying to connect to http://firstdomain.org/, it’s getting the wrong response. Typically, this happens when there’s a different web server listening at this address. LetsEncrypt needs to connect to Caddy itself when they make a request to the domain you’re getting HTTPS for, or the validation won’t work.
So the first port of call is to make sure that the server publicly accessible at http://firstdomain.org/ does actually have Caddy listening on port 80.
Using the Staging environment is great! It’s there for this exact purpose - testing to make sure all the required configurations are set properly, networking-wise etc etc.
It should not be any other webservers before Caddy and Caddy is the only webserver that is listening on port 80 and 443 to the outside world. But on the internal network (Docker Network) Wordpress does listen to port 80 but only from internal request directed right at it its local ip
I uses this command command to start the Caddy server
Hmm. Try running caddy -host focusongaming.no -ca https://acme-staging-v02.api.letsencrypt.org/directory "status 200 /" directly on the host, with the Docker container down, and see if that goes anywhere?
On the host directly. Make sure the abiosoft/caddy container isn’t running and binding 80 and 443, then run that command.
It’ll run Caddy directly on the host and try to obtain the certificate. It’ll have no configuration other than to send Status 200 for any request for that hostname. It’s about as simplified as we get - just trying to rule out as many variables as possible in one go.
So installed Caddy on the host using curl https://getcaddy.com | bash -s personal and then shutdown the docker containers,
but Still the same problem happens.
2018/10/20 17:26:56 [focusongaming.no] failed to get certificate: acme: Error 403 - urn:ietf:params:acme:error:unauthorized - Invalid response from http://focusongaming.no/.well-known/acme-challenge/F9ILWNna7LQrpH9R86itMRdmcnWSOI0d4_YravvMD6Y: "<!DOCTYPE html>\n\n<html lang=\"en-US\" prefix=\"og: http://ogp.me/ns#\">\n\n\t<head>\n\t\t\n\t\t<meta charset=\"UTF-8\">\n\t\t<meta name=\"viewport\""
That’s the top of an HTML document. Probably an index page of some kind. Notably it implements Open Graph protocol. The really weird part is that Caddy shouldn’t be returning that at all, for a few reasons.
Firstly, it’s a /.well-known request, and Caddy should be returning the ACME challenge response! Secondly, with no HTML in the site root, and no browse directive - Caddy should simply be returning an empty body with a Status 200, per the "status 200 /" directive on the command! Very strange.
What result do you get from running curl -IL http://focusongaming.no/ on the host machine’s command line?
Whatever LetsEncrypt is talking to, it really doesn’t seem to be your server. Has the DNS changed recently? Usually LetsEncrypt is very fast to update their DNS when it changes, but who knows…
curl: (7) Failed to connect to focusongaming.no port 80: Connection refused
The domain did point to my old web server for around three weeks ago but that server should be down, and I changed the DNS at my provider at least two weeks ago to this new server.
Could it be that LE is somehow still talking to that server or something?
Once it’s up and running (it’ll just serve HTTP, won’t try to involve LetsEncrypt), we’ll try curl -i http://focusongaming.no/" again and see what we get. We want to see Status 200 and no body.
If we do get what we’re expecting, we can be pretty sure that LetsEncrypt is doing weird stuff right now.
$ caddy -host http://focusongaming.no "status 200 /"
Activating privacy features... done.
http://focusongaming.no:2015
WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with "ulimit -n 8192".
On both my computer and on the host I get
$ curl -i "http://focusongaming.no/"
curl: (7) Failed to connect to focusongaming.no port 80: Connection refused
But if I try the same with the port number 2015 it outputs
$ curl -i "http://focusongaming.no:2015"
HTTP/1.1 200 OK
Server: Caddy
Date: Sat, 20 Oct 2018 15:56:58 GMT
Content-Length: 0
Ahh, yeah, my mistake… Might need a Caddyfile, actually. Just throw this in the directory you run the caddy command from, and then run it without any flags or parameters this time:
http://focusongaming.no
status 200 /
Just wanna make 100% sure that port 80 at that address has Caddy responding.
That was the response we want to see, though. I’m pretty sure we can point the finger at LetsEncrypt. Next step might be to try pointing a different domain name at your server and trying with that.
Yep, just got the same from my end just now, so LE definitely aren’t connecting to the right server for HTTP validation. I think this is the first time I’ve seen them get it wrong quite like this, to be honest.