Outdated LE On Ova

Morning Fellas,

It appears that the current LE certbot that is installed on the .ova file is outdated. Under Monitoring -> LE log I get the following warning:

Code:

2021-06-06 09:01:07,657:DEBUG:certbot.main:certbot version: 0.35.1
2021-06-06 09:01:07,657:DEBUG:certbot.main:Arguments: ['-n', '--post-hook', "echo '1' > /usr/local/ispconfig/server/le.restart"]
2021-06-06 09:01:07,657:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2021-06-06 09:01:07,663:WARNING:certbot.cli:You are running with an old copy of letsencrypt-auto that does not receive updates, and is less reliable than more recent versions. The letsencrypt client has also been renamed to Certbot. We recommend upgrading to the latest certbot-auto script, or using native OS packages.
2021-06-06 09:01:07,664:DEBUG:certbot.cli:Deprecation warning circumstances: /opt/eff.org/certbot/venv/bin/certbot / {'LANG': 'en_US.UTF-8', 'SHELL': '/bin/sh', 'LANGUAGE': 'en_US:en', 'SHLVL': '1', 'OLDPWD': '/root', 'PWD': '/usr/local/ispconfig/server', 'LOGNAME': 'root', 'PATH': '/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin', 'HOME': '/root', '_': '/bin/php'}
2021-06-06 09:01:07,684:DEBUG:certbot.log:Root logging level set at 20
2021-06-06 09:01:07,685:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2021-06-06 09:01:07,694:DEBUG:certbot.renewal:no renewal failures

What are the steps to correct this?
Thx.

 

Any ramifications from using an alternative method install LE?

In an effort to keep my prod & test in sync, I tried the following that seems to work:

Then, I did referenced the original The Perfect Server instructions that I followed, to install the same acme LE and force updated ispconfig to issue new self-signed certificate .

Code:

1.)#curl https://get.acme.sh | sh -s
2.)#ispconfig_update.sh --force
3.)#shutdown -r now

Everything seems to be running perfectly fine... no errors or warnings anyway, -except-, I am a little worried because the Monitoring -> LE.log doesn't reflect any changes being made (still shows original warning, even after 5 minute refresh)

Is there a a cron job (or something else) I should run confirm all is well?

 

Appreciate the feedback.

As it stands, ispconfig_update.sh successfully issued a new certificate and previously, I haven't issued any LE ssl to any sites on my test server (actually no sites are installed, only nextcloud, which I didn't issue an ssl certificate to either.

Will adding completely new sites, somehow be at risk as well? This is a vbox test server, so I am not terribly concerned about ssl, more worried about unforeseen bugs / errors cropping up.

 

@jesse-Norell Thanks for the tip. However, last night, after a 2nd reboot.. the test server suddenly "freaked out with NC not loading and ISPConfig showing blank pages. After some investigation, I may need to use @till's original suggestion of updating only the cert-bot, if the problem is related to the new SSL. However, there is also a chance the sudden failure could be related to a modsec vs. ssl issue. Even though the modsec_audit.log is clear of errors... the apache2 error.log shows some modsec related issues that need to be resolved. After, I resolve the modsec issues, I will test the SSL "shortcut" solution, I had and see how it goes know..

 

Upon closer examination of the apache error log, there was no modsec vs. ssl issue (forgive the bias, modsec is usually the problem). The errors that were in my log were caused by me using self-signed SSL certificates on my test server with the "SSLUseStapling" directive turned on in my vhost. I set the directives to "Off" and that got rid of my errors and got LE log file going again. I did this with an earlier vbox snapshot, so now I have the old certbot working correctly.

From this point, I attempted @till's original recommendation and ran into my current problem.

One more, note (symptom), perhaps unrlated... even though LE log is going again (no ssl errors)... I am unable to issue a self-signed certificate for my nextcloud install. I check the boxes, click save, I see the red save indicator... test in browser.. no https... I re-check ispconfig domain config, and the SSL boxes are NOT checked.. (reverted)...

The official certbot instructions require me to install snapd (which I was trying to avoid with my acme.sh workaround). However, trying to do things the correct way, I have the problem that I can't -completely- install snapd on (debian 10 buster, inside virtualbox, oracle virtualization):

On Step 3 of the official instructions, I attempt to run:
https://certbot.eff.org/lets-encrypt/debianbuster-apache

Code:

#snap install core; sudo snap refresh core

error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
       /tmp/sanity-mountpoint-389560980: unknown filesystem type 'squashfs'.
error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
       /tmp/sanity-mountpoint-389560980: unknown filesystem type 'squashfs'.

I tried the solutions that I found online:

Code:

#apt install libsquashfuse0 squashfuse fuse
then
# snap install core; snap refresh core
error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
       /tmp/sanity-mountpoint-389560980: unknown filesystem type 'squashfs'.
error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
       /tmp/sanity-mountpoint-389560980: unknown filesystem type 'squashfs'.

No Luck.

At which point, I had to idea to skip over the above, and just try Step Five of the official instructions:

Code:

#snap install --classic certbot
error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
       /tmp/sanity-mountpoint-745794367: unknown filesystem type 'squashfs'.

So, this appears to be an impasse, no way to actually upgrade certbot.. Anyone have any thoughts?

FYI, another symptom / ssl problem. I can't issue a self-signed certificate for my nextcloud installation. I check the SSL boxes for the website -> domain , click save, wait for the red save to disapper. Then I check the browser.. no https. From here, I re-check ispconfig websites -> domain and the SSL boxes are no longer checked.

 

Are you using oracle virtualbox?

 

