Chris Whorton's picture

Not sure how to fix the SSL for TK Wordpress or Bullseye (17.1).

Not a great linux guy to figure this one out, but if i had a little help, it would be greatly appreciated.

Getting Fatal error also with dehydrated-wrapper. Exited with non-zero exit code.


We have briefly opened the firewall to the site with the correct DNS and tested connection from outside.

Opened confconsole and added (listed in DNS) and ran the script.

Fatal Error.

Thank you for the help.

Jeremy Davis's picture

Hi Chris, it's probably best to start a new thread.

FWIW, in my experience, the issue is usually either slow DNS propagation (i.e. your domain isn't yet mapped to your server) or lack of access to port 80. However, it's also worth noting that if either of those things occur too many times, you will be blocked from accessing the Let's Encrypt ACME server. Once that happens, even if the real issue is resolved, it will continue to fail - until the blockage times out (TBH, I'm not sure how long your domain is blacklisted for?).

If you are willing to share the real domain name and IP address then I can check from my end.

Please try running this command (as root):

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

Once that has completed (will likely fail again I imagine). Then either copy/paste or attach the log file (/var/log/confconsole/letsencrypt.log) to your post. Please note that only the first post in a thread can have attachments - please let me know if you've done that though as it's not actually displayed (website bug).

Chris Whorton's picture

Thanks for reaching out.

Opened up the internal server to internet and ran the command. is listed below.

Closed it back up after running it.

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

[2023-08-09 14:09:24] dehydrated-wrapper: INFO: started
# INFO: Using main config file /etc/dehydrated/confconsole.config
+ Account already registered!
[2023-08-09 14:09:25] dehydrated-wrapper: INFO: found apache2 listening on port 80
[2023-08-09 14:09:25] dehydrated-wrapper: INFO: stopping apache2
[2023-08-09 14:09:27] dehydrated-wrapper: INFO: running dehydrated
# INFO: Using main config file /etc/dehydrated/confconsole.config
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 1 authorizations URLs from the CA
 + Handling authorization for
 + 1 pending challenge(s)
 + Deploying challenge tokens...
[2023-08-09 14:09:30] INFO: Deploying challenge for
[2023-08-09 14:09:30] INFO: Serving /var/lib/dehydrated/acme-challenges/PLstdrbwr0lMVFDAx-XON0KI2p8mfvjepPb4iztVTWI on
 + Responding to challenge for authorization...
 + Cleaning challenge tokens...
