Ungültiges SSL Zertifikat für Nextcloud, bei Zugriff aus gleichem Netzwerk

xtim · February 1, 2021, 9:27am

Hallo liebe Community,

leider habe ich nachwie vor Probleme mit meiner Nextcloud und dem Zugriff via HTTPS. Im Gegensatz zu meinem letzten Post diesbezüglich kann ich das Problem nun besser lokalisieren.

Ich erhalte beim Zugriff auf meine Nextcloud über eine SSL-Verschlüsselte DynDNS aus meinem eigenen Netzwerk immer den Fehler “ERR_CERT_AUTHORITY_INVALID” (Google Chrome) und “Nicht vertrauenswürdiges Zertifikat” (Nextcloud App). Kurrioserweise tritt das ganze nicht auf, wenn ein anderes Gerät im Netzwerk bereits eine Verbindung zur Nextcloud hält.

Ich bin ziemlich ratlos und vermute den Fehler in der Konfiguration meiner Nextcloud, aber ich habe keine Ahnung wo ich anfangen soll. Wäre super, wenn mir jemand dabei helfen könnte das ganze zuverlässig zum Laufen zu bekommen.

Hier noch ein paar Eckdaten zu meinem Netzwerk:

Nextcloud als LXC auf einem lokalen Proxmox-Server
Ich habe eine DynDNS in der Fritzbox hinterlegt und einen Nginx Revers Proxy in einem anderen LXC unter Docer laufen, der das Zertifikat erstellt und auf die entsprechende SubDomain der DynDNS für Nextcloud verweist.
Technisch ist das Netzwerk aus Router>Repeater>Switch>Homeserver aufgebaut
Alle Dienste und Anwendungen sind aktuell

Reiner_Nippes · February 1, 2021, 12:16pm

zeigt er dir das zertifikat an und wer hat es ausgestellt?

ich mach an der stelle immer mal gerne ein curl -v https://nextcloud.dyndns/ um zu schauen, was da so kommt. ggf. noch ein -k für --insecure

xtim · February 2, 2021, 9:27am

Hey Reiner,

wenn ich mich mit der Nextcloud verbinden möchte, wird mir als Aussteller der Name meiner subdomain angezeigt. Und curl -v gibt folgendes aus:

