[bug] domain change via letsencrypt tool can leave Apache unrecoverable

Forum thread where this was diagnosed:
https://help.nextcloud.com/t/lets-encrypt-problem-switching-from-dyndns-to-freedns/244548

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.

Start with bin/ncp/NETWORKING/letsencrypt.sh and bin/ncp/CONFIG/nc-httpsonly.sh, then compare the 000-default.conf content in nc-nextcloud.sh and 1.40.0.sh. Verify the certificate-failure fallback and missing-file handling restore a startable Apache configuration, and document the domain-change sequence and webroot dependency in the Configuration Reference.