[2023-08-09 14:09:42] INFO: Clean challenge for
 + Challenge validation has failed :(
ERROR: Challenge is invalid! (returned: invalid) (result: ["type"]      "http-01"
["status"]      "invalid"
["error","type"]        "urn:ietf:params:acme:error:connection"
["error","detail"]      " Fetching Timeout during connect (likely firewall problem)"
["error","status"]      400
["error"]       {"type":"urn:ietf:params:acme:error:connection","detail":" Fetching Timeout during connect (likely firewall problem)","status":400}
["url"] ""
["token"]       "PLstdrbwr0lMVFDAx-XON0KI2p8mfvjepPb4iztVTWI"
["validationRecord",0,"url"]    ""
["validationRecord",0,"hostname"]       ""
["validationRecord",0,"port"]   "80"
["validationRecord",0,"addressesResolved",0]    ""
["validationRecord",0,"addressesResolved"]      [""]
["validationRecord",0,"addressUsed"]    ""
["validationRecord",0]  {"url":"","hostname":"","port":"80","addressesResolved":[""],"addressUsed":""}
["validationRecord"]    [{"url":"","hostname":"","port":"80","addressesResolved":[""],"addressUsed":""}]
["validated"]   "2023-08-09T14:09:31Z")
[2023-08-09 14:09:43] dehydrated-wrapper: FATAL: dehydrated exited with a non-zero exit code.
[2023-08-09 14:09:43] dehydrated-wrapper: WARNING: Python is still listening on port 80
[2023-08-09 14:09:43] dehydrated-wrapper: INFO: attempting to kill add-water server
[2023-08-09 14:09:43] dehydrated-wrapper: WARNING: Something went wrong, restoring original cert, key and combined files.
[2023-08-09 14:09:43] dehydrated-wrapper: INFO: (Re)starting apache2
[2023-08-09 14:09:43] dehydrated-wrapper: INFO: (Re)starting stunnel4@webmin.service
[2023-08-09 14:09:43] dehydrated-wrapper: INFO: (Re)starting stunnel4@shellinabox.service
[2023-08-09 14:09:43] dehydrated-wrapper: WARNING: Check today's previous log entries for details of error.
Jeremy Davis's picture

Firstly, as you've probably noticed, I moved your posts to a new thread.

Thanks for providing the log. Your log suggests that everything is working ok, but the Let's Encrypt servers can't contact your server for some reason. Note this line in your log:

["error","detail"]      " Fetching Timeout during connect (likely firewall problem)"

Assuming that is your public IP (or at least was at the time if it's dynamic) then DNS propagation issues can be ruled out.

Your log suggests that everything else went ok, until Let's Encrypt tried to access your server. Instead of accessing the challenge being served, it got a 400 if you google "let's encrypt 400" you'll find masses of threads detailing the issue. As noted in the hint, it is almost certainly an issue contacting your server.

To check your firewall, first open port 80 and use a remote port scanner to check that the port is externally accessible. I'm sure there are other options, but the one I usually use is Shields Up. I usually just run the test for "Common ports" (which will include port 80) - but you can explicitly probe just port 80 if you want.

If the firewall is letting the traffic through, then it will report that port 80 is either "open" (if something behind it is responding on port 80) or "closed" (if the port is "open" but nothing behind it is listening). If it reports "stealth", then there is something still blocking port 80 on your connection. I'd check with your ISP as a starting point (often common ports are blocked by ISPs to reduce malicious stuff propagating online).

If that reports 80 is "open", then move onto the next step. If it reports "closed", then ensure that the traffic is being redirected to your server (perhaps need to enable port forwarding?). Once the port scan reports port 80 as "open", your ready to move on.

Once the port is reporting as "open", that means that there is a response coming from your server (hopefully - or something at least). By default, our WordPress appliance serves via port 80 but a common config is to auto redirect port 80 to 443. You need to explicitly connect to port 80, so unless you have access to a remote shell that you can use to probe your sever, if you have a redirect like that configured, it's probably worth temporarily disabling it (note that an auto redirect like that won't have any impact on getting certs as Apache isn't used to server the challenge).

Then try to connect to your server.

If you have access to a remote server, just use curl (on the remote server). Even if there is a redirect, that isn't an issue. E.g. testing port 80 on the TurnKey webserver:

user@ninjux ~$ curl
<title>302 Found</title>
<p>The document has moved <a href="">here</a>.</p>

As noted in that response, it's redirecting to port 443, but that confirms that it's connecting to port 80 as desired.

If you don't have access to a remote shell, then you can use a smartphone (or other device that has internet access via cell). Be sure to disable wifi so you are definitely checking from outside your LAN (i.e. there is no risk that your gateway is doing any funky redirects and giving false info). You should be able to view your site publicly - via port 80 (double check in your browser that it's not https/port 443).

A completely different path to achieve your ends would be to use DNS-01 validation, rather than HTTP-01 validation. DNS-01 validation provides challenges via DNS records, rather than serving them via port 80. Assuming that your server isn't public (and your DNS provider is supported by lexicon) then that may be a preferable way to get a cert? (no public access via port 80 required).

DNS validation isn't available via default Confconsole in v17.x (it will be in v18.x - but that's not yet released) but you can download a slightly newer Confconsole version (v2.0.6) from GitHub or just download the deb directly on your server (then install) like this:

apt install ./confconsole_2.0.6_all.deb

