You are here
Chris Whorton - Tue, 2023/08/08 - 23:18
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 webservername.domain.com (listed in DNS) and ran the script.
Fatal Error.
Thank you for the help.
Forum:
Tags:
Hi Chris
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):
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).
Logs for SSL
Thanks for reaching out.
Opened up the internal server to internet and ran the command.
intranet.whortonins.com 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 Processing intranet.whortonins.com + Signing domains... + Generating private key... + Generating signing request... + Requesting new certificate order from CA... + Received 1 authorizations URLs from the CA + Handling authorization for intranet.whortonins.com + 1 pending challenge(s) + Deploying challenge tokens... [2023-08-09 14:09:30] confconsole.hook.sh: INFO: Deploying challenge for intranet.whortonins.com [2023-08-09 14:09:30] confconsole.hook.sh: INFO: Serving /var/lib/dehydrated/acme-challenges/PLstdrbwr0lMVFDAx-XON0KI2p8mfvjepPb4iztVTWI on http://intranet.whortonins.com/.well-known/acme-challenge/PLstdrbwr0lMVFDAx-XON0KI2p8mfvjepPb4iztVTWI + Responding to challenge for intranet.whortonins.com authorization... + Cleaning challenge tokens... [2023-08-09 14:09:42] confconsole.hook.sh: INFO: Clean challenge for intranet.whortonins.com + 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"] "71.78.47.13: Fetching http://intranet.whortonins.com/.well-known/acme-challenge/PLstdrbwr0lMVFDAx-XON0KI2p8mfvjepPb4iztVTWI: Timeout during connect (likely firewall problem)" ["error","status"] 400 ["error"] {"type":"urn:ietf:params:acme:error:connection","detail":"71.78.47.13: Fetching http://intranet.whortonins.com/.well-known/acme-challenge/PLstdrbwr0lMVFDAx-XON0KI2p8mfvjepPb4iztVTWI: Timeout during connect (likely firewall problem)","status":400} ["url"] "https://acme-v02.api.letsencrypt.org/acme/chall-v3/253407980656/rzFZTA" ["token"] "PLstdrbwr0lMVFDAx-XON0KI2p8mfvjepPb4iztVTWI" ["validationRecord",0,"url"] "http://intranet.whortonins.com/.well-known/acme-challenge/PLstdrbwr0lMVFDAx-XON0KI2p8mfvjepPb4iztVTWI" ["validationRecord",0,"hostname"] "intranet.whortonins.com" ["validationRecord",0,"port"] "80" ["validationRecord",0,"addressesResolved",0] "71.78.47.13" ["validationRecord",0,"addressesResolved"] ["71.78.47.13"] ["validationRecord",0,"addressUsed"] "71.78.47.13" ["validationRecord",0] {"url":"http://intranet.whortonins.com/.well-known/acme-challenge/PLstdrbwr0lMVFDAx-XON0KI2p8mfvjepPb4iztVTWI","hostname":"intranet.whortonins.com","port":"80","addressesResolved":["71.78.47.13"],"addressUsed":"71.78.47.13"} ["validationRecord"] [{"url":"http://intranet.whortonins.com/.well-known/acme-challenge/PLstdrbwr0lMVFDAx-XON0KI2p8mfvjepPb4iztVTWI","hostname":"intranet.whortonins.com","port":"80","addressesResolved":["71.78.47.13"],"addressUsed":"71.78.47.13"}] ["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.My guess is something blocking port 80?
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:
Assuming that 71.78.47.13 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:
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:
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:
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.
Looks like the new conconsole installed BUT...
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>
main()
File "/usr/bin/confconsole", line 712, in main
pm = plugin.PluginManager(PLUGIN_PATH,
File "/usr/lib/confconsole/plugin.py", line 183, in __init__
current_plugin = Plugin(file_path, module_globals)
File "/usr/lib/confconsole/plugin.py", line 78, in __init__
self.module = imp.load_module(self.module_name, module_fob,
File "/usr/lib/python3.9/imp.py", line 234, in load_module
return load_source(name, filename, file)
File "/usr/lib/python3.9/imp.py", 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/get_certificate.py", line 11, in <module>
import dns_01
ModuleNotFoundError: No module named 'dns_01'
Argh! It looks like there is something wrong with the package!?
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.:
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):
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...
Excellent! That worked!
Excellent! That worked! Thank you! Thank you!
got it to work, some notes for future reference
dns_01_spec = importlib.util.spec_from_file_location('dns_01', '/usr/lib/confconsole/plugins.d/Lets_Encrypt/dns_01.py') dns_01 = importlib.util.module_from_spec(dns_01_spec) sys.modules["dns_01"] = dns_01 dns_01_spec.loader.exec_module(dns_01)also and and then finally from the still activated venv hope it might help someone elseThanks for posting.
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