curl -v https://meine.subdomain.duckdns.org
* Rebuilt URL to: https://meine.subdomain.duckdns.org
*   Trying meine.ip.v4.adresse...
* TCP_NODELAY set
* Connected to meine.subdomain.duckdns.org (meine.ip.v4.adresse) port 443 (#0)
* schannel: SSL/TLS connection with meine.subdomain.duckdns.org port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 195 bytes...
* schannel: sent initial handshake data: sent 195 bytes
* schannel: SSL/TLS connection with meine.subdomain.duckdns.org port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with meine.subdomain.duckdns.org port 443 (step 2/3)
* schannel: encrypted data got 2873
* schannel: encrypted data buffer: offset 2873 length 4096
* schannel: sending next handshake data: sending 93 bytes...
* schannel: SSL/TLS connection with meine.subdomain.duckdns.org port 443 (step 2/3)
* schannel: encrypted data got 274
* schannel: encrypted data buffer: offset 274 length 4096
* schannel: SSL/TLS handshake complete
* schannel: SSL/TLS connection with meine.subdomain.duckdns.org port 443 (step 3/3)
* schannel: stored credential handle in session cache
 
> GET / HTTP/1.1
> Host: meine.subdomain.duckdns.org
> User-Agent: curl/7.55.1
> Accept: */*

* schannel: client wants to read 102400 bytes
* schannel: encdata_buffer resized 103424
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: encrypted data got 1680
* schannel: encrypted data buffer: offset 1680 length 103424
* schannel: decrypted data length: 1651
* schannel: decrypted data added: 1651
* schannel: decrypted data cached: offset 1651 length 102400
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: decrypted data buffer: offset 1651 length 102400
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 1651
* schannel: decrypted data buffer: offset 0 length 102400
< HTTP/1.1 302 Found
< Server: openresty
< Date: Tue, 02 Feb 2021 09:11:28 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 0
< Connection: keep-alive
< Referrer-Policy: no-referrer
< X-Content-Type-Options: nosniff
< X-Download-Options: noopen
< X-Frame-Options: SAMEORIGIN
< X-Permitted-Cross-Domain-Policies: none
< X-Robots-Tag: none
< X-XSS-Protection: 1; mode=block
< Set-Cookie: kryptische=zeichenfolge; path=/; secure; HttpOnly; SameSite=Lax
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
 
Ein paar weitere Zeilen, bei denen ich nicht weiß, ob ich sie hier posten sollte.
 
< Location: https://meine.subdomain.duckdns.org/index.php/login
< Strict-Transport-Security: max-age=15552000; includeSubDomains;
< X-Served-By: meine.subdomain.duckdns.org

* Connection #0 to host meine.subdomain.duckdns.org left intact.

So wie ich das verstehe, läuft was beim Verweis auf das Zertifikat falsch. Leider fehlt mir jede Idee, wo ich ansetzen soll.

Reiner_Nippes · February 2, 2021, 10:25am

irgendwie fehlt da was.

ich meinte folgenden block:

* Server certificate:
*  subject: CN=help.nextcloud.com
*  start date: Jan 29 23:18:28 2021 GMT
*  expire date: Apr 29 23:18:28 2021 GMT
*  subjectAltName: host "help.nextcloud.com" matched cert's "help.nextcloud.com"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.

in dem beispiel vom dem foren server steht: issuer: C=US; O=Let's Encrypt; CN=R3

p.s.: könntest du bitte mit markdown richtig quoten? drei ``` vor und hinter dem text. sonst interpretiert die foren software die * und > als formatierungszeichen.

xtim · February 2, 2021, 11:40am

Ich kann dir leider nicht ganz folgen, ich weiß nur, dass ich den Befehl gerade noch mal in meiner win10 konsole eingegeben habe und jetzt das rauskam:

curl -v https://meine.subdomain.duckdns.org
* Rebuilt URL to: https://meine.subdomain.duckdns.org/
*   Trying meine:ip:v6:adresse . . .
* TCP_NODELAY set
* Connected to meine.subdomain.duckdns.org (meine:ip:v6:adresse) port 443 (#0)
* schannel: SSL/TLS connection with meine.subdomain.duckdns.org port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 195 bytes...
* schannel: sent initial handshake data: sent 195 bytes
* schannel: SSL/TLS connection with meine.subdomain.duckdns.org port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with meine.subdomain.duckdns.org port 443 (step 2/3)
* schannel: encrypted data got 1319
* schannel: encrypted data buffer: offset 1319 length 4096
* schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - Die Zertifikatkette wurde von einer nicht vertrauenswürdigen Zertifizierungsstelle ausgestellt.
* Closing connection 0
* schannel: shutting down SSL/TLS connection with meine.subdomain.duckdns.org port 443
* schannel: clear security context handle
curl: (77) schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - Die Zertifikatkette wurde von einer nicht vertrauenswürdigen Zertifizierungsstelle ausgestellt.

Vielleicht kannst du dir so besser ein Bild davon machen.

Reiner_Nippes · February 2, 2021, 2:17pm

kannst du noch curl -v -k https://meine.subdomain.duckdns.org ausprobieren? ohne -k kommt keine verbindung zustande. dann zeigt er wohl auch nicht an, wer das zertifikat ausgestellt hat.

devnull · February 2, 2021, 2:50pm

Ist denn das SSL-Zertifikat hierfür ausgestellt?
Funktioniert das mit genau dem Namen von außen?

Ruf die Adresse mal mit Mozilla Firefox auf, wählre rechte Maustause “Elemente untersuchen” und gehe auf “Netzwerkanalyse”. Ist da vielleicht irgendwie doch noch ein Redirect oder sonstwas auf die IP-Adresse oder so? Um alle Schritte zu sehen rufe z. B. erst Google auf, dann die Netzwerkanalyse und gebe dann die URL oben im Browser ein.

xtim · February 10, 2021, 4:34pm

Hey ihr zwei und sorry, für die späte Antwort. Ich habe in der Zwischenzeit noch einen Bitwardenserver aufgesetzt und habe dort das gleiche Problem. Komischer Weise tritt der Fehler nur auf, wenn mein PiHole an ist. Somit scheinen meine Nextcloud und Netzwerkconfiguration okay zu sein.
Der Versuch einen Redirect auf die lokale IP meiner Nextcloud, bei dem Aufruf der Dyndns im lokalen Netzwerk hat leider nicht funktioniert. Habt ihr eine Idee, wie man beides parallel zum Laufen bekommen kann oder sollte ich mit meinem Problem lieber in das PiHole Forum umziehen?
Vielen Dank für alle, die sich an der Fehlerbehebung beteiligt haben!

Reiner_Nippes · February 10, 2021, 8:06pm

du meinst deinem dns server so einzustellen, dass er eine 192.er zurückgibt, wenn du die fqdn der nextcloud intern auflöst?

was liefert denn curl -v -k https://meine.subdomain.duckdns.org zurück. und was liefert nslookup meine.subdomain.duckdns.org respektive dig meine.subdomain.duckdns.org, wenn du einen linux client hast.

Rookie · March 24, 2021, 4:46pm

Hallo zusammen, ich habe auch ein SSL-Verbindungsproblem
Ich erreiche jedoch über mein Netz NC und kann mich über SSH problemlos verbinden!

Jedoch is des bei mir ein bisschn verzickter …
Ich habe:
NextCloudPi version|v1.35.0
NextCloudPi image|NextCloudPi_03-28-20
distribution|Raspbian GNU/Linux 10

dazu kommt noch das ich eine ds-lite Anschluss habe bei Unitymedia bzw. Vodafone. Daher habe ich einen Proxy bei IONOS laufen der mir die ip4 auf ip6 umleitet.
Bisher habe ich alles ohne SSL-Zertifikat (Let’s Encrypt) hinbekommen und die Fehlermeldungen in Browser usw. alle mit “Ich akzepiere das Risiko” umgehen können. Doch seit neustem geht auch die NC-App nicht mehr. Und ein Aufruf mittels Browser auf meine Domain funktioniert überhaupt nicht mehr.

Ich bin derzeit ratlos und muss aber auch gestehen das ich Hilfe hatte mit dem Proxy bei IONOS.

Kann mir da einer mal einen Rat geben was ich nun machen soll?
THX für die Hilfe

submentis · June 20, 2022, 11:42am

Hallo zusammen!
Meine Frustration führt dazu, dass ich mich hier anmelde und auf Hilfe hoffe.
Problem: Nextcloud ist nur von außen erreichbar. Intern zeigt er ein Zertifikatfehler an.
Infrastruktur: Nextcloud Server 24.0.1 per Snap auf einem Linux Ubuntu Server 20.04. Der Server (x.1) hängt wie auch alle anderen clients im gleichen Subnet 192.168.70.x an einer Telekom Digitalisierungsbox aka Zyxel (x.2). Seit gestern nun an einer FritzBox 7530 ax (ebenfalls IP x.2). Telekom-DSL 250/40MBit ohne feste IP. DynDNS über Srvdns.de, dazu eigene .de Domain, die auf Srvdns per DNS A und AAAA verweist.
Das ganze vor ca. 3 Monaten neu aufgesetzt. Zyxel Router hat Weiterleitung Port 80 und 443 auf den Server. Lets encrypt lief problemlos durch, Zertifikat erstellt.
Von außen alles kein Problem, funktioniert einwandfrei, die Browser geben keinerlei Warnung aus.
Seit zwei Wochen aber (also 192.168.70.x) ist der Zugriff intern nicht mehr möglich, an irgendein Zutun erinnere ich mich nicht. Wegen wenig Zeit habe ich meine Cloud nur auf der Arbeit genutzt
Gestern wollte ich das Problem lösen, aber trotz Reboot Client, Server, Router ging nix. Ich konnte aber sehen, dass ich beim Zugriff ein Zyxel Zertifikat sehen konnte, also das Routereigene.
Ich habe daraufhin ein neues Zertifikat für Nextcloud erstellt, es lief völlig problemlos durch.
Die FB lag da, kurzerhand installiert, DynDNS und Portweiterleitung gesetzt und siehe da, es lief. Ich hatte perfekt Zugriff von intern (!) auf die Cloud.
Heute morgen nun sagt mir sowohl Laptop wie iPad, geht nicht, weil Zertifikatfehler. Diesmal Zertifikat von der FB. Von außen allerdings problemlos Zugriff auf die Cloud.
Ich hab Euer Forum jetzt 3x durch und bei Google alles mögliche angegeben. Wahrscheinlich ist es ein Netzwerkproblem mit den Routern, aber vielleicht weiss jemand Rat?

Danke im Voraus,
C

Mornsgrans · June 21, 2022, 5:56am

Trage mal testweise in der Fritzbox den Nextcloud Server unter
Heimnetz - Netzwerk - Netzwerkeinstellungen - Weitere Einstellungen
mit der vollständigen Adresse im Feld DNS-Rebind-Schutz ein.

submentis · June 22, 2022, 10:51pm

Hallo!
habe ich direkt mal eingegeben. Ich habe beide Adressen eingegeben, die DynDNS Adresse, aber auch meine eigene Domain.
Bei Aufruf gelange ich nun auf die Anmeldeseite der Fritzbox für externe User (FB möchte User und PW). Also wenn ich intern bin. Rufe ich direkt die FB auf, möchte er wie immer nur ein PW.
Bin ich extern, so funktioniert alles super.

Ich setzte jetzt noch testweise meinen Server als exposed host in die FB in der Hoffnung, dass das etwas ändert.
Geht das nicht, dann würde ich SSL komplett abschalten und über Wireguard gehen. (Natürlich wären Port 80 und 443 ganz dicht und der Server aus dem Internet direkt gar nicht mehr erreichbar )

Danke für Eure Hilfe,
C