mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-13 15:13:33 +01:00
new-acct curl returned with 52 #453
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @reetp on GitHub (Dec 16, 2019).
Suddenly found one of my CentOS 6 boxes had failed to renew certificates.
Long story short after testing various things I updated to latest dehydrated just for good measure, have tested with both normal and test API servers and continue to get this error:
Problem connecting to server (post for https://acme-staging-v02.api.letsencrypt.org/acme/new-acct; curl returned with 52)
Cleared accounts and certs etc etc and cannot get past this.
Debugging in Bash:
++++ curl -A 'dehydrated/0.6.5 curl/7.19.7' -s -w '%{http_code}' -o /tmp/dehydrated-vsit5B https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce -I
+++ statuscode=200
Then
+++curl -A 'dehydrated/0.6.5 curl/7.19.7' -s -w '%{http_code}' -o /tmp/dehydrated-Cjkjac https://acme-staging-v02.api.letsencrypt.org/acme/new-acct -D /tmp/dehydrated-MDnYMO -H 'Content-Type: application/jose+json' -d '{"protected": "ey........."}"
++ statuscode=100
++ curlret=52
As far as I am aware nothing had changed on the server or anywhere else.
Config is really simple - just custom WellKnown that is accessible, CA and Accept Terms
I have several other near identical boxes in several locations and none of them are experiencing this. I did wonder if it had any relationship to 684 but from the bash debug it looks like it gets past the new-nonce URL.
Completely perplexed so any advice gratefully received.
@lukas2511 commented on GitHub (Dec 16, 2019):
Does this box have the same network configuration as your other boxes?
From the fact that curl actually saw a "100 Continue" message and after that no more content (52: Empty reply from server) I'm assuming that somehow the connections gets interrupted at that point, which I often observe on connections with mismatching MTUs, misconfigured firewalls or IPs conflicting between hosts.
I'm closing this as this is definitively not a dehydrated bug. Still interested in what's going on here.
@reetp commented on GitHub (Dec 16, 2019):
Thanks for looking...
Essentially yes - I have one that, bar the internal & external IPs, is identical AFAIAA.
Proxmox hosted Server (-> pi-hole DNS) -> Endian -> wide world
Endian port forwards 80 & 443 to the box which only has an internal IP.
Proxmox has no firewalling enabled. Server itself has iptables disabled (had been enabled but stopped for testing)
That was my understanding too, but try as I might I cannot see where that is happening so was after any help in debugging it. It's the ONLY box I have ever had an issue with. Been using your script for a long time, and even wrote a package to make it easy to configure/use on our Koozali SME server.
Indeed. I have no reason to specifically think it is dehydrated, but I have no idea what else it could actually be, and there is no real 'support' forum for dehydrated and associated issues.
This box was using v 0.6.2 and AFAICT had been working perfectly until 15th Dec when the last cert expired, but presumably there was a failure at the renew point that was missed but I am not sure how long ago that was to see what might have changed - presumably around 30 days. I still can't think of anything that would affect it though.
I have tried upgrading to 0.6.5, remove all accounts & certs and start afresh, revert accounts & certs and go back to the v1 server to renew, and still nothing!
V1 gives this on renew:
curl -A 'dehydrated/0.6.5 curl/7.19.7' -s -w '%{http_code}' -o /tmp/dehydrated-vPcGSm https://acme-v01.api.letsencrypt.org/acme/new-authz -D /tmp/dehydrated-tltbGL -H 'Content-Type: application/jose+json
ERROR: Problem connecting to server (post for https://acme-v01.api.letsencrypt.org/acme/new-authz; curl returned with 52)
So basically the same issue with a different endpoint. Very puzzling and no idea what to test.
@lukas2511 commented on GitHub (Dec 16, 2019):
Mh you should be using acme-v02, I think acme-v01 stopped accepting new registrations, so that might be another issue. But if it doesn't work with a completely fresh installation and it works from a different system on the same network I have absolutely no clue on what's happening here. You could maybe trace it using wireshark, maybe there is something obvious like a tcp reset out of nowhere.
@reetp commented on GitHub (Dec 17, 2019):
v1 & v2 yes - I am aware of that - I have tried both renewing v1, and creating a new v2 and both failed :-(
OK, I think we might have got it working, and fixed another issue that we had very occasionally on certain sites not always loading correctly - we thought it might have been CDN or other issues and could never pin it down specifically as it was not consistent.
Bit lengthy but it may help others. It is fairly obscure..... and to do with the way that ISPs can handle supposedly 'static' IPs.
I have two static IPs with my ISP. However, according to them they are really dynamic addresses that are kept for your login. That means the gateways shift because I presume there is some network shenanigans behind the scenes....
So I think when I set some of this up I made some assumptions that then changed without realising.
2 Draytek ADSL routers get the WAN details via DHCP
81.136.x.x gateway 81.139.128.1 (PPPoA)
213.123.x.x gateway 81.148.160.1 (PPPoE)
Those routers are in a kind of half bridge mode (Draytek 'Active True IP') back to an Endian WAN gateway router.
This replaced an old Draytel 3300 WAN router which if I remember correctly you set to DHCP and it automagically picked up the correct settings from the Draytek ADSL routers. I forget now, but it was never an issue.
But the Endian wanted the IP, gateway, and subnet mask specifically. DHCP only picks up the ADSL routers REAL internal Lan IP address, not the WAN address.
I think what happened was the subnet for each was originally set to 255.255.255.0 and the gateway IPs set to 81.136.x.1 and 213.123.x.1 respectively because as you can see above, the gateway for the 213 address is really some internal hack by the ISP and you can't use a subnet mask properly - the IP and gateway are meant to be on the same subnet.
So I swapped the 81.136 address to use a subnet mask of 255.252.0.0 to match the current gateway (I have a feeling this was the original setting given to me like 10 years back when we got the line & IP but the ISP denies all knowledge of it) with the current correct gateway and everything suddenly seems to be OK including dehydrated. Odd that the previous settings work for most stuff, but not all. (I saw the gateway IP change when I test rebooted the ADL Router which is what started me off)
As yet I have no idea what to set as a subnet mask for the 213.123 address.... however, that really only runs VPNs and never seems to have an issue.
I presume a lot of this is internal network juggling with the shortage of IPv4 addresses. But currently the ISP is not offering IPv6.... go figure !!!!!
So the upshot is check your network settings really carefully, especially in these days of lack of IPv4s and ISPs playing crazy games rather than getting on with issuing IPv6 addresses.