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": [
"85.3.126.93"
],
"addressUsed": "85.3.126.93"
}
]
},
(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)