Forum thread where this was diagnosed:
https://help.nextcloud.com/t/lets-encrypt-problem-switching-from-dyndns-to-freedns/244548
| # |
Component |
Severity |
Impact |
| 1 |
letsencrypt.sh |
High |
Apache unrecoverable, no UI recovery path |
| 2 |
nc-httpsonly.sh |
Medium |
Silent failure with misleading error output |
| 3 |
Documentation |
Low |
Missing domain-change workflow causes user error |
Issue 1 — letsencrypt.sh has no fallback when certbot fails and the old cert is already gone
In letsencrypt.sh, install_template nextcloud.conf.sh is only called when certbot succeeds (the whole update block is behind &&). If certbot fails, 001-nextcloud.conf is left unchanged.
That is fine as long as the previously referenced certificate still exists. The problem is when a user tries to switch domains: the old cert may already be gone (expired, deleted, or removed during a previous failed attempt), certbot fails because port 80 is not set up correctly yet, and now 001-nextcloud.conf points to a cert file that no longer exists. Apache cannot reload or restart. There is a recovery path — disabling LE via the NCP panel triggers the ACTIVE=no branch which calls install_template unconditionally and restores Apache with the snakeoil cert — but nothing in the UI indicates this, and a user trying to switch domains would have no reason to think "disable LE first" is the required step.
The ACTIVE=no path already does the right thing — it calls install_template unconditionally and the template falls back to the Debian snakeoil cert (${LETSENCRYPT_CERT_PATH:-/etc/ssl/certs/ssl-cert-snakeoil.pem}). The certbot failure branch should do the same: check whether the cert currently referenced in 001-nextcloud.conf still exists, and if not, call install_template to get Apache back into a startable state.
Issue 2 — nc-httpsonly.sh breaks silently when 000-default.conf is missing
nc-httpsonly.sh runs sed directly on 000-default.conf with no existence check:
sed -i "s|RewriteEngine .*|RewriteEngine $opt|" /etc/apache2/sites-available/000-default.conf
apachectl -k graceful
If the file is missing, sed fails and the graceful reload fails. The NCP panel shows the reload error but gives no indication that the root cause is the missing file. The file is created by nc-nextcloud.sh during installation and also by the 1.40.0.sh update, but nothing recreates it on demand.
A simple existence check at the top of configure() -- and recreating the file with the same content already present in nc-nextcloud.sh and 1.40.0.sh if it is missing -- would fix this.
Issue 3 — Missing documentation for domain change workflow
The Configuration Reference only says: enter domain, enter email, click Run. There is nothing about the correct sequence for a domain change (disable LE first, then update the domain, then re-enable), and nothing about the dependency on 000-default.conf being present for certbot's webroot challenge to work.
Forum thread where this was diagnosed:
https://help.nextcloud.com/t/lets-encrypt-problem-switching-from-dyndns-to-freedns/244548
letsencrypt.shnc-httpsonly.shIssue 1 —
letsencrypt.shhas no fallback when certbot fails and the old cert is already goneIn
letsencrypt.sh,install_template nextcloud.conf.shis only called when certbot succeeds (the whole update block is behind&&). If certbot fails,001-nextcloud.confis left unchanged.That is fine as long as the previously referenced certificate still exists. The problem is when a user tries to switch domains: the old cert may already be gone (expired, deleted, or removed during a previous failed attempt), certbot fails because port 80 is not set up correctly yet, and now
001-nextcloud.confpoints to a cert file that no longer exists. Apache cannot reload or restart. There is a recovery path — disabling LE via the NCP panel triggers theACTIVE=nobranch which callsinstall_templateunconditionally and restores Apache with the snakeoil cert — but nothing in the UI indicates this, and a user trying to switch domains would have no reason to think "disable LE first" is the required step.The
ACTIVE=nopath already does the right thing — it callsinstall_templateunconditionally and the template falls back to the Debian snakeoil cert (${LETSENCRYPT_CERT_PATH:-/etc/ssl/certs/ssl-cert-snakeoil.pem}). The certbot failure branch should do the same: check whether the cert currently referenced in001-nextcloud.confstill exists, and if not, callinstall_templateto get Apache back into a startable state.Issue 2 —
nc-httpsonly.shbreaks silently when000-default.confis missingnc-httpsonly.shrunsseddirectly on000-default.confwith no existence check:sed -i "s|RewriteEngine .*|RewriteEngine $opt|" /etc/apache2/sites-available/000-default.conf apachectl -k gracefulIf the file is missing,
sedfails and the graceful reload fails. The NCP panel shows the reload error but gives no indication that the root cause is the missing file. The file is created bync-nextcloud.shduring installation and also by the1.40.0.shupdate, but nothing recreates it on demand.A simple existence check at the top of
configure()-- and recreating the file with the same content already present innc-nextcloud.shand1.40.0.shif it is missing -- would fix this.Issue 3 — Missing documentation for domain change workflow
The Configuration Reference only says: enter domain, enter email, click Run. There is nothing about the correct sequence for a domain change (disable LE first, then update the domain, then re-enable), and nothing about the dependency on
000-default.confbeing present for certbot's webroot challenge to work.