Unfortunately, it's not (yet) well documented, but I have tested it and it works. It leverages lexicon to interact with your DNS provider (hopefully yours is listed/supported?!).

If you do update confconsole, to be sure you are starting with a clean slate, I suggest cleaning your existing config before you continue:

rm /etc/dehydrated/confconsole*

On first run, any missing files will be replaced with the updated ones (you will need to re-enter your domain).

Hopefully that is of some value. If you want more pointers or have more questions, please post back and I'll reply ASAP.

Chris Whorton's picture

ran the rm command

installed the new confconsole.

ran the confconsole... I dont know what these mean.

I am very thankful for you help.


~# confconsole
Traceback (most recent call last):
  File "/usr/bin/confconsole", line 739, in <module>
  File "/usr/bin/confconsole", line 712, in main
    pm = plugin.PluginManager(PLUGIN_PATH,
  File "/usr/lib/confconsole/", line 183, in __init__
    current_plugin = Plugin(file_path, module_globals)
  File "/usr/lib/confconsole/", line 78, in __init__
    self.module = imp.load_module(self.module_name, module_fob,
  File "/usr/lib/python3.9/", line 234, in load_module
    return load_source(name, filename, file)
  File "/usr/lib/python3.9/", line 171, in load_source
    module = _load(spec)
  File "<frozen importlib._bootstrap>", line 711, in _load
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/usr/lib/confconsole/plugins.d/Lets_Encrypt/", line 11, in <module>
    import dns_01
ModuleNotFoundError: No module named 'dns_01'


Jeremy Davis's picture

Argh! It looks like there is something wrong with the package!?

TBH I'm not sure why, as the file definitely appears to exist!? I.e.:

root@core ~# ls /usr/lib/confconsole/plugins.d/Lets_Encrypt/

Regardless, I have confirmed the issue and just rebuilt the package from the current latest code (that we're working on for the upcoming v18.0 release).

You can download it from GitHub like this (same as before, just different filename):

apt install ./confconsole_2.1.0+3+gf70719e_all.deb

You don't need to remove the config files again.

I didn't test it exhaustively, but it should work now (I double checked by installing it and it definitely runs on my v17.2 system).

My apologies... Hopefully it works for you this time...

Chris Whorton's picture

Excellent! That worked! Thank you! Thank you!

Hannes Brandstätter-Müller's picture

I had a similar problem, here's what I had to do to fix it: based on TKL 17, with confconsole_2.1.0+3+gf70719e_all.deb installed configure the settings for my dns provider in /usr/share/confconsole/letsencrypt/lexicon.yml like:
  auth_access_secret: XXXXXXXXXXXXXX
  auth_access_key: YYYYYYYYYY
  private_zone: False
change /usr/lib/confconsole/plugins.d/Lets_Encrypt/
import importlib.util
and replace the line loading the dns_01 module with
dns_01_spec = importlib.util.spec_from_file_location('dns_01', '/usr/lib/confconsole/plugins.d/Lets_Encrypt/')
dns_01 = importlib.util.module_from_spec(dns_01_spec)
sys.modules["dns_01"] = dns_01
apt install python3-venv
python3 -m venv /usr/local/src/venv/lexicon
source /usr/local/src/venv/lexicon/bin/activate
pip install dns-lexicon[route53]
and then finally from the still activated venv
hope it might help someone else
Jeremy Davis's picture

Thanks for posting with your workaround.

FWIW I'm sure that I've finally fixed it properly (I know I've said that before, but for real this time!). It was a silly mistake on my part. (See explanation here if you're interested).

After a little more testing, I did make some other tweaks - so users who hit the same issue can just install the newer version and it work - without any manual intervention required.

I plan to rebuild Confconsole and push a fixed version to our repos ASAP, probably tomorrow. All new appliances should automatically include the fix and anyone else who comes across this should be able to just install the fixed version and it should "just work"

Add new comment