SSL_ERROR_INTERNAL_ERROR_ALERT för Nextcloud via snap

@Airikr:

Disclaimer: Jag kan ingenting om Nextcloud eller Snap.

Jag tycker inte det ser ut som att problemet är i certifikatet i sig, utan i SSL-konfigurationen. Sökväg till privkey/pubkey/certificate chain, protokoll/schifferkonfiguration kan vara fel, t ex.

Se nedan:

openssl s_client -connect cloud.edgren.blog:443
CONNECTED(00000003)
140365640762496:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../ssl/record/rec_layer_s3.c:1544:SSL alert number 80
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 309 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)
---

Raden "no peer certificate available" är mest intressant, där.

Vidare hittar jag inte "-t" i certbots manual, men jag misstänker att -t är shorthand för "--test-cert". Vilket INTE - som du skriver - är ett "test av certifikat". Utan istället en begäran om ett testcertifikat (istället för ett skarpt certifikat). Detta är inte vad du vill göra.

Se följande meddelande:

You've asked to renew/replace a seemingly valid certificate with a test certificate (domains: cloud.edgren.blog). We will not do that unless you use the --break-my-certs flag!

Det signalerar att du redan har ett skarpt certifikat på plats. Vilket också styrker min teori om att din SSL-konfiguration är fel.

Edit: Läste lite snabbt om Nextcloud och tolkar det som att det inte är en "fristående" server utan att applikationen behöver en fristående webbserver, vilket i ditt fall verkar vara Aapache. Så SSL-konfigurationen måste göras där snarare än i Nextcloud.

Här är ett exempel på hur relevanta delar av SSL-konfigurationen i Apache kan se ut:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/cloud.edgren.blog/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/cloud.edgren.blog/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/cloud.edgren.blog/chain.pem

@Airikr:

Som sagt kan jag inte Nextcloud eller Snap så bra, så jag vet inte riktigt om snap kan orsaka "dubletter" av paket, eller om man kan ha två paket som kolliderar med varandra på något sätt men jag noterade nedan i loggen du visade.

Jun 10 18:15:16 server-home nextcloud.apache[1364292]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Jun 10 18:15:16 server-home nextcloud.apache[1364292]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
Jun 10 18:15:16 server-home nextcloud.apache[1364292]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
Jun 10 18:15:16 server-home nextcloud.apache[1364292]: no listening sockets available, shutting down
Jun 10 18:15:16 server-home nextcloud.apache[1364292]: AH00015: Unable to open logs
Jun 10 18:15:16 server-home systemd[1]: snap.nextcloud.apache.service: Main process exited, code=exited, status=1/FAILURE

Apache meddelar att det inte kan starta på grund av att en annan process lyssnar på port 80.

Jag tänker att du kanske har två två Apache-instanser igång, där den ena inte har en korrekt SSL-konfiguration? Du kan ju kolla runt litet med ps netstat (sudo netstat -tulpno), osv.

@Airikr:

Hmm, märkligt att netstat inte visar något på TCP port 80. Eftersom att apache inte kan knyta till den porten så hade jag förväntat mig att se nåt i stil med (grovt förenklat) tcp 0.0.0.0:80 LISTEN apache2. Någonting ligger ju onekligen där.

Du kan ju, lite för skojs skull testa sudo ss -tlpn istället för netstat.

Att systemctl status apache inte visar något beror på att apache-tjänsten heter apache2.

Edit: Förresten, utifrån så ser det ut som Caddy (inte apache):

curl -I cloud.edgren.blog
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
Server: Caddy
X-Content-Type-Options: nosniff
Date: Wed, 10 Jun 2020 21:22:58 GMT
Content-Length: 59

@Airikr:

Poängen med min edit ovan var inte 404-felsidan, utan vilken webbserver som lyssnar på porten tar emot anslutningen.

Tar mig friheten att klistra in en rad från loggarna som skall vara "lugnt". Den avslöjar ingenting känsligt eller annat som vi inte redan pratat om i tråden.

Netstat visar (bl a):

tcp6       0      0 :::80                   :::*                    LISTEN      745/caddy            off (0.00/0/0)
tcp6       0      0 :::443                  :::*                    LISTEN      745/caddy            off (0.00/0/0)

Som du ser har Caddy bundit både port 80 och port 443. Det är sannolikt anledningen till att Apache inte lirar. Jag kollade snabbt på snapcraft-filen för Nextcloud (här) och det verkar inte som Nextcloud använder Caddy, utan - just precis - Apache.

Vad använder du Caddy till? Du kan ju testa att tillfälligt stänga av Caddy och starta om (snap) nextcloud och se om det lirar då.

Dvs nåt i stil med (jag vet inte exakt, det beror på var caddy kommer ifrån):

sudo systemctl stop caddy
sudo snap restart nextcloud

Obs: En del osäkerheter här som du ser. Jag vet inte var Caddy kommer ifrån eller vad du använder det till, och har aldrig jobbat med snap eller nextcloud.

Gah, just det ...

Men är det då inte så enkelt att både Nextcloud/Apache och Rocket Chat/Caddy försöker binda till 80 och 443, och av en händelse så har Rocket Chat/Caddy "hunnit först" och Nextcloud/Apache kan inte starta. När vi sedan ansluter till cloud.edgren.blog i ett försök att nå Nextcloud/Apache så är det i själva verket Caddy/Rocket Chat som svarar. Men Caddy/Rocket Chat's vhost/SSL-konfiguration är för chat.sermo.nu (INTE cloud.edgren.blog), och då smäller det.

