ACME Error 400 while generating certificate

[Jeff_Tan_Han_Wei]

Hello there.

I’ve been using Caddy for months now (without trouble). But today I had to switch my domain name, and I got in trouble halfway with the Automatic HTTPS.

This is my Caddyfile:

mydomainnothingelse.com {    
    # empty
}

I ran the command caddy (without any parameters). After a few seconds, it returns this:

Activating privacy features... 2018/12/17 12:50:55 [mydomainnothingelse.com] failed to get certificate: acme:         Error 400 - urn:ietf:params:acme:error:connection - Fetching http://mydomainnothingelse.com/.well-    known/acme-challenge/9ywCsG5SinZc3CiJfxx9UnwBPF1iVSqR-W0XMZl6TFw: Error getting validation data

I made sure to forward port 80 and 443 from the outside to my internal ip address (192.168.0.113) and point it to port 80 and 443 (again). I’ve also ran setcap to make sure caddy can bind to port 80 and 443, but I’m not sure I did it the right way… sudo setcap cap_net_bind_service=+ep /usr/local/bin/caddy.

I’m so desperate to the point that I ran ulimit -u 8192 /usr/local/bin/caddy (which is normally not needed).

What happened? Every help is appreciated. Thanks!

[magikstm]

Recheck these:

• That port 80 and 443 are open externally on the server and not used by another process
• That your A and AAAA record for the domain are setup correctly

[Jeff_Tan_Han_Wei]

Hi,

Thank you for your reply!

Yes, port 80 and 443 is currently open and I’ve also pointed the domain to my IP address.

[Whitestrake (Matthew Fay)]

Hi @Jeff_Tan_Han_Wei,

Next thing to check is that Caddy is properly accessible via your external IP address.

Try adding tls self_signed to the site configuration for your domain name and bring up Caddy again. It should launch without trying to request any certificates.

When that’s done, run this in a shell:

curl -kIL example.com

(replacing example.com with your domain name as appropriate)

The response will give us an idea of what LetsEncrypt might be seeing when it tries to initiate an ACME challenge.

[Jeff_Tan_Han_Wei]

Hi, thanks for your reply.

I managed to successfully implement the self-signed certificate and ran curl -kIL mydomainnothingelse.com. It returned:
curl: (8) Weird server reply
Any ideas what’s this? Thanks!

[Whitestrake (Matthew Fay)]

Huh. Wasn’t expecting that.

Try curl -vkIL example.com instead (adding the v flag, for verbose output). Might give us a better idea of what the “weird server reply” is.

The one thing we can infer from this is that it’s clearly not an open path from your external IP to Caddy; something along the way is misbehaving.

[Jeff_Tan_Han_Wei]

Hi again.

I ran curl -vkIL mydomainnothingelse.com. Return value:

* Rebuilt URL to: mydomainnothingelse.com:2015/
*   Trying 161.142.33.137...
* TCP_NODELAY set
* Connected to mydomainnothingelse.com (123.456.789) port 2015 (#0)
> HEAD / HTTP/1.1
> Host: mydomainnothingelse.com:2015
> User-Agent: curl/7.61.1
> Accept: */*
> 
* Closing connection 0
curl: (8) Weird server reply

Thanks for your time

[Whitestrake (Matthew Fay)]

Looks like it wasn’t a “weird server reply” so much as “the server said nothing at all and then closed the connection”.

Just to confirm, try this (again substituting your own domain name for example.com):

curl -kIL -H "Host:example.com" 192.168.0.113

We want to see a good Caddy response from this; we’re testing how it responds to a request for your domain name, we’re just connecting directly to it locally instead of resolving it through the external IP.

[Jeff_Tan_Han_Wei]

Hi,

Just to add to the frustuation, the command returned the same “weird server reply”. Thanks for your help anyways. I’ll try to resolve the problem myself. Maybe I missed something.

Thanks.

[Whitestrake (Matthew Fay)]

@Jeff_Tan_Han_Wei

the command returned the same “weird server reply”

Did it do this immediately, or on the second response?

I realised after I posted that the more correct way of doing what I intended was this:

curl -kIL example.com --resolve 'example.com:80:192.168.0.113' --resolve 'example.com:443:192.168.0.113'

(doing it as above might have had it work for HTTP, redirected to the new location, which would have gone via external for HTTPS)

But if it gave you a weird server reply off the bat, it could be that the host in question (192.168.0.113) has a rogue firewall or some other issue meaning that Caddy isn’t listening on the expected ports.

[Jeff_Tan_Han_Wei]

Hi, (and sorry for being inactive for such a long time)

Thanks for all your effort and time. Long story short, I got so frustruated (I worked on this problem for about 9 hours) I decided to do the unprofessional thing and reset my router. It worked and it let me pass. No idea why.

One big problem right now: whenever I decide to write root index.html (or just try root …), the browser gives me this error:

Now does anybody have an idea

Thanks once again @Whitestrake @magikstm

BTW @Whitestrake I see you around the forum very often. Almost every topic. Wow.

[Whitestrake (Matthew Fay)]

No worries, I like to help!

Double check the root doc: https://caddyserver.com/docs/root

The expected usage is that you designate the directory containing index.html rather than the file itself.

I also recommend you use an absolute path for it wherever possible, so that the ambiguity of relative paths doesn’t come back to bite you in unexpected ways.

If you don’t specify a root at all, Caddy will assume the web root to be the present working directory (i.e. the directory you were in when you launched Caddy).

[Jeff_Tan_Han_Wei]

Thanks! It solved my problem. I didn’t know that I needed to designate the directory instead of just a html folder. TIL.

Thank you for being so helpful

Have a good day.