Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

  • »Gerrit« ist männlich
  • »Gerrit« ist der Autor dieses Themas

Beiträge: 30

Registrierungsdatum: 09.02.2013

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

1

13.10.2019, 10:09

Nextcloud nicht mehr über Internet erreichbar

Hallo,


auf meinem Server laufen folgende Dinge seit etwa 10 Monaten:
  1. Nextcloud 15.0.2
  2. Subsonic
  3. Ubuntu 18.04.3 LTS
  4. Apache/2.4.29
  5. PHP version 7.2.19
----------------


Auf Nextcloud (Port 80/443) und Subsonic(32400) kann ich im Netzwerk problemlos zugreifen. Aus dem Internet konnte ich über no-ip und eine Portweiterleitung auch problemlos zugreifen.Seit gestern funktioniert der Zugriff für Nextcloud nun nur noch aus dem lokalen Netzwerk. Beim Zugriff aus dem Internet bekomme ich ein timeout. Subsonic funktioniert weiterhin problemfrei - die Portweiterleitung funktioniert daher denke ich.

Kann mir hier jemand weiterhelfen?
Vielen Dank!
apache2ctl configtest

Quellcode

1
2
3
4
AH00526: Syntax error on line 23 of /etc/apache2/sites-enabled/001-server.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/server.hopto.org/fullchain.pem' does not exist or is empty
Action 'restart' failed.
The Apache error log may have more information.

Apache error.log:

Quellcode

1
2
3
[Sun Oct 13 06:25:04.077998 2019] [ssl:warn] [pid 1206] AH01909: server.hopto.org/:443:0 server certificate does NOT include an ID which matches the server name
[Sun Oct 13 06:25:04.078311 2019] [mpm_prefork:notice] [pid 1206] AH00163: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 configured -- resuming normal operations
[Sun Oct 13 06:25:04.078322 2019] [core:notice] [pid 1206] AH00094: Command line: '/usr/sbin/apache2'

Die Ausgabe '/etc/letsencrypt/live/server.hopto.org/fullchain.pem' kann ich nicht nachvollziehen, da unter dem Link eine Verweisung auf eine nicht leere Datei besteht.
Am Zertifikat kann es eigentlich nicht liegen. certbot certificates:

Quellcode

1
2
3
4
5
6
7
8
9
10
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Found the following certs:
  Certificate Name: server.hopto.org
	Domains: server.hopto.org
	Expiry Date: 2019-12-10 08:31:33+00:00 (VALID: 58 days)
	Certificate Path: /etc/letsencrypt/live/server.hopto.org/fullchain.pem
	Private Key Path: /etc/letsencrypt/live/server.hopto.org/privkey.pem
-------------------------------------------------------------------------------

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Gerrit« (16.10.2019, 21:52)


Beiträge: 1 131

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian bullseye-testing / 5.10.0-10-amd64

  • Nachricht senden

2

13.10.2019, 12:30

Hmm. Im Moment bleibt mir nur der Tip, mal die Rechte der .pem Datei zu prüfen. Passt da vom Eigentümer und den Rechten alles?
Heute ist keiner da! Komm morgen wieder. :-)

  • »Gerrit« ist männlich
  • »Gerrit« ist der Autor dieses Themas

Beiträge: 30

Registrierungsdatum: 09.02.2013

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

3

13.10.2019, 17:44

Hallo,
die Dateien dort haben alle die selben Rechte:

Quellcode

1
-rw-r--r-- 1 root root 3566 Sep 11 09:31 fullchain5.pem

Sieht doch ganz ok aus oder?
Ich habe seitdem nichts mehr geändert, lediglich den Server abgeschaltet und nun wieder angestellt. Nun gibt apach2ctl configtest keine Fehler mehr aus. Wie kann sowas sein?

4

13.10.2019, 19:46

Hat der Apache Lesezugriff in /etc/ und darunter? (Ist ja an und für sich schon wenig empfehlenswert, aber wenn das Zertifikat nunmal dort abgelegt wurde...)

Nachdem jetzt kein Cofig-Fehler mehr gemeldet wird, was steht im Log?
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

  • »Gerrit« ist männlich
  • »Gerrit« ist der Autor dieses Themas

