Certbot-auto urn:acme:error:connection 400


Some additional info before the form: This is a weird issue I haven’t run into before. I’m using Let’s Encrypt (specifically certbot) without any problems on my hosted servers and private NAS and haven’t had too many problems before. However, this case is a bit special, I am assuming it is related to the rather uncommon DNS chain.

The server in this case is a Raspberry Pi located at a club house that needed a cheap solution to proxy a stream from their local network via HTTPS. Due to this, the DNS record looks as following:
***.ch --CNAME--> ***.dyndns.org --A--> <ip>

  • Port 80 and 443 are open and redirected to the device
  • Both domains resolve to the correct IP successfully
  • According to verbose logging, LE managed to resolve the domain correctly (see below)
  • There is no attempted connections in nginx’s access or error logs

My domain is: ***
I ran this command: certbot-auto renew (also with --text -vv, see below)
It produced this output: urn:acme:error:connection :: The server could not connect to the client to verify the domain
My operating system is (include version): Linux 4.4.38-v7+ armv7l (raspbian)
My web server is (include version): nginx/1.6.2
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

This is the payload received from LE for the http-01 challenge status:

      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:acme:error:connection",
        "detail": "Could not connect to ***",
        "status": 400
      "validationRecord": [
          "url": "http://***/.well-known/acme-challenge/eRahJZH9jQoWQoYVaI5Hl2lDedq_sHpAfFeS11JeB1A",
          "hostname": "***",
          "port": "80",
          "addressesResolved": [
          "addressUsed": ""

(Edit: I removed the actual domain from the post, since the site is rather unknown and LE community will probably be ranked higher by search engines)


Strange indeed, I’m getting a 404 file not found error when requesting the challenge (from The Netherlands, perhaps it has something to do with global distribution of LE’s servers…?). That’s not surprising, as the challenge is probably gone indeed. At least I’m able to connect!


I’m using certbot-auto, as far as I know, that always cleans up after itself when it exits, so accessing the challenge resource now will yield 404, yes.
The challenge itself is still valid and checkable via LE’s servers here


Pardon me, I will go bang my head on the desk for the next half an hour.
I lazily used an older script that actually stops nginx before renewal, which obviously doesn’t comply with how the http-01 challenge is designed to work…

Thanks anyways :smiley:


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