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 
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 cloud.mydomain.de:443
CONNECTED(00000003)
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: cloud.mydomain.de
Domains: cloud.mydomain.de
Expiry Date: 2022-03-27 12:15:49+00:00 (VALID: 89 days)
Certificate Path: /srv/letsencrypt/live/cloud.mydomain.de/fullchain.pem
Private Key Path: /srv/letsencrypt/live/cloud.mydomain.de/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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> 
Thank you for the suggestions, they helped me to solve this issue. In addition, I had to login to the Nextcloud via local domain http://nextbox.fritz.box (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. 
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
