Acme: error: 400

(Wouter Verduin) #1

Hi all! Im afraid i need some help but let me show you the things i am having troubles with:

Target: Run caddy to reverse proxy, and to different local servers/services.

Background: Pfsense server, ubuntu VM running the services (say At this time i got my pfesnse forwarding port 80 and 443 to port 81 and 444 (to keep my primary services online while i figure this out, attached to the I link my to that still running service, bound to that domain only locally running on 81/444 to keep 80 and 443 open to test caddy.

Problem: Setting up Caddy using this tutorial. Error displayed on my terminal (after typing: sudo caddy -host :

2019/05/30 16:02:26 [INFO] [] acme: Trying to solve TLS-ALPN-01
2019/05/30 16:02:40 [INFO] Unable to deactivated authorizations:
2019/05/30 16:02:40 [] failed to obtain certificate: acme: Error -> One or more domains had a problem:
[] acme: error: 400 :: urn:ietf:params:acme:error:connection :: Timeout during connect (likely firewall problem), url:

What i tried so far:

  • Another brand new VM of ubuntu 18 LTS; same error
  • Different domain name i have
  • tested openness of ports ( nc -zw3 80 && echo “opened” || echo “closed” aswell for 443, both showing opened).
  • Double checked my is pointed towards my external IP

How can i resolve this?! Kinda at despair at this moment. Is this because i already binded to my nextcloud snap (which is still working now on ports 81 & 444?

Any help would be really appreciated! Thanks in advance :slight_smile:

(Matthew Fay) #2

Hi @Wouter_Verduin,

From a quick test, it looks like is currently served by Apache server. Doesn’t explain why LetsEncrypt got a timeout, though, I connected just fine. You’d need make sure your edge router is forwarding packets to the Caddy host.

1 Like
(Wouter Verduin) #3

@Whitestrake Thanks for your reply! is not really the domain im attempting to use and besides; after i am doing testing/configuring i reroute the ports to my nextcloud instance to keep it in the air in the meantime i am trying to figure this out.

It still bugs me i cant get this working. Ports 80 and 443 are perfectly open for my nextcloud instance (when forwarded to 81 and 444 for nextcloud) but when i switch them to forward to 80/443; caddy gets the acme 400 error…

Really appreciate any ideas to resolve this!

(Matthew Fay) #4

No worries. Try to avoid using other people’s domain names, it just confuses the issue.

We’re going to assume that DNS is set correctly because you can reach your Nextcloud instance when you swap back to that.

Take LetsEncrypt out of the situation and test directly to make sure that Caddy is responding on the right ports when you’re forwarding to it.

Point your port forwards to Caddy again, then run it on port 80 and do a simple test.

caddy -host -port 80 "status 200 /"

Then run curl -I and look for Server: Caddy.

Assuming that works, we’ll repeat with 443:

caddy -host -port 443 "tls self_signed" "status 200 /"

And then curl -I, looking for a similar response.

If you can, run those curl commands from a host outside of your network, such as via phone hotspot.

(Wouter Verduin) #5


Again, thanks alot!

Curl results:
HTTP/1.1 200 OK
Server: Caddy
Date: Sat, 01 Jun 2019 11:19:59 GMT

And for port 443:
curl: (52) Empty reply from server

Ran them from my internal network; i dont know how to use that command on my android phone.

Another notable thing is that i have a pfsense router. Got DNS rebind checks disabled since i’ve read somewhere that this might cause issues. My DNS servers are and But as you say, it works fine if i forward to port 444 and 81 to keep my nextcloud alive.
Today i also checked if i can receive some certificates through the acme package, worked without a problem.

Hopefully you have some other leads! :slight_smile:

NB: I got to say: With your suggestion i realised to check if port 80 wasnt bound/used by another program. Found nginx running so purged that since i dont use it. Still no succes after this though.

(Matthew Fay) #6

Whatever port 443 is forwarded to, it’s not reaching Caddy (assuming you ran Caddy properly on port 443 for this test).

Caddy, via acme-go/lego, will always attempt to validate via TLS-ALPN challenges, which happen over 443. I’d wager if you ran Caddy with the -disable-tls-alpn-challenge flag, which causes it to fall back to the HTTP challenge on port 80 (which you’ve tested as working), Caddy would successfully requisition a certificate… But you probably still wouldn’t be able to access the HTTPS page.

(Wouter Verduin) #7


Also tested with -disable-tls-alpn-challenge; still same error.

I also attempted to run it with a clean ubuntu 18LTS VM and ran in the same errors. Are there more ways to troubleshoot this problem?

Are there possibly other firewall settings i need to look for besides port forwarding? specific DNS settings to allow/disable?

(Matthew Fay) #8

I’m honestly stumped, that seems almost impossible. If you can get:

from a cURL from an external network, that’s everything Caddy needs to solve a HTTP challenge right there. We’re talking about a basic HTTP request, working fine, that’s essentially the entire mechanism LetsEncrypt uses.

There are no DNS settings to consider. Not even Cloudflare’s MITM interferes with a HTTP challenge. There just needs to be an A record at the end of the line that points to your host.

Getting a working HTTP response when cURLing your domain, but having LetsEncrypt time out, would require that your system is somehow interfering specifically with requests from LetsEncrypt IPs.

(Wouter Verduin) #9

@Whitestrake I dont know why or how but i figured it out.

I reinstalled my pfsense and with the very most basic things i tested and it worked and retrieved certificates.

Unfortunatly i ran in something different i hope you can help me with. This was the output after the new try:

Activating privacy features… 2019/06/03 10:35:34 [INFO] [] acme: Obtaining bundled SAN certificate
2019/06/03 10:35:35 [INFO] [] AuthURL:
2019/06/03 10:35:35 [INFO] [] acme: use tls-alpn-01 solver
2019/06/03 10:35:35 [INFO] [] acme: Trying to solve TLS-ALPN-01
2019/06/03 10:35:41 [INFO] [] The server validated our request
2019/06/03 10:35:41 [INFO] [] acme: Validations succeeded; requesting certificates
2019/06/03 10:35:42 [INFO] [] Server responded with a certificate.
2019/06/03 10:35:43 Listen: listen tcp :443: bind: address already in use

After that i ran:
sudo netstat -plnt | grep ‘:443’ with the result:
tcp6 0 0 :::443 :::* LISTEN 23880/caddy

Seems caddy is blocking the binding of the port now! :slight_smile: Is there a way to disable this? I think after that i will be all set!

(Matthew Fay) #10

Yeah. pkill caddy to get rid of the currently blocking instance and then start it again.