nextcloudpi
nextcloudpi copied to clipboard
nextcloud
v1.53.1 breaks NextcloudPi panel on custom domain (4443)
After upgrade from NextcloudPi version v1.53.0 to v1.53.1, the NextcloudPi panel (4443) Is not available.
HTTPd log:
[ssl:warn]
localhost:4443:0 server certificate does NOT include an ID which matches the server name.
ssl_stapling_init_cert: can't retrieve issuer certificate!.
I can see that in /etc/apache2/sites-available/ncp.conf, it is used SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert snakeoil.key instead of SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/privkey.pem
After modifying SSLCertificateFile in /etc/apache2/sites-available/ncp.conf Nextcloudpi panel is available again, but gets messages like "You should run Lets Encrypt for trusted encrypted acces" and "Certificates none" This is not the case!
So v1.53.1 breaks this.
/etc/letsencrypt/live/domain.com/fullchain.pem should never have been used in ncp.conf. The admin panel is supposed to only be available on the local network via the ip address, nextcloudpi.local.
Did you manually adjust the apache config?
yes, but only for debugging. I understand that it should only be available on local network, but it doesn't work anymore!
Hi I too did access to the config page through myDomain:4443 ^^' And I didn't change any config file to do so (or I don't remember) Didn't know I wasn't supposed to (but usefull when you want to know why the server is down (HPB or Redis often faulty here)) @Haraade : to fix this I just renew the Let's encrypt certificate with "ncp-config" tool in a shell window (however it was valid) After that I could access the web page.
I have renewed the Let's encrypt certificat. It was valid, and it is also after the renewal.
When I go to https://local-ip:4443 I get this feedback: Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please.
Okay, sorry, maybe this was just a use case I wasn't aware of - it's indeed possible to access the admin panel via the domain if you're in the same local network and are using the dnsmasq service of ncp or some custom rerouting in your router.
I'll work on a fix.
@Haraade Are you sure that you aren't missing the s from https in your url? Your new error message sounds like that might be the issue.
Yes, it is HTTPS.
I do not use the dnsmasq service that is included. I have three separate dns servers in the same network that all refers the ip>domain.
Do you have any custom proxies in front of NCP?
You're speaking plain HTTP to an SSL-enabled server port. clearly states that you are trying to talk to NCP via an unencrypted connection
If possible, include the output of curl -kv https://ncp-local-ip from your machine (if you have a linux PC available.
No proxies.
curl -kv https://192.168.0.20:4443/
- Trying 192.168.0.20:4443...
- Connected to 192.168.0.20 (192.168.0.20) port 4443 (#0)
- ALPN, offering h2
- ALPN, offering http/1.1
- successfully set certificate verify locations:
- CAfile: /etc/ssl/certs/ca-certificates.crt
- CApath: /etc/ssl/certs
- TLSv1.3 (OUT), TLS handshake, Client hello (1):
- TLSv1.3 (IN), TLS handshake, Server hello (2):
- TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
- TLSv1.3 (IN), TLS handshake, Certificate (11):
- TLSv1.3 (IN), TLS handshake, CERT verify (15):
- TLSv1.3 (IN), TLS handshake, Finished (20):
- TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
- TLSv1.3 (OUT), TLS handshake, Finished (20):
- SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
- ALPN, server accepted to use h2
- Server certificate:
- subject: CN=odroidm1
- start date: Feb 25 22:49:30 2023 GMT
- expire date: Feb 22 22:49:30 2033 GMT
- issuer: CN=odroidm1
- SSL certificate verify result: self signed certificate (18), continuing anyway.
- Using HTTP2, server supports multi-use
- Connection state changed (HTTP/2 confirmed)
- Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
- Using Stream ID: 1 (easy handle 0x2ced70)
GET / HTTP/2 Host: 192.168.0.20:4443 user-agent: curl/7.74.0 accept: /
- TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
- TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
- old SSL session ID is stale, removing
- Connection state changed (MAX_CONCURRENT_STREAMS == 100)! < HTTP/2 401 < strict-transport-security: max-age=15768000; includeSubDomains < www-authenticate: Basic realm="ncp-web login" < content-length: 381 < content-type: text/html; charset=iso-8859-1 < date: Fri, 02 Feb 2024 09:27:57 GMT < server: Apache <
Unauthorized
This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.
* Connection #0 to host 192.168.0.20 left intact
Hm, that output looks perfectly fine, actually...
Can you try again with curl -u ncp:<web-panel-password> -kv https://ncp-local-ip?
PLEASE MAKE SURE TO REMOVE THE PASSWORD FROM THE OUTPUT BEFORE POSTING!
- Trying 192.168.0.20:4443...
- Connected to 192.168.0.20 (192.168.0.20) port 4443 (#0)
- ALPN, offering h2
- ALPN, offering http/1.1
- successfully set certificate verify locations:
- CAfile: /etc/ssl/certs/ca-certificates.crt
- CApath: /etc/ssl/certs
- TLSv1.3 (OUT), TLS handshake, Client hello (1):
- TLSv1.3 (IN), TLS handshake, Server hello (2):
- TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
- TLSv1.3 (IN), TLS handshake, Certificate (11):
- TLSv1.3 (IN), TLS handshake, CERT verify (15):
- TLSv1.3 (IN), TLS handshake, Finished (20):
- TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
- TLSv1.3 (OUT), TLS handshake, Finished (20):
- SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
- ALPN, server accepted to use h2
- Server certificate:
- subject: CN=odroidm1
- start date: Feb 25 22:49:30 2023 GMT
- expire date: Feb 22 22:49:30 2033 GMT
- issuer: CN=odroidm1
- SSL certificate verify result: self signed certificate (18), continuing anyway.
- Using HTTP2, server supports multi-use
- Connection state changed (HTTP/2 confirmed)
- Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
- Server auth using Basic with user 'ncp'
- Using Stream ID: 1 (easy handle 0x49ed70)
GET / HTTP/2 Host: 192.168.0.20:4443 authorization: Basic user-agent: curl/7.74.0 accept: /
- TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
- TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
- old SSL session ID is stale, removing
- Connection state changed (MAX_CONCURRENT_STREAMS == 100)! < HTTP/2 200 < content-security-policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; object-src 'self'; < x-xss-protection: 1; mode=block < x-content-type-options: nosniff < x-robots-tag: none < x-permitted-cross-domain-policies: none < x-frame-options: DENY < cache-control: no-cache < pragma: no-cache < expires: -1 < link: </js/minified.js>; rel=preload; as=script;,</js/ncp.js>; rel=preload; as=script;,</css/ncp.css>; rel=preload; as=style;,</img/ncp-logo.svg>; rel=preload; as=image;, </img/loading-small.gif>; rel=preload; as=image;, rel=preconnect href=ncp-launcher.php; < set-cookie: PHPSESSID=; path=/; secure; HttpOnly < strict-transport-security: max-age=15768000; includeSubDomains < vary: Accept-Encoding < content-type: text/html; charset=UTF-8 < date: Fri, 02 Feb 2024 13:03:47 GMT < server: Apache
The rest of what came out is too much to post here!
This is the feedback in the firefox browser.
https://domain.com:4443 has a security policy called HTTP Strict Transport Security (HSTS), which means Firefox can only connect to it securely. You cannot add an exception to visit this site.
I see... I think I understand the issue. The web interface is actually working, but the certificate has changed. Since your browser already knew the old certificate and HSTS is enabled, it will refuse to connect to it with a new certificate. Can you try a different browser and, if that works, delete the information about that page from your browser ("forget about this page" in firefox)?
I can access the panel, but browser complains about unsafe website.
What makes it a problem to use SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem and SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/privkey.pem ? As long as port 4443 is not exposed to anything other than the local network. This is taken care of by the firewall in the ncp. These certificates are regularly updated.
With the latest changes, ncp-panel complains about: Certificates none You should run Lets Encrypt for trusted encrypted access
That's not true.
I updated nc-apps, nextcloud, and nc-update; all from the ncp web panel yesterday. Everything went fine, no issues.
Today I decided to update my debian 11 system packages. I have been holding off updating them, for over a year due to issues I had with php8.1. I saw that php8.1 is supported in NCP now, so I updated. It caused my HPB service to be down and I was unable to access the nextcloud web panel (i could access ncp panel fine). So I reverted to a backup of my / (minus /home) partition I made yesterday.
IDK what is causing this. I also am not sure what php version I'm running. If someone can provide a command for me to check, I'll check and let you know, if that's of any help.
What makes it a problem to use SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem and SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/privkey.pem ?
Nothing, I was just not aware that the admin panel was configured in this way. This will be readded soon.
I updated nc-apps, nextcloud, and nc-update; all from the ncp web panel yesterday. Everything went fine, no issues.
Today I decided to update my debian 11 system packages. I have been holding off updating them, for over a year due to issues I had with php8.1. I saw that php8.1 is supported in NCP now, so I updated. It caused my HPB service to be down and I was unable to access the nextcloud web panel (i could access ncp panel fine). So I reverted to a backup of my / (minus /home) partition I made yesterday.
IDK what is causing this. I also am not sure what php version I'm running. If someone can provide a command for me to check, I'll check and let you know, if that's of any help.
That sounds like an entirely different issue. @Ronkn please create a new issue for this and include information about what you did exactly.
I believe I added one a while ago about this. I'll look back to see what I can find. Or maybe that was in the nextcloud forum. I'll open an issue if I don't have one already opened.