Beiträge: 30

Registrierungsdatum: 09.02.2013

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

5

13.10.2019, 22:02

Das log hat sich nicht groß geändert:
apache error log

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[Sun Oct 13 12:27:00.896986 2019] [ssl:warn] [pid 1002] AH01909: server.hopto.org/:443:0 server certificate does NOT include an ID which matches the server name
[Sun Oct 13 12:27:04.695808 2019] [ssl:warn] [pid 1263] AH01909: server.hopto.org/:443:0 server certificate does NOT include an ID which matches the server name
[Sun Oct 13 12:27:04.713345 2019] [mpm_prefork:notice] [pid 1263] AH00163: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 configured -- resuming normal operations
[Sun Oct 13 12:27:04.713414 2019] [core:notice] [pid 1263] AH00094: Command line: '/usr/sbin/apache2'
[Sun Oct 13 12:41:45.667307 2019] [mpm_prefork:notice] [pid 1263] AH00169: caught SIGTERM, shutting down
[Sun Oct 13 12:41:45.782805 2019] [ssl:warn] [pid 2024] AH01909: server.hopto.org/:443:0 server certificate does NOT include an ID which matches the server name
[Sun Oct 13 12:41:45.835536 2019] [ssl:warn] [pid 2036] AH01909: server.hopto.org/:443:0 server certificate does NOT include an ID which matches the server name
[Sun Oct 13 12:41:45.844081 2019] [mpm_prefork:notice] [pid 2036] AH00163: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 configured -- resuming normal operations
[Sun Oct 13 12:41:45.844154 2019] [core:notice] [pid 2036] AH00094: Command line: '/usr/sbin/apache2'
[Sun Oct 13 12:42:25.995527 2019] [mpm_prefork:notice] [pid 2036] AH00169: caught SIGTERM, shutting down
[Sun Oct 13 15:34:27.930431 2019] [ssl:warn] [pid 946] AH01909: server.hopto.org/:443:0 server certificate does NOT include an ID which matches the server name
[Sun Oct 13 15:34:31.133239 2019] [ssl:warn] [pid 1210] AH01909: server.hopto.org/:443:0 server certificate does NOT include an ID which matches the server name
[Sun Oct 13 15:34:31.146818 2019] [mpm_prefork:notice] [pid 1210] AH00163: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 configured -- resuming normal operations
[Sun Oct 13 15:34:31.146888 2019] [core:notice] [pid 1210] AH00094: Command line: '/usr/sbin/apache2'
[Sun Oct 13 15:40:23.613055 2019] [mpm_prefork:notice] [pid 1210] AH00173: SIGHUP received.  Attempting to restart
[Sun Oct 13 15:40:23.673523 2019] [ssl:warn] [pid 1210] AH01909: server.hopto.org/:443:0 server certificate does NOT include an ID which matches the server name
[Sun Oct 13 15:40:23.681262 2019] [mpm_prefork:notice] [pid 1210] AH00163: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 configured -- resuming normal operations
[Sun Oct 13 15:40:23.681322 2019] [core:notice] [pid 1210] AH00094: Command line: '/usr/sbin/apache2'

Soweit ich es verstehe, hat nur root dort leserechte (Hat ja bisher auch funktioniert). Sollte ich den Besitzer in root:www-data ändern und der Gruppe leserechte geben?
Vielen Dank!

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Gerrit« (13.10.2019, 22:20)


6

13.10.2019, 22:09

Wenn es bisher und mit den gleichen Rechten auch geklappt hat, würde ich vorerst nichts ändern, sondern erstmal die Sache mit dem unpassenden Server-Namen im Zertifikat klären. Das steht ja im Log als Grund warum er nicht startet.

Die Zertifikate an einen weniger kritischen Ort verlegen kannst du später immer noch, wenn das Grundproblem einmal behoben ist.

Fällt dir übrigens an Zeile 6+7 in deinem Ausschnitt etwas auf? -> Falsch anonymisiert, klar. Wenn du aber verschleierte Angaben lieferst, bist du in dem Punkt auf dich allein gestellt.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

  • »Gerrit« ist männlich
  • »Gerrit« ist der Autor dieses Themas