No customizations here... snap just doesn't like oracle virtualizations

Found this:
https://community.letsencrypt.org/t...-mount-squashfs-image-using-squashfs/132689/7

When I run "snap install core", I still get:

Code:

error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
       /tmp/sanity-mountpoint-202714544: unknown filesystem type 'squashfs'.

FYI

Code:

# snap install lxd
error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
       /tmp/sanity-mountpoint-329628364: unknown filesystem type 'squashfs'.

This is what finally has cerbot installed for me.

Code:

#apt install certbot
#apt install python3-certbot-apache

Still trying to figure out how to get it working with ispconfig. Any tips?

 

Clarity... What I mean is that my status quo is... My primary domain "test.example.com" has a self signed certificate that shows in the browser. However, I am unable to use ispconfig to assignment a SSL certificate to my nextcloud installation. LE.log is working.

 

My nextcloud installation is installed on my test server under nextcloud.com, but for dev purposes, I use a sitealias tester1.nextcloud.com
I tried the faq suggestion of "Skip Letsencrypt check" under System -> Server config -> server1.example.com -> Web.

No Luck. (FYI, I am using a bridged-network adapter)

EUREKA --- that's the problem... LE is checking acme for my production site (haven't installed nextcloud on production yet)... and clearly acme and certbot aren't friends.

There is a DNS A record for nextcloud.com on my test server, but LE seems to ignore it in preference of the prod server...

Code:

Domain: tester1.nextcloud.com
Type:   None
Detail: DNS problem: NXDOMAIN looking up A for tester1.nextcloud.com - check that a DNS record exists for this domain
2021-06-08 16:31:14,066:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: nextcloud.com
Type:   unauthorized
Detail: Invalid response from http://nextcloud.com/.well-known/acme-challenge/urhvCLriZJchYlaM4rHsXiDMQz1DsRkkP7tejP1GCsk [prod-ip-xx.xx.xx.xx]: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address.
2021-06-08 16:31:14,089:DEBUG:certbot.error_handler:Encountered exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 82, in handle_authorizations
    self._respond(aauthzrs, resp, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 168, in _respond
    self._poll_challenges(aauthzrs, chall_update, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 239, in _poll_challenges
    raise errors.FailedChallenges(all_failed_achalls)
certbot.errors.FailedChallenges: Failed authorization procedure. tester1.nextcloud.com (http-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up A for tester1.nextcloud.com - check that a DNS record exists for this domain, nextcloud.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://nextcloud.com/.well-known/acme-challenge/urhvCLriZJchYlaM4rHsXiDMQz1DsRkkP7tejP1GCsk [prod-ip-xx.xx.xx.xx]: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"

2021-06-08 16:31:14,089:DEBUG:certbot.error_handler:Calling registered functions
2021-06-08 16:31:14,089:INFO:certbot.auth_handler:Cleaning up challenges
2021-06-08 16:31:14,090:DEBUG:certbot.plugins.webroot:Removing /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/urhvCLriZJchYlaM4rHsXiDMQz1DsRkkP7tejP1GCsk
2021-06-08 16:31:14,090:DEBUG:certbot.plugins.webroot:Removing /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/Re9inhcx2vGCROWKVmzGfJgIljuHAuW0pOEhqt1Dt00
2021-06-08 16:31:14,090:DEBUG:certbot.plugins.webroot:All challenges cleaned up
2021-06-08 16:31:14,090:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/letsencrypt", line 11, in <module>
    load_entry_point('certbot==0.31.0', 'console_scripts', 'certbot')()
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1365, in main
    return config.func(config, plugins)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1250, in certonly
    lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 121, in _get_and_save_cert
    lineage = le_client.obtain_and_enroll_certificate(domains, certname)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 410, in obtain_and_enroll_certificate
    cert, chain, key, _ = self.obtain_certificate(domains)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 353, in obtain_certificate
    orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 389, in _get_order_and_authorizations
    authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 82, in handle_authorizations
    self._respond(aauthzrs, resp, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 168, in _respond
    self._poll_challenges(aauthzrs, chall_update, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 239, in _poll_challenges
    raise errors.FailedChallenges(all_failed_achalls)
certbot.errors.FailedChallenges: Failed authorization procedure. tester1.nextcloud.com (http-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up A for tester1.nextcloud.com - check that a DNS record exists for this domain, nextcloud.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://nextcloud.com/.well-known/acme-challenge/urhvCLriZJchYlaM4rHsXiDMQz1DsRkkP7tejP1GCsk [prod-ip-xx.xx.xx.xx]: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"
2021-06-08 16:31:14,538:DEBUG:certbot.main:certbot version: 0.31.0
2021-06-08 16:31:14,539:DEBUG:certbot.main:Arguments: ['--domains', 'nextcloud.com', '--domains', 'tester1.nextcloud.com']
2021-06-08 16:31:14,539:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2021-06-08 16:31:14,545:DEBUG:certbot.log:Root logging level set at 20
2021-06-08 16:31:14,545:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log

 

I am wrong again... Ok... So how do I generate the self-signed SSL for nextcloud.com on the test server? disconnect the internet, then try?

 

Got it. Thanks.

Another question...since my prod doesn't have any sites yet, not even nextcloud, is it possible to / how would I go about switching from acme.sh to certbot on my prod server?

While I don't immediately need ssl on my test server, I know a few wordpress shopping cart plugins require a ssl certificate to be installed, even during dev & testing, so thinking ahead, I don't want the worry of conflicting acme vs. certbot certificates slowing progress...

How would I adjust these steps to remove acme from my prod server?