Zertifikat lässt sich nicht erneuern

[ottosykora]

Wenn er nicht weiß, wo er anfangen soll, nimmt er die bekannten wie 80 und 443

Und? Server sind dazu da.
Wenn man keine Webserver mehr betreiben soll, oder bei jedem erst mit Portscann erfahren muss wo dieser erreichbar ist, dann braucht es den www nicht mehr.

 

[Benares]

@NSFH, https ist Standard, da hast du Recht.
Aber poste doch bitte mal den Link zu wenigstens einer professionellen Web-Site, die http sperrt und nicht einfach auf https umleitet.

 

[ottosykora]

Und dann ist der Satz "aber man kann nicht erwarten, dass alle einen Webserver immer mit https://.... ansprechen...." so daneben wie er nur falsch sein kann. Standard heute ist HTTPS ob das gefällt oder nicht.

das ist doch kaum möglich. Leute geben irgendetwas ein, eine Domain und kaum jemand gibt sich die Mühe vorher noch https:// einzugeben. Sicher gibt es da einzelne Leute die das so machen, aber das kann man wirklich nicht von Besuchern eines Servers erwarten. Da würde Internet ziemlich zusammenbrechen.
Ich kenne niemanden, auch unter IT Leuten, der vor jeder Webseite fleissig https:// eintippt.

 

[Monacum]

Server sind dazu da.

Ich habe hier schon ein paar mal gelesen, dass ein NAS kein Server ist.

Wenn man keine Webserver mehr betreiben soll, oder bei jedem erst mit Portscann erfahren muss wo dieser erreichbar ist, dann braucht es den www nicht mehr.

Du setzt wieder ein persönliches Gerät wie ein NAS mit irgendeiner x-beliebigen Seite im WWW gleich; es geht auch nicht darum, keine Web Server mehr zu betreiben, was soll das für eine Argumentation sein? Ich habe oben lediglich argumentiert, dass man was aus meiner Sicht nicht machen sollte und das für eine Internetseite andere Voraussetzungen gelten als für einen privaten Server mit privaten Daten. Mir geht es nicht darum, hier irgendwie irgendetwas vor zu schreiben und mir ist es auch egal, wer wie viele Ports warum offen hat.

das ist doch kaum möglich. Leute geben irgendetwas ein, eine Domain und kaum jemand gibt sich die Mühe vorher noch https:// einzugeben.

Deswegen schreibt er doch, dass das der Standard ist und dass Browser wie Chrome mittlerweile von sich aus standardmäßig die sichereren Verbindungen bevorzugen und sogar mit Warnhinweis antworten, wenn die Seite „nur“ in HTTP verfügbar ist. Damit, was ich einzugeben habe, hat das nichts zu tun.

 

[ottosykora]

es gibt kaum jemanden der https://youtube.com eingibt

meisten youtube.com aber es geht auch http://youtube.com etc
Das ist eine Funktion von dem Server eine Anfrage auf 80 entsprechend umzuleiten. Man kann nicht erwarten dass dies die Besucher machen.
Das hat mit Browser etc nichts zu tun.
Auch das Forum hier kann man via 80 anrufen und wird dann auf 443 umgeleitet. Das ist Standard.

 

[Monacum]

Wir reden aneinander vorbei.

Das hat mit Browser etc nichts zu tun.

Spoiler: Doch.

 

[Benares]

Deswegen schreibt er doch, dass das der Standard ist und dass Browser wie Chrome mittlerweile von sich aus standardmäßig die sichereren Verbindungen bevorzugen und sogar mit Warnhinweis antworten, wenn die Seite „nur“ in HTTP verfügbar ist

Du solltest vielleicht nicht alles nachplappern, ohne es vorher zu prüfen.
Auch moderne Browser sprechen erstmal http, wenn man ihnen in der URL nichts anderes sagt. Der Anbieter kann dann, neben der Umleitung, dem Browser z.B. auch über HSTS mitteilen, dass er auch https kann. Der Browser merkt sich das im Browser-Cache für eine gewisse Zeit (max-age) und versucht es künftig erst gar nicht mehr erst per http. Das hat aber nichts mit einer automatischen Bevorzugung von https zu tun.

 

[Ulfhednir]

Das Ganze entgleitet hier ein wenig. Es geht hier um die Beantragung eines Zertifikates und dessen Fehlerquelle. Hier die ACME Challenge.
Zumindest bei ACME-01 ist HTTP im Kern verpflichtend. Deshalb wäre das Ganze selbstverständlich eine Fehlerquelle.

Die HTTP-01 Challenge kann nur auf Port 80 durchgeführt werden. Erlauben von anderen Ports, würde die Challenge weniger sicher machen und ist nach dem ACME Standard nicht erlaubt.

https://letsencrypt.org/de/docs/challenge-types/