Beiträge: 30

Registrierungsdatum: 09.02.2013

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

7

13.10.2019, 22:21

Wenn es bisher und mit den gleichen Rechten auch geklappt hat, würde ich vorerst nichts ändern, sondern erstmal die Sache mit dem unpassenden Server-Namen im Zertifikat klären. Das steht ja im Log als Grund warum er nicht startet.

Die Zertifikate an einen weniger kritischen Ort verlegen kannst du später immer noch, wenn das Grundproblem einmal behoben ist.

Fällt dir übrigens an Zeile 6+7 in deinem Ausschnitt etwas auf? -> Falsch anonymisiert, klar. Wenn du aber verschleierte Angaben lieferst, bist du in dem Punkt auf dich allein gestellt.
... sorry, da habe ich einen Punkt vergessen. Ich habe es noch gerade gezogen.

8

13.10.2019, 22:45

Schön und gut, aber wir können so nicht sehen ob das Zertifikat zu dem Servernamen passt. Du musst alleine herausfinden was ihm daran nicht gefällt.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

  • »Gerrit« ist männlich
  • »Gerrit« ist der Autor dieses Themas

Beiträge: 30

Registrierungsdatum: 09.02.2013

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

9

15.10.2019, 21:49

...sehe ich ein.
Das Problem war recht einfach behoben, indem in der entsprechenden conf Datei unter /etc/apache2/sites-available, ServerName und ServerAlias so wie folgt definerte - im Internet findet man da Anleitungen.

Quellcode

1
2
ServerName www.server.de
ServerAlias server.de

Jetzt ist mein Fehler in der log des Apache2 weg, aber die Seite kann ich trotzdem nicht mehr aus dem Internet aufrufen. Einen Timeout erhalte ich weiterhin. An welchen Stellen kann ich denn noch nachsehen?

Quellcode

1
2
[Tue Oct 15 21:43:11.675172 2019] [mpm_prefork:notice] [pid 965] AH00163: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 configured -- resuming normal operations
[Tue Oct 15 21:43:11.702092 2019] [core:notice] [pid 965] AH00094: Command line: '/usr/sbin/apache2'

10

16.10.2019, 14:19

Vielleicht leitet no-ip nicht an deine IP weiter.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

  • »Gerrit« ist männlich
  • »Gerrit« ist der Autor dieses Themas

Beiträge: 30

Registrierungsdatum: 09.02.2013

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

11

16.10.2019, 21:50

... das naheliegenste war es mal wieder!
Ich habe die Portweiterleitung nie hinterfragt, da Port 22,80 und 32400 weitergeleitet werden konnten. Nach einem Neustart des Routers geht es jetzt wieder!
Ich möchte mich bei euch bedanken - obwohl das Problem wo anders lag, habe ich wieder etwas gelernt!

12

18.10.2019, 20:18

Wenn du eine rewrite-rule zur Umleitung von HTTP auf HTTPS hättest, hättest du es bei einem Aufruf ohne https:// auch bemerken können. Springt der Browser von selbst auf https://, dann ist der Endpunkt jedenfalls erreichbar. Kommt weiter nichts, liegt der Fehler irgendwo innerhalb ab Port 443. Damit ist die Hälfte der Fehlerquellen ausgeschlossen und die URL kann man auch bequemer eintippen. ;)
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

  • »Gerrit« ist männlich
  • »Gerrit« ist der Autor dieses Themas

Beiträge: 30

Registrierungsdatum: 09.02.2013

Derivat: Ubuntu

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

13

22.10.2019, 20:39

Guter Hinweis,

das werde ich mir mal ansehen!

14

26.10.2019, 21:47

Es ist ganz simpel:

Quellcode

1
2
3
        RewriteCond %{HTTPS} !=on
        RewriteCond %{ENV:HTTPS} !=on
        RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]


Eigentlich ist so eine Regel der einzig gute Grund, einen Dienst auf Port 443 und Port 80 anzubieten. Ansonsten könnte man sich den Zertifikats-Firlefanz ja sparen, wenn der gleiche Dienst durch einfaches Eintippen in die Adresszeile auch unverschlüsselt zu erreichen ist.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl