Migrating from SME 9.2 - letsencrypt

NethServer Version: nethserver-7.9.2009-x86_64
Module: letsencrypt

It seems, the procedure of renewing the letsencrypt certs have not been migrated to the NS. What would be the best approach for getting and renewing the certs in the NethServer?

Once you have requested a letsencrypt certificate here:

image

Updates are done automatically

EDIT:
Upload certificate may not cover al the options (ie Request Let's Eencrypt certificate) can’t think of a better text :thinking: … any suggestions? cc// @giacomo @edoardo_spadoni

This process leads to:

tail -f /var/log/letsencrypt/letsencrypt.log

File “/usr/lib/python2.7/site-packages/certbot/_internal/client.py”, line 374, in obtain_certificate
orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
File “/usr/lib/python2.7/site-packages/certbot/_internal/client.py”, line 421, in _get_order_and_authorizations
authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
File “/usr/lib/python2.7/site-packages/certbot/_internal/auth_handler.py”, line 91, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, best_effort)
File “/usr/lib/python2.7/site-packages/certbot/_internal/auth_handler.py”, line 180, in _poll_authorizations
raise errors.AuthorizationError(‘Some challenges have failed.’)
AuthorizationError: Some challenges have failed.
2021-01-06 21:41:56,529:ERROR:certbot._internal.log:Some challenges have failed.

On the SME box this was handled by dehydrated. What about the Authorization error? I read about certbot in the wiki and in the forum and I’m not clear quite clear with the process. I didn’t have to register to a bot while using dehydrated…

Well, yes, you did–it’s just that the bot was called dehydrated rather than certbot. Both are pieces of software that run locally on your server.

I’d expect the full letsencrypt.log would give more detail for the issue. Without that, I could only say:

  • Make sure every hostname on the request has a public DNS record that points to the public IP address of your Neth server, and
  • Make sure there’s no firewall blocking port 80 on your Neth server.
1 Like

o.k., that the bot was (is) dehydrated was not clear to me, thank’s for clarification. The process went flawless before, port 80 is open on the NS. Could it be a owner/rights problem in /var/www/html?

ls -lahtr /var/www/html/

total 20K
drwxr-xr-x. 4 root root 33 Nov 16 17:19 …
drwxr-xr-x. 3 root root 28 Jan 4 16:10 .well-known
-rw-r----- 1 apache apache 766 Jan 5 16:50 favicon.ico
-rw-r----- 1 apache apache 267 Jan 5 16:50 index.html
-rw-r–r-- 1 apache apache 187 Jan 5 16:50 index.php
-rw-r–r-- 1 apache apache 26 Jan 5 16:50 robots.txt
drwxr-xr-x. 3 root root 114 Jan 5 17:07 .
-rw-r–r-- 1 apache apache 211 Jan 5 17:10 .htaccess

What about .well-known? Owner is root?

and

ie port 80 is forwarded to your nethserver instance locally?

I remember I had to customize the deydrated script on the SME. It worked like this:

I added in the script dehydrated

export http_proxy=http://ip-of-the-proxy:port-of-the-proxy, and
export https_proxy=http://ip-of-the-proxy:port-of-the-proxy

On the OPNSense there is a proxy running. I’ll disable the proxy to check if this is the reason for the error and let you know.

1 Like

Now, if HTTP access to your server from outside is a problem, DNS validation may be an option for you. See:


and:

Well, you may try for yourself to reach ivbonline.de and www.ivbonline.de
All I see (now) is the standard NS html page.
The letsencrypt log says:

Fetching http://www.ivbonline.de/.well-known/acme-challenge/…: Connection refused

Even while I changed to apache:apache and did a service httpd restart.

Yep, that’s a firewall problem. Disable the reverse proxy on your OPNsense box, and forward port 80 to the NS box.

I disabled the proxy, disabled also every rule not to bypass the proxy. I already had a rule for the dehydrated bot directing the challenge to the ip of the server with the ports 80 and 443. That did not work.

I created a new rule without aliases directing explicit the port 80 to the NS IP port 80. That did the job. I don’t get it???

Now back to owner/rights in var/www/html - should I revert -R the directory .well-known back to root:root?

Might as well. Even as you showed it up-thread, it’s world-readable, which is all that’s needed.

I thought so. Thank you for your help.

regards,
stefan