Zertifikat-Fehler trotz aktuellem Zertifikat von Let's Encrypt

[Moeffz]

Moin,

ich habe folgendes Fehlerbild:
Wenn ich die Photostation oder Drive über Opera aufrufe, erhalte ich den Fehler NET::ERR_CERT_AUTHORITY_INVALID, über Firefox erhalte ich einen ähnlichen Fehler. Selbst das iPhone meldet mir eine nicht vertrauenswürdige Verbindung. Der Aufruf der Diskstation über Port 4001 hingegen funktioniert tadellos.

Meine Konfiguration ist wie folgt:
Auf dem Router (FritzBox) habe ich Portfreigaben für die Ports 80,443 und 4001 für IPv4 und IPv6 eingerichtet. Auf der Diskstation sind diese Ports freigeschaltet.
Ich hatte auf der Diskstation ein Zertifikat von LE, welches abgelaufen war (Der Refresh fiel in eine Zeit, in der die DS offline war.). Dieses Zertifikat habe ich einfach erneuert und als Standardzertifikat eingerichtet.

Wenn ich die Startseite der Photostation aufrufe, werde ich auf die Startseite der FritzBox umgeleitet. Als Zertifikat wurde mir das von der FritzBox selbst erstellte angezeigt. Erwartet hätte ich hier das Zertifikat von LE. Daraufhin habe ich in der FB das LE-Zertifikat importiert, erreiche dann aber gar nichts mehr.

Wo kann ich hier noch etwas überprüfen?

Update:
Der Fehler tritt anscheinend nur von intern auf. Das deutet dann wohl auf einen Konfigurationsfehler in der FritzBox hin.

 

[Fusion]

Wie lautet die exakte URL bei welchem Aufruf von welchem Gerät?
Mit dieser Matrix sollte sich der Fehler schnell lokalisieren lassen.

Das 'Standardzertifikat' ist nur jenes welches für neu installierte Dienste als Voreinstellung verwendet wird.
Um ein Zertifikat als Standard für alle nicht anderweitig definierten Dienste zu setzen musst du es unter 'Konfiguration' dem Dienst 'Systemvoreinstellung' zuweisen.

 

[Moeffz]

Moin,

danke für die schnelle Reaktion

Die URLs sind:
https://<meine-domain>:4001 für DS,
https://<meine-domain>/photo für die Photostation sowie
https://<meine-domain>/drive .

Erstere Seite lässt sich aufrufen, zweitere und drittere nicht.

Wenn ich aus dem DSM heraus Photostation und Drive aufrufe, werden folgende Links verwendet:
https://<meine-domain>/photo/login.php?sid=<sid>&usr=admin&SynoToken=<SynoToken>
https://<meine-domain>:4001/?launchApp=SYNO.SDS.Drive.Application

Der erstere Aufruf klappt nicht, der zweite schon.

Das Zertifikat ist in der Konfiguration allen aufgeführten Diensten zugewiesen (incl. Synology Drive Server und Systemvoreinstellung). Auf der Synology habe ich auch kein weiteres Zertifikat.

 

[Fusion]

Was heißt "lässt sich nicht aufrufen" im Detail, welche Fehler / Warnungen werden angezeigt?
Aufruf aus dem LAN/WLAN oder von extern (z.B. Mobilfunknetz)?

Systemsteuerung > Anwendungsportal ist der Alias /drive aktiviert?

Hast du <meine-domain> irgendwo im DSM eingetragen? Wenn ja, wo?

Gehörst also auch zu der Gruppe der "Syno Zertifikatslöscher". Ist wohl der Deutsche? Putzwahn. lol

 

[Wollfuchs]

erfolgt der aufruf aus dem selben netz oder "von aussen"

was bringt https://deineip:4001 und jeweils /photo und so aus dem lan?

 

[Moeffz]

Moin,

der Aufruf erfolgt aus dem LAN mit Opera.