Hier muss man also keine Grundsatzdiskussion führen, ob das Freischalten von HTTP zum Weltuntergang führt.
Meine Herren, es wird hier Niemandem empfohlen HTTP für das allgemeine Surfen im Internet zu führen - sondern einzig und allein für die Beantragung von Lets Encrypt offen zu lassen. Selbstverständlich wird hier auch Niemandem empfohlen mit HTTP im öffentlichen WLAN auf die DS zuzugreifen. Wenn man hier generell ein Sicherheitsrisiko sieht, wäre die einzig logische Schlussfolgerung auch auf ein Portforwarding für HTTPS zu verzichten.

Wenn der Service / Webserver einen Exploit hat, spielt es keine Rolle, ob die aufgebaute Verbindung verschlüsselt ist oder nicht. Das einzige Problem mit der ACME über HTTP besteht bei einer potentiellen man-in-the-middle, wo der DS ein fehlerhaftes Zertifikat untergejubelt würde. Allerdings dürfte das Ganze aufgrund der fehlenden Vertrauensstellung letztlich auch scheitern, weil der Browser mir mitteilen dürfte, dass das Cert nicht von LE stammt.
Der Aufwand und Voraussetzungen sind nicht unerheblich - kurzum: Das Risiko hier ist überschaubar.

 

[synfor]

Ich habe hier schon ein paar mal gelesen, dass ein NAS kein Server ist.

Das ist falsch. Ein NAS ist ein Server mit Focus auf Storage.

 

[spline]

Hallo, ich würde das Thema gern noch mal aufgreifen.
Ich habe, nachdem ich pro Stunde bis zu 20 Anmeldeversuche hatte, entnervt die Ports 80 und 443 deaktiviert und meine eigenen Vergeben.
Seither ist endlich Ruhe. Natürlich habe ich ein sehr starkes Passwort und das Admin Konto deaktiviert. Dazu noch im Firewall eine sehr lange Liste mit "Bad -IP" und viele Länder ausgeschlossen. (Ich habe eine feste IP seit Jahren)
Klar, kommt man nicht einfach in mein System rein, doch diese bis zu 500 Anmeldeversuche lassen meinen Server auch nie ruhen, was das System belastet, Strom kostet und sinnlosen Traffic.

Jetzt wollte ich "endlich" auch https aktivieren. Leider lässt sich meine feste IP nicht über die Diskstation bei letsencrypt registrieren.
Also machte ich eine DDNS über Synology. Wo ich aber nicht die Ports eingeben kann. Ich kann also meine Diskstation nicht über xxxx.synology.me erreichen, sondern nur über xxxx.synology.me:55646.

Letsencrypt brauch aber blöderweise immer Port 80 offen.
Jetzt hab ich die Wahl:

1. Sicher per https aber alle 3 Monate daran denken das Zertifikat zu erneuern Port 80 öffnen, Prozess starten, Port 80 schliessen
2. Sicher per https aber Port 80 und 443 offen haben und wieder mit hunderten Anmeldeversuchen ärgern
3. auf https verzichten und weiter mit eigenen Ports schaffen, ruhe geniessen

Leider reichen meine bescheidenen Anwenderkenntnisse nicht um ein eigenes Zertifikat von eine kostenpflichtigen Stelle zu beantragen und einzufügen.

 

[EDvonSchleck]

Ein Zertifikat auf eine IP ist normal nicht vorgesehen. Das Zertifikat wird auf eine Domain ausgestellt.

Wenn du eine Fritz!Box hast, kannst du das Öffnen der Ports über ein Skript machen. Ich selbst nutze ac,me.sh, um die Zertifikate ohne Portfreigabe zu aktualisieren. Das ganze funktioniert über eine Schnittstelle. Die Aktualisierung wird automatisch nach 60 Tagen durchgeführt und man braucht kein Fritz!Box dafür. Acme.sh lässt sich nativ oder über Docker (nutze ich) installieren.

Beide Wege sind kostenlos. Ohne eine Verschlüsselung sollte man sein DS nicht ins Netz hängen. Besser ist noch über VPN die Verbindung aufzubauen. Gegen eine Verbindung über den Port 443 spricht nichts. Somit kannst du dir die Porteingabe sparen, nutzt den Reverse Proxy oder die Router NAT (IPv4) um die Anfrage auf den Port 55646 zu gelangen.

 

[spline]

"Leider"einen Asus mit Asuswrt-Merlin Software. Da weiss ich nicht wie Scripts gehen
Also bleibt nur Port 80 offen lassen (und 443?) und meine eigenen Ports und sorgenfrei sein, oder Port 80 zu und alle 3 Monate per Hand.
Komm ich dann noch ins System wenn das Script abgelaufen ist?

 

[EDvonSchleck]

Das Script was ich meine gibt es nur für die Fritz!Box. Das liegt auch an der Verbreitung hier.
Auf deinen AsusWRT läuft acme.sh ebenfalls: https://www.snbforums.com/threads/p...on-fork-asuswrt-merlin-374-43_48e2-lts.71145/

