Peter Atkin's picture

I've been having some difficulty  SSL into tracks; I'm happy to buy an SSL or us Lets Encrypt, possible for a helping hand on that by pointing me to information that can help me.


Peter Atkin's picture


[2022-09-26 15:55:02] dehydrated-wrapper: INFO: started

[2022-09-26 15:55:09] dehydrated-wrapper: INFO: found apache2 listening on port 80

[2022-09-26 15:55:09] dehydrated-wrapper: INFO: stopping apache2

[2022-09-26 15:55:10] dehydrated-wrapper: INFO: running dehydrated

ERROR: Problem connecting to server (post for; curl returned with 28)              

[2022-09-26 16:00:26] dehydrated-wrapper: WARNING: Python is still listening on port 80

[2022-09-26 16:00:26] dehydrated-wrapper: INFO: attempting to kill add-water server

[2022-09-26 16:00:26] dehydrated-wrapper: WARNING: Something went wrong, restoring original cert, key and combined files.

[2022-09-26 16:00:26] dehydrated-wrapper: INFO: (Re)starting apache2

[2022-09-26 16:00:26] dehydrated-wrapper: INFO: (Re)starting stunnel4@shellinabox.service

Session closed.

Just minding my own business then a bug happenes.

Jeremy Davis's picture

It looks like your server is timing out trying to connect to Let's Encrypt servers:

ERROR: Problem connecting to server (post for; curl returned with 28)

Curl's error 28 is "timeout". I just tested that URL in my web browser and it looks like your certificate. So I'm assuming that your server correctly connected to the Let's Encrypt servers and passed the "challenge". But then for some reason, your server timed out trying to download the cert.

It may have been caused by intermittent network congestion. So, the first thing I would try is downloading that URL from the commandline of your server. I.e.:


If that works, then I suggest retrying getting a cert via Confconsole. If it doesn't work, then I'd recommend trying to work out what is blocking your network traffic. Assuming that you are running it as a VM, then please ensure that the host it's running on hasn't got any firewall or other network filtering enabled. If it does, temporarily disable it/them to test if that is the cause of issue. If you have something such as a hardware firewall or some sort of network proxy configured, please try disabling that temporarily too.

If you continue to have issues, please post back with more details, such as where (and on what) your server is running, what sort of network topography you have and any other details that may be relevant.

Peter Atkin's picture

Ran the command, but does not get (time out). We are using let's encrypt on other windows machines seems ok; to my knowledge, we only need ports 80 and 443 open, is that correct?

I'm using a default setup of Tracks GDT; everything works except the Let encrypt, is there a way to switch off the firewall, most commands I tried do not work; seems the firewall used is not vanilla, and my Linux knowledge is limited...

Sorry to be a pain but it seems I need some hand-holding here.

Just minding my own business then a bug happenes.

Jeremy Davis's picture

The failure you reported was a failure to connect to the Let's Encrypt servers. The fact that the command worked ok from the command line (and your reports that other servers are getting LE certs ok), suggests that there isn't a critical and/or consistent issue connecting from your network. It suggests that the problem was some intermittent networking issue, perhaps a brief internet outage, a network pathway through a failed packet routed the wrong way or perhaps just some network congestion?

For what it's worth, once you have it set up and have a cert, the automated cert updater can work around intermittent network outages.

If you haven't already, I suggest just retrying to get a cert. Assuming that you completed the config and everything is as it should be, rather than re-running through Confconsole, I suggest just running our wrapper script directly. I.e.:

/usr/lib/confconsole/plugins.d/Lets_Encrypt/dehydrated-wrapper --register --force

Hopefully, that should "just work". If not, please post the output back.

Beyond that, I'd be inclined to double check your resource usage. Root volume storage space is probably the most likely to cause issues. But perhaps an overloaded CPU caused the timeout (seems extremely unlikely to me, but perhaps?).

To check free space on your root volume:

df -h /

To check resource usage, install htop and run that. I.e.:

apt install -y htop


everything works except the Let encrypt

That may appear to be the case, but what you have shown so far appears to be a somewhat straight forward network failure. When your server was trying to download your certificate from Let's Encrypt, the download failed. I.e. the issue is almost certainly network related, rather than specific to TurnKey.

The fact that you aren't noticing any other issues suggests that it was either a "one off" network failure, or is at least a relatively minor intermittent issue (small enough that you mostly don't notice it). As I noted above, it could be that internet just dropped out briefly at the pivotal moment. The command that you tested running (which succeeded) was the same command that failed when trying to download your certificate. So it's clearly not an acute issue.

is there a way to switch off the firewall, most commands I tried do not work

The built in firewall is configured, but not enabled by default. So unless you enabled it, it's already disabled. FYI we use iptables, which is fairly standard Linux firewall. Actually under the hood it's the newer default; nftables, but we have the "iptables compatibility mode" enabled, so it acts like the legacy iptables.

When I was speaking of firewalls or proxies, I was more referring to the possibility of a network firewall or internet connection via a proxy. I.e. something external to your TurnKey server, perhaps a firewall on the host if it's a VM.

So to summarize, I suggest re-running the dehydrated wrapper script. If it still fails, please share the output.

Add new comment