Die Fehlermeldung lautet im Detail und ist in allen drei Fällen identisch:
Dieser Server konnte nicht beweisen, dass er <meine-domain> ist. Sein Sicherheitszertifikat wird vom Betriebssystem Ihres Computers als nicht vertrauenswürdig eingestuft. Mögliche Gründe sind eine fehlerhafte Konfiguration oder ein Angreifer, der Ihre Verbindung abfängt.

NET::ERR_CERT_AUTHORITY_INVALID

Systemsteuerung > Anwendungsportal ist der Alias /drive aktiviert?

Ja.

Hast du <meine-domain> irgendwo im DSM eingetragen? Wenn ja, wo?

Fiese Frage. Ich habe mal gesucht, aber (noch) nichts gefunden. Insbesondere unter Konnektivität und in der Webstation habe ich nichts gefunden. Gibt es im Info-Center unter den Diensten einen Anhaltspunkt, wie es aussehen sollte, damit es korrekt ist?

Gehörst also auch zu der Gruppe der "Syno Zertifikatslöscher". Ist wohl der Deutsche? Putzwahn. lol

Ich bin verzweifelt und habe schon so einiges ausprobiert. Als ich gesehen habe, dass ein selbsterstelltes Zertifikat bei obiger Fehlermeldung angezeigt wird, bin ich dem nachgegangen und habe nicht benötigte gelöscht.

Hilft eventuell der Hinweis, dass ich DynDNS über die FritzBox mache oder ist das eine falsche Fährte? Wenn ich ein nslookup auf die Domäne mache, lande ich bei der FritzBox.

Nachtrag:
Im Internet Explorer habe ich das gleiche Problem. Die Fehlermeldung dort lautet:
Das Sicherheitszertifikat dieser Website wurde nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt.
Anmerkung: Logisch. Er zeigt auch das von der FirtBox selbst erstellte Zertifikat an.
Dort kann ich dann das Laden der Website fortsetzen und lande auf einer Fehlerseite der FritzBox. Meldung:
Die angegebene URL wurde nicht gefunden. Sie werden auf die Startseite der Fritz!Box umgeleitet.

Von extern habe ich es mit dem Safari getestet. Dort lautet die Fehlermeldung:
Safari kann nicht geöffnet werden, da Safari keine sichere Verbindung zum Server herstellen konnte.

 

[Wollfuchs]

Die Fehlermeldung lautet im Detail und ist in allen drei Fällen identisch:
Dieser Server konnte nicht beweisen, dass er lottelene.de ist. Sein Sicherheitszertifikat wird vom Betriebssystem Ihres Computers als nicht vertrauenswürdig eingestuft. Mögliche Gründe sind eine fehlerhafte Konfiguration oder ein Angreifer, der Ihre Verbindung abfängt.

NET::ERR_CERT_AUTHORITY_INVALID

da kommt von aussen ein wunderbar gueltiges Zertifikat ..
Lets Encrypt .. Zert Kette ok .. alles fluffig und kommt direkt auf einem "nicht eingerichteten" Webstation Server raus.

Von Innen also LAN kommt murks? ... dann ist der port 80 und 443 direkt auf den webserver umgebogen?

 

[blurrrr]

Da Du jetzt auch die öffentliche Domain mit der Fehlerbeschreibung gepostet hast... also von aussen sieht das soweit alles gut aus

 

[Fusion]

Also, ich habe ebenfalls keinerlei Probleme in Firefox, Opera oder Chrome deine Seiten aufzurufen. Egal ob /drive oder /photo oder die Dummy Webseite der Web Station für / oder dein DSM (4001).
Einzig wird bemängelt, dass wenn man die Domain für sich aufruft, bsp. <meine-domain> er nur auf http://<meine-domain> landet. Und hier eben http an sich als "nicht sicher", da unverschlüsselte Übertragung, eingestuft wird.
Da könnte man je nach nginx oder Apache noch mit einer Direktive oder htaccess nacharbeiten, dass immer auf https umgeleitet wird.

