After three months of running my Nextbox in production, the TLS certificate failed to renew. I found that it was probably due to not having set up IPv6 correctly in the Fritzbox. Fortunately, the docs explain its settings explicitly, so I set the IA_NA setting correctly and suddenly all the bars at HTTPS / TLS Status of the Nextbox app went green :tada:

Then I renewed the certificate manually doing sudo certbot --config-dir /srv/letsencrypt renew via SSH and expected everything to run smoothly again. Unfortunately, now the website won’t show up at all anymore. Instead, Firefox says

Secure Connection Failed - Error code: SSL_ERROR_RX_RECORD_TOO_LONG

Web research on this states that something is wrong with the server config. openssl even thinks that there is no certificate served at all:

$ openssl s_client -connect
140558183642496:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:331:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 5 bytes and written 316 bytes
Verification: OK
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

The certificate is there and valid though:

$ sudo certbot --config-dir /srv/letsencrypt certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name:
    Expiry Date: 2022-03-27 12:15:49+00:00 (VALID: 89 days)
    Certificate Path: /srv/letsencrypt/live/
    Private Key Path: /srv/letsencrypt/live/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

What can I do next to investigate what is wrong here?

hey @mcnesium

mmmh, never happened before™

really hard to guess what went wrong here, do you use guided dns or static ? The guided DNS approach now uses (deSEC) dns for verification against letsencrypt now instead of direct connection, so this might be an issue.

Frankly, I would suggest to not debug this, but moreover redo it. So roughly like that (all as root or with sudo)

  • stop the nextcloud containers systemctl stop nextbox-compose
  • remove the ssl site sym-link from the apache configuration rm /srv/apache2/site-enabled/nextbox-ssl.conf
  • create the default (non-ssl) sym-link to ln -s /srv/apache2/sites-available/000-default.conf /srv/apache2/site-enabled/
  • delete (backup) contents of /srv/letsencrypt (to make sure a new certificate will be acquired)
  • start the nextcloud containers systemctl start nextbox-compose

(untested commands, be careful and check them twice please)

Then you should be able to login to your nextcloud instance again an acquire a new certificate with your favored method.

<add typical ssh-no-support-and-own-risk-disclaimer here> :smiley:

Thank you for the suggestions, they helped me to solve this issue. In addition, I had to login to the Nextcloud via local domain (after adding this domain to the trusted_domains array in /srv/nextcloud/config/config.php via SSH) and first dis- and then reenable HTTPS in the Nextbox app to kickstart the Letsencrypt certificate renewal.

Also I noticed that there was no nextbox-ssl.conf symlink in /srv/apache2/site-enabled to remove, and instead the 000-default.conf symlink was already there.

But now the nextbox can be reached on the regular TLS-enabled domain again. :tada:

One downside is that there are yellow bars again here:

Could that become a problem sometime in the future?

As long as your NextBox is reachable from the outside there should be no problem. Although this is a little weird, as the reported reachability is ok, but there seems to be no Nextcloud answering. Did you try reaching your Nextcloud instance from a mobile network or a external machine?

external machine via regular DSL/Cable network