Är du med? Det är Caddy som orsakar SSL_ERROR_INTERNAL_ERROR_ALERT, inte Nextcloud. Nextcloud körs inte ens.

Du kan inte ("utan vidare" - för jag antar att du inte har någon reverse proxy) köra både Nextcloud/Apache och Caddy/Rocket Chat på 80/443. En tänkbar lösning är att du konfigurerar den ena tjänsten att lyssna på 8080 och 8443, istället. Och gör motsvarande port forwards/redirects i din brandvägg, så klart.

Här beskriver Nextcloud hur man ändrar sin port-konfiguration när applikationen är installerad via snap: https://github.com/nextcloud/nextcloud-snap#httphttps-port-co...

Om det inte löser sig finns ju möjligheten att fråga på Ubuntu-Sverige och skulle det inte heller hjälpa finns AskUbuntu där många ytterst kunniga Ubuntu-användare hänger

Well, Att ha olika vhosts/domännamn räcker inte, tyvärr. Om du nu ska hosta bägge tjänsterna på samma server med ett externt ip så är det enda sättet (jag kan komma på) att sätta upp/konfigurera en proxy/tunnel framför som sedan vidarebefordrar trafiken "upstream" till de riktiga tjänsterna. Du skulle t ex kunna använda Apache med hjälp av modulen mod_proxy, eller installera en "riktig" proxy såsom haproxy eller squid.

Du skulle kunna börja kika här: https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html och/eller här: https://docs.nextcloud.com/server/15/admin_manual/configurati... Det kan bli väldigt lärorikt för dig, men känn efter om inte ett vanligt bookmark är tillräckligt, först.

@Airikr
Jupp ser att du genererat ett par stycken ^^

Kan rekommendera att du genererar ett wildcard cert till din domän istället så de blir
*.edgren.blog

* = kommer att hantera / acceptera alla andra subdomäner du lägger till via din DNS-hanterings portal.

Utöver det så behöver din proxy .conf för nextcloud vara korrekt.

Hjälpte en användare på reddit, efter att han fick min nextcloud konfig så löste sig allt för honom 😋
https://www.reddit.com/r/NextCloud/comments/ezea8l/help_fixin...

Kolla gärna igenom min konfig och updatera tråden om du behöver mer hjälp efter
Lycka till!

Jag skulle rekommendera helt tvärt om

Om du kör en pre-built så kan du absolut noll om ditt eget system om det fallerar.
Om du kör snap, ganska mycket samma sak. 10 minuter att få upp - sedan har man 0 kunskap om vad man kör.

Jag skulle rekommendera att du installerar nextcloud standalone

https://docs.nextcloud.com/server/latest/admin_manual/install...
Då kan du köra den webbserver du redan kör till dina andra edgren siter, de verkar du ha fått rätt på med https redan juh

Finns också guider som (oftast är bra) problemet (imo) är att de ofta innehåller lite egna lösnignar av de som skriver dem, vilket gör - att när något går sönder - så står man där som ett pucko.

Jag installerade om min NC miljö c:a 10ggr innan jag blev nöjd xD

Jag håller med. Självklart kan man inte förvänta sig att alla ska göra allt från scratch -- Och någonstans ska man dra gränsen avseende hur mycket "automagi" man vill ha. Jag menar liksom inte att någon som villl köra Nextcloud måste köra Gentoo och kompilera allt från källkod. Men i det här fallet så tror jag delar av grundproblemet bottnade i att OP förväntade sig att "sudo snap install nextcloud rocketchat-server" bara skulle fungera (vilket är en rimlig tanke, för det är ju så dessa hjälpmedel marknadsförs).

Men "under huven" installerades (bl a) Apache, MySQL, Redis, PHP-FPM, Caddy, MongoDB, NodeJS, Certbot ... Och tråden skapades därför att Apache och Caddy inte tog hänsyn till varandra.

Oavsett om man väljer att köra sina tjänster mha snap, docker, virtuella maskiner eller någonting annat så blir det ofta svårare att anpassa/felsöka/lösa problem om man tagit för många genvägar. I synnerhet om man har flera tjänster som riskerar att kollidera med varandra på något sätt eller vill börja skräddarsy sin miljö och, t ex, vilja serva två applikationer på samma port via en proxy.

Att inte ta några genvägar och göra saker den "långa vägen" som jag och Allexz (om jag förstår honom rätt) pratar om är jäkligt väl investerad tid bland annat eftersom man tvingas lära sig vilka komponenter som krävs och hur de passar ihop. Och då blir det lättare att fixa eleganta och skräddarsydda lösningar, samt att fixa potentiella problem. Och dessutom kan man slippa den bloat och/eller "abstraktion" som genvägar så som docker och snap tenderar att skapa.

Inte för jag är någon Linux-guru direkt, och ni såg ju hur jag reserverade mig eftersom att jag inte är bekant med snap, osv. Men jag tror att jag kunde hjälpa till ändå till stor del på grund av att jag lärt mig den långa vägen och därför kunde sätta mg in i snap relativt fort.

Menar inte att skapa ett krig mellan apt, snap, docker eller virtuella maskiner här -- Alla har sin plats och jag använder själv samtliga (med undantag för just snap, då, hehe). Men för mig känns det bra att veta att oavsett vad nästa "genvägsteknik" blir så har jag hyffsat koll på grunderna och kommer kunna förhålla mig till det.

Edit: Sen hade det kanske varit artigt av enoch85 att nämna att han är maintainer för den VM han länkade till. Inte för att jag misstror honom -- Projektet är ju FLOSS, men i ett annat sammanhang hade det kanske varit viktigare för att förekomma eventuella diskussioner om egenintressen.