Die fiese Frage nach <meine-domain> bezog sich darauf, dass wenn diese irgendwo als benutzerdefinierte Domain oder Reverse Proxy eingetragen gewesen wäre (was sie offensichtlich nicht ist), dass dann nur der ausgewählte Dienst darüber erreichbar wäre und andere Dienste wie die Photo Station eingeschränkt bis gar nicht mehr, weil der Alias /photo dann in einem anderen Webserver Host Kontext ausgewertet wird.

 

[ottosykora]

photo und driver sind auch bestens da,

 

[Moeffz]

*hust*
Danke für den Hinweis. Meine Domain habe ich wieder ersetzt.

Da ich intern viel mit der Photostation arbeite, ist der Fehler für mich sehr ärgerlich.

Von Innen also LAN kommt murks? ... dann ist der port 80 und 443 direkt auf den webserver umgebogen?

Was genau meinst Du hier?

 

[Wollfuchs]

wenn du nur von innen den hinweis bekommst, dass der server nicht beweisen kann, dass er derjenige ist .. dann stimmt eventuell die antwort nicht, bzw. die frage ist falshc gestellt an die auth stelle.

du rufst einen server auf, der du ja selber bist .. fraegst also gegen deine fritzbox "hey, wer ist lena und ist die auch sauber" und die frotz bix sagt "?? das bin doch ich (also mein netz) .. dann bounce ich dich mal retour, namen aufloesen und korrekt routen kann ich ja".

nun landest du per nginx auf deinem server, genauso als waerst du per ip dorthin marschiert. und dafuer gibts kein zert.

erst wenn du komplett aus deinem netz raus gehst und von aussen eine abfrage machst, kriegst du die korrekte antwort.
ich tippe daher auf das gleiche problem, dass man hat, wenn man ein LE nutzt und alle schotten dicht macht danacht.
das zert laeuft ab, ist 3 monate fein und dann moeeeep.

wenn also deine anfrage raus geht und nicht mehr zu dir korrekt zurueck kommt weil die antwort an port 80/443 geht, landet sie ja bei lena.
du bist aber nicht lena .. also ja schon .. aber eigentlich ..

otto hat bestimmt eine hausmetapher am start .. irgendwas mit "du kannst solange klingeling bruellen in deinem keller wie du willst, wenn du nicht vor die tuer gehst, hoert dich niemand schreien".

 

[Moeffz]

Ich müsste also meine internen Aufrufe erst nach extern umleiten, um dann über extern problemlos auf meine internen Seite zugreifen zu können, korrekt? Wie richte ich das denn ein?
Was mich nur noch irritiert ist, dass es für die DSM-Startseite problemlos klappt.

 

[Wollfuchs]

naja .. die dsm ist die mama ... der webserver ist der spross einer kurzen unbedachten affaere .. und eigentlich auch
nicht ehelich .. und von daher

wenn du die ds mal fuer 1 min in die dmz packst .. dann sollten alle brav sagen "ohhh jaaaaa, so ein tolles baby".
dann wieder ins lan und erst in 3 monaten heisst es wieder " ... oooh ... hmmm .. huebscher kinderwagen, ist der neu?"

 

[ottosykora]

Ich müsste also meine internen Aufrufe erst nach extern umleiten, um dann über extern problemlos auf meine internen Seite zugreifen zu können, korrekt?

nein, intern kannst du die interne IP oder den Namen der DS benutzen. Also etwa wie http://192.168.1.2:5000 für DSM, oder htpp://DISKSTATION:5000


mit der externen Adresse, also ddns zum Bsp, von innnen anrufen geht nicht immer, die Browser blockieren so was.
Bei einigen Routern kann man die ddns Adresse unter rebind schutz Ausnahmen eintragen, dann geht es wieder

Man kann auch die hosts Datei in Windows bearbeiten und dort den ddns Namen eintragen.

 

[Moeffz]

Ich habe es nun über die /etc/hosts gelöst. Die Variante mit der Rebind-Ausnahme in der Fritz!Box wäre technisch auch möglich gewesen. Die habe ich aber nicht probiert.

Vielen Dank!