Ich ziehe jedoch wegen der Einfachheit Docker auf der DS vor. Welche DS hast du genau?

 

[spline]

DS916+

Docker könnte das für mich übernehmen?

 

[EDvonSchleck]

Ja würde funktionieren, nutze das selbst.

eventuell ist die Aussage von Synology für den DDNS Dienst für dich interessant: https://www.synology-forum.de/threa...ng-synology-ssl-zertifikatserneuerung.123876/

 

[spline]

Gibt es für Docker eine Anleitung für nicht studierte Admins?

 

[EDvonSchleck]

https://www.christosgeo.com/2022/02/03/renew-lets-encrypt-certificates-on-synology-using-acme-sh/

Alternativ über die Aufgabensteuerung:

1. Docker installieren
2. acme Ordner unter /docker erstellen und account.conf entsprechend der Domain oder DynDNS anlegen und Werte eintragen
3. Script über Aufgabensteuerung oder SSH (root) installieren:

docker run -d --name acme.sh \
-v /volume1/docker/acme:/acme.sh \
--net=host \
--restart always \
neilpang/acme.sh:latest daemon

4. acme.sh mit Befehl auf Lets Encrypt setzen:

acme.sh --set-default-ca --server letsencrypt

5. Zertifikat beantragen:

acme.sh --issue --dns dns_anbieter -d deinedomain --dnssleep 300

6. Zertifikat auf die DS übertragen:

acme.sh --deploy -d deinedomain --deploy-hook synology_dsm

Die Befehle 4–6 werden direkt im Terminal im Container eingetragen. Das ganze klingt komplizierter als es ist. Beachte aber bitte, dass der Anbieter Domain/DDNS acme.sh unterstützen muss! Die entsprechenden Werte sind in der account.conf und Befehl 5 & 6 anzupassen.

 

[spline]

Vielen lieben Dank, dass muss ich mal in ruhe machen

dns dns_anbieter -d deinedomain

... beduetet: synology.me -d onkelkurt, wenn meine DDNS onkelkurt.synology.me heissen würde?

 

[EDvonSchleck]

Eventuell für dich noch die unterstützten DynDNS Anbieter interessant: https://www.synology-forum.de/threa...der-fritzbox-installieren.103085/post-1039052

Wenn du ein paar Euros im Jahr ausgeben willst, würde ich die lieber für eine eigene Domain investieren. Bei Netcup gibt es immer wieder Angebote und mit weniger als 2 € im Jahr kannst dafür jede Anwendung eine eigen Subdomain anlegen (Reverse Proxy) und ersparst dir die unterschiedlichen Porteingaben. Ein mit acme.sh erzeugtes Wirdcard-Zertifikat deckt alle Subdomains ab.

... beduetet: synology.me -d onkelkurt, wenn meine DDNS onkelkurt.synology.me heissen würde?

DDNS von Synology wird nicht unterstützt, alternativen siehe den Link oben. Als Domain kommt die komplette Adresse hinein.

Beispiel:
Zertifikat beantragen (Befehl 5)

acme.sh --issue --dns dns_ddnss -d onkelkurt.ddnss.de

Zertifikat auf die DS übertragen (Befehl 6)

acme.sh --deploy -d onkelkurt.ddnss.de --deploy-hook synology_dsm

Das Ganze ist wirklich nicht sehr schwer. Wenn du es einmal gemacht hast, siehst du es selber.

Letztendlich ist es nur 1 Ordner und eine Config erstellen und 4 Befehle (incl. Installation in Docker – Aufgabensteuerung) kopieren und ausführen. Ab dann macht acme.sh alles alleine und automatisch ohne Port offen zu haben!

 

[abrocksi]

5. Zertifikat beantragen:

acme.sh --issue --dns dns_anbieter -d deinedomain --dnssleep 300

6. Zertifikat auf die DS übertragen:

acme.sh --deploy -d deinedomain --deploy-hook synology_dsm

Hallo EdvonSchleck,

ich stehe gerade auf dem Schlauch. Ich möchte acme.sh gerne für eine Domain und drei Subdomains, die ich bei IONOS gekauft habe, einsetzen.

Alle Anleitungen, die ich im Netz und Forum finde, beziehen sich meist auf eine DDNS-Adresse bzw. einen DDNS Anbieter. In einem anderen Post von Dir stehen dankenswerterweise auch ein paar, die von acme.sh unterstützte werden.

Nun meine Frage: Kann ich auch über acme.sh ein Wildcard-Zertifikat für meine IONOS Domain/Subdomains erstellen? Oder verweigert das IONOS?
Wenn ja, wie müsste dann meine account.conf zum zugehörigen Docker Container von acme.sh aussehen?

cheers,
abrocksi