13
Grundsätzliches zu Zertifikaten zum Zugriff auf privates Netzwerk aus dem WWW
Guten Tag,
da ich derzeit den Zugriff aus dem WWW auf mein privates Netzwerk einrichte, beschäftigt mich zum ersten Mal das Thema Zertifikate, damit ich Nutzern Zugang über HTTPS z.B. auf Dienste wie NextCloud oder PhotoPrism gewähre.
Mein Setup:
Mehrere Domains und Subdomains mit Umleitung auf meine öffentliche IP
PfSense mit fester öffentlicher IP
Eingerichteter HAProxy mit mehreren Backendservern, die auf TrueNAS Scale als VM (App) laufen
TrueNAS Scale
Bei Portweiterleitung auf die TrueNAS sind die Apps über IP:Port erreichbar.
Sobald ich über die Domain, z.B. https://nextcloud.meinedomain.de oder https://meinedomain.de gehe, bekomme ich diverse Fehlermeldungen für die Zertifikate.
Ich habe mit ACME auf der pfsense bei Letsencrypt das benötigte Zertifikat erstellt (darin sind mehrere Domains gelistet) und dieses Zertifikat mit öffentlichen Tools als funktionierend getestet.
Nun brauche ich Unterstützung, was ich wo noch einrichten muß:
1) Acme richtete in der pfsense eine Certificate Authority. Benötige ich noch eine weitere CA oder reicht nur diese eine?
2) Wenn ich in meinem privaten Netzwerk auf Geräte wie FritzBox oder TrueNAS zugreife, erhalte ich beim ersten Anmelden eine Meldung, daß das Zertifikat bzw. der Webserver nicht vertrauensvoll ist. Ich kann zwar eine Ausnahme hinzufügen, aber für die Zukunft hätte ich es gerne so, daß es ein internes Zertifikat gibt, damit ich bei einer neuen Anmeldung Ruhe habe. Ich hatte früher auf der pfsense eine interne CA eingerichtet, aber so richtig funktioniert hat es nicht.
Daher die Frage: kann ich ein Letsencrypt-Zertifikat so einrichten, daß auch der Zugriff auf meine internen Server funktioniert? Und wenn das nicht geht, wie erstelle ich mein eigenes Zertifikat, worin alle Webserver in meinem privaten Netzwerk enthalten sind, damit wenn sich ein neuer Benutzer in meinem Netwerk anmeldet, er nicht immer eine Ausnahme im Browser hinzufügen muß?
Ich weiß, daß mein Wissen zu Zertifikaten sehr dünn ist und daher bitte ich um Nachsicht. Am besten fahre ich mit einer Anweisung, welche Schritte ich nach und nach abarbeiten muß und während ich diese Schritte einrichte, lese ich dann in der Wiki nach, was ich mache und verstehe es dann auch. Im Gegensatz dazu, wenn ich mich erst tagelang theoretisch in die Materie einarbeite.
Vielen Dank!
da ich derzeit den Zugriff aus dem WWW auf mein privates Netzwerk einrichte, beschäftigt mich zum ersten Mal das Thema Zertifikate, damit ich Nutzern Zugang über HTTPS z.B. auf Dienste wie NextCloud oder PhotoPrism gewähre.
Mein Setup:
Mehrere Domains und Subdomains mit Umleitung auf meine öffentliche IP
PfSense mit fester öffentlicher IP
Eingerichteter HAProxy mit mehreren Backendservern, die auf TrueNAS Scale als VM (App) laufen
TrueNAS Scale
Bei Portweiterleitung auf die TrueNAS sind die Apps über IP:Port erreichbar.
Sobald ich über die Domain, z.B. https://nextcloud.meinedomain.de oder https://meinedomain.de gehe, bekomme ich diverse Fehlermeldungen für die Zertifikate.
Ich habe mit ACME auf der pfsense bei Letsencrypt das benötigte Zertifikat erstellt (darin sind mehrere Domains gelistet) und dieses Zertifikat mit öffentlichen Tools als funktionierend getestet.
Nun brauche ich Unterstützung, was ich wo noch einrichten muß:
1) Acme richtete in der pfsense eine Certificate Authority. Benötige ich noch eine weitere CA oder reicht nur diese eine?
2) Wenn ich in meinem privaten Netzwerk auf Geräte wie FritzBox oder TrueNAS zugreife, erhalte ich beim ersten Anmelden eine Meldung, daß das Zertifikat bzw. der Webserver nicht vertrauensvoll ist. Ich kann zwar eine Ausnahme hinzufügen, aber für die Zukunft hätte ich es gerne so, daß es ein internes Zertifikat gibt, damit ich bei einer neuen Anmeldung Ruhe habe. Ich hatte früher auf der pfsense eine interne CA eingerichtet, aber so richtig funktioniert hat es nicht.
Daher die Frage: kann ich ein Letsencrypt-Zertifikat so einrichten, daß auch der Zugriff auf meine internen Server funktioniert? Und wenn das nicht geht, wie erstelle ich mein eigenes Zertifikat, worin alle Webserver in meinem privaten Netzwerk enthalten sind, damit wenn sich ein neuer Benutzer in meinem Netwerk anmeldet, er nicht immer eine Ausnahme im Browser hinzufügen muß?
Ich weiß, daß mein Wissen zu Zertifikaten sehr dünn ist und daher bitte ich um Nachsicht. Am besten fahre ich mit einer Anweisung, welche Schritte ich nach und nach abarbeiten muß und während ich diese Schritte einrichte, lese ich dann in der Wiki nach, was ich mache und verstehe es dann auch. Im Gegensatz dazu, wenn ich mich erst tagelang theoretisch in die Materie einarbeite.
Vielen Dank!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670194
Url: https://administrator.de/forum/grundsaetzliches-zu-zertifikaten-zum-zugriff-auf-privates-netzwerk-aus-dem-www-670194.html
Ausgedruckt am: 15.01.2025 um 08:01 Uhr
13 Kommentare
Neuester Kommentar
Moin,
beschäftige Dich mal mit SAN (Subject Alternative Name/Multi-domain) Zertifikaten. Das geht auch mit Let's Encrypt, da gibst Du jede (aktive) Subdomain (www, nextcloud, fritzbox usw.) und die Hauptdomain an. Du wirst aber ein neues Zertifikat anfordern müssen, da man die SANs nicht nachträglich hinzufügen (oder herauslöschen kann).
Vgl. bspw. https://grumpytechie.net/2019/09/20/adding-sans-to-lets-encrypt-certific ...
oder auch https://letsencrypt.org/docs/integration-guide/
Gruß
cykes
beschäftige Dich mal mit SAN (Subject Alternative Name/Multi-domain) Zertifikaten. Das geht auch mit Let's Encrypt, da gibst Du jede (aktive) Subdomain (www, nextcloud, fritzbox usw.) und die Hauptdomain an. Du wirst aber ein neues Zertifikat anfordern müssen, da man die SANs nicht nachträglich hinzufügen (oder herauslöschen kann).
Vgl. bspw. https://grumpytechie.net/2019/09/20/adding-sans-to-lets-encrypt-certific ...
oder auch https://letsencrypt.org/docs/integration-guide/
Gruß
cykes
1
Moin,
das
und das
widerspricht sich. Wenn Letsencrypt-Zertifikate eingesetzt werden, braucht man ja gerade keine eigene CA. Dann gibt es auch keine Fehlermeldungen, weder lokal, noch remote. Es sieht daher so aus, als ob die öffentlichen Zertifikate gar nicht eingerichtet sind, sondern selbst generierte mit eigener CA.
Lesestoff mit Schritt-für-Schritt: agix.com.au/configure-haproxy-on-pfsense-with-letsencrypt-ssl-https-termination/ oder mikes-projects.de/edv/netzwerk/pfsense-letsencrpyt-zertifikate.
Gruß
DivideByZero
P.S.:
das
Ich habe mit ACME auf der pfsense bei Letsencrypt das benötigte Zertifikat erstellt (darin sind mehrere Domains gelistet) und dieses Zertifikat mit öffentlichen Tools als funktionierend getestet.
und das
1) Acme richtete in der pfsense eine Certificate Authority. Benötige ich noch eine weitere CA oder reicht nur diese eine?
widerspricht sich. Wenn Letsencrypt-Zertifikate eingesetzt werden, braucht man ja gerade keine eigene CA. Dann gibt es auch keine Fehlermeldungen, weder lokal, noch remote. Es sieht daher so aus, als ob die öffentlichen Zertifikate gar nicht eingerichtet sind, sondern selbst generierte mit eigener CA.
Lesestoff mit Schritt-für-Schritt: agix.com.au/configure-haproxy-on-pfsense-with-letsencrypt-ssl-https-termination/ oder mikes-projects.de/edv/netzwerk/pfsense-letsencrpyt-zertifikate.
Gruß
DivideByZero
P.S.:
Daher die Frage: kann ich ein Letsencrypt-Zertifikat so einrichten, daß auch der Zugriff auf meine internen Server funktioniert?
Ja, s.o.Und wenn das nicht geht, wie erstelle ich mein eigenes Zertifikat, worin alle Webserver in meinem privaten Netzwerk enthalten sind, damit wenn sich ein neuer Benutzer in meinem Netwerk anmeldet, er nicht immer eine Ausnahme im Browser hinzufügen muß?
Geht nicht. Er müsste bei einem selbstgenerierten Zertifikat Deine CA auf allen aufrufenden Geräten importieren, dann wird auch den Zertifikaten vertraut, die diese CA ausstellt. Das ist noch komplizierter, als die Ausnahme, und für Otto-Normal-User, der einfach eine Seite aufrufen will, untauglich. Um das zu vermeiden, gibt es ja gerade Zertifikate wie die von Letsencrypt.1
@cykes
Servus, long time no hear
Danke!
Ich habe jetzt im Acme (für Letsencrypt) zu meinen bestehenden Domains/Subdomains, bei den ich bei meinem Registrar im A record meine feste IP eingetragen habe, noch die ganzen Webserver im internen Netzwerk hinzugefügt. Wie bei den registrierten Domains die Methode "Standalone HTTP Server" über Port 80 hinzugefügt. Letsencrypt meldet beim Renew, daß diese Subdomains
no valid AAAA records found for subdomain.domain
CURLE_URL_MALFORMAT (3)
The URL was not properly formatted.
Muss ich bei meinem Registrar für jeden Webserver in meinem Netzwerk eine eigene Subdomain anlegen, die dann auf meine öffentliche IP verweist?
Servus, long time no hear
Danke!Ich habe jetzt im Acme (für Letsencrypt) zu meinen bestehenden Domains/Subdomains, bei den ich bei meinem Registrar im A record meine feste IP eingetragen habe, noch die ganzen Webserver im internen Netzwerk hinzugefügt. Wie bei den registrierten Domains die Methode "Standalone HTTP Server" über Port 80 hinzugefügt. Letsencrypt meldet beim Renew, daß diese Subdomains
no valid AAAA records found for subdomain.domain
CURLE_URL_MALFORMAT (3)
The URL was not properly formatted.
Muss ich bei meinem Registrar für jeden Webserver in meinem Netzwerk eine eigene Subdomain anlegen, die dann auf meine öffentliche IP verweist?
Moin,
Gruß,
Dani
no valid AAAA records found for subdomain.domain
hm. Kann es sein, dass du einen Dualstack Lite Anschluss hast und damit nur via IPv6 erreichbar bist?Wie bei den registrierten Domains die Methode "Standalone HTTP Server" über Port 80 hinzugefügt. Letsencrypt meldet beim Renew, daß diese Subdomains
Ich würde an einer Stelle die Zertifikate bzw. das Wildcard Zertifikat via Challenge DNS-01 abrufen. Somit musst nämlich nicht sicherstellen, dass der abzurufende Service nicht im Internet erreichbar sein muss. Abgesehen davon wird mit einem Wildcard-Zertifikat deine Subdomains nicht offensichtlich publiziert. Es gibt natürlich andere Wege... aber die muss man als vermeidlicher Angreifer erst einmal gehen wollen und können.Muss ich bei meinem Registrar für jeden Webserver in meinem Netzwerk eine eigene Subdomain anlegen, die dann auf meine öffentliche IP verweist?
Wenn du die Zertifikate via Challenge HTTP-01 abrufen möchtest, Ja. Wobei es einen A-Eintrag tut. Alle weiteren Einträge, welche hinter sich der öffentliche IP-Adresse verbergen, können problemlos als CNAME Eintrag angelegt werden. Schon das mögliche Rate-Limit.Gruß,
Dani
1
@DivideByZero
Danke für die Links. Das hat mir weitergehofen!
@Dani
Danke für den Tipp mit der Wildcars, also *.mydomain.com. Letsencrypt hat es einwandfrei geschluckt, nachdem ich im DNS der Domain unter TXT und CNAME vor der Domain "_acme-challenge" eingetragen und im Wert die Challenge-Phrase von Letsencrypt.
Ich habe nun zwei Netwerke, die beide über eine öffentliche IP erreichbar sind. Auf dem entfernten Netzwerk (Office) läuft eine TrueNAS Scale mit zwei Docker Apps, NextCloud und PhotoPrism. Wenn ich nun über WWW auf meinen Server im Büro photoprism.mydomain.com zugreife, erhalte ich einen Fehler, daß das SSL die maximale Länge überschritten hat:
Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG
Dieser Server läuft jedoch als VM auf der TrueNAS und das ganze habe ich als Backend im HAProxy eingerichtet. Auch hier kann ich noch Fehler gemacht haben.
Wenn ich jedoch auf meine pfsense zugreife (IP:8443) erhalte ich den Fehler, daß das Zertifikat nicht vertrauenswürdig ist und wenn ich die Ausnahme hinzufüge, komme ich drauf. Wenn ich die pfsense mit https://mydomain.com:8443 anspreche, bekomme ich ebenfalls die Meldung, daß
mydomain.com verwendet eine Sicherheitstechnologie namens "HTTP Strict Transport Security (HSTS)", durch welche Firefox nur über gesicherte Verbindungen mit der Website verbinden darf. Daher kann keine Ausnahme für die Website hinzugefügt werden.
Ich taste mich voran dank eurer Hilfe...
Vielleich noch erwähnenswert, daß mir Firefox mein Letsencrypt-Zertifikat anzeigt und dort steht unter
Basiseinschränkungen !
Zertifizierungsstelle Nein
Ist das von Belang?
Danke für die Links. Das hat mir weitergehofen!
@Dani
Danke für den Tipp mit der Wildcars, also *.mydomain.com. Letsencrypt hat es einwandfrei geschluckt, nachdem ich im DNS der Domain unter TXT und CNAME vor der Domain "_acme-challenge" eingetragen und im Wert die Challenge-Phrase von Letsencrypt.
Ich habe nun zwei Netwerke, die beide über eine öffentliche IP erreichbar sind. Auf dem entfernten Netzwerk (Office) läuft eine TrueNAS Scale mit zwei Docker Apps, NextCloud und PhotoPrism. Wenn ich nun über WWW auf meinen Server im Büro photoprism.mydomain.com zugreife, erhalte ich einen Fehler, daß das SSL die maximale Länge überschritten hat:
Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG
Dieser Server läuft jedoch als VM auf der TrueNAS und das ganze habe ich als Backend im HAProxy eingerichtet. Auch hier kann ich noch Fehler gemacht haben.
Wenn ich jedoch auf meine pfsense zugreife (IP:8443) erhalte ich den Fehler, daß das Zertifikat nicht vertrauenswürdig ist und wenn ich die Ausnahme hinzufüge, komme ich drauf. Wenn ich die pfsense mit https://mydomain.com:8443 anspreche, bekomme ich ebenfalls die Meldung, daß
mydomain.com verwendet eine Sicherheitstechnologie namens "HTTP Strict Transport Security (HSTS)", durch welche Firefox nur über gesicherte Verbindungen mit der Website verbinden darf. Daher kann keine Ausnahme für die Website hinzugefügt werden.
Ich taste mich voran dank eurer Hilfe...
Vielleich noch erwähnenswert, daß mir Firefox mein Letsencrypt-Zertifikat anzeigt und dort steht unter
Basiseinschränkungen !
Zertifizierungsstelle Nein
Ist das von Belang?
Update:
Nach mehreren Tagen (und Nächten bis 3:00 Uhr früh), in den ich zahlreiche Videos und Tutorials durchgegangen bin, habe ich nach über 6 Jahren mit pfSense überlegt, eine Alternative zu suchen. Als Grund war eine ums Verrecken nicht zum Laufen zu bringende Instanz des HA Proxy. Die Tutorials alle zeigten Einstellungen, die ich in der Version auf der pfSense nicht finden konnte.
So landete ich bei OpenWRT und war sprachlos. Nach einigem Anlauf (man muß ziemlich viel manuell machen, um das Image auf die SSD eines Minirouters installieren) wurde ich mit einem rasend schnell startendem Linux OS belohnt. So etwas habe ich nicht gesehen, im Nu ist das OS bei Bedarf gebootet. Dann gin ich ans Eingemachte und installierte es auf einem dritten Minirouter. WireGuard habe ich trotz mehrerer Versuche nicht zum Laufen gebracht und als der zu Hause stationierte Router sich zweimal beim Neustart aufhing, habe ich in der dritten Nacht auf OPNSense zurückgegriffen.
Hier stockte ich schon am Anfang, als es um das Einrichten des Internetzugangs ging. Anders als bei pfSense, wo ich gewohnt war, die Interfaces und IP-Adressen von der Konsole aus einzustellen und sich erst dann an der GUI anzumelden und die restlichen Einstellungen zumachen, sollte man hier zwingend alles auf Standard lassen und sich gleich unter 192.168.1.1 verbinden und dann mit dem Wizzard die ersten Einstellungen vornehmen. Ansonsten ist es ein try and error, weshalb auch immer.
Dann machte ich mich an die Einrichtung des WireGuard-VPN. Ich habe Stundenlang zwei professionelle Videos umgesetzt, den Tunnel zum Laufen gebracht, aber konnte nicht auf mein entferntes LAN zugreifen. Dann erst bin ich auf der Originalseite von OPNSense in der Anleitung gelandet, und... Hier steht alles drin, sogar mit Bildern aber das ganz große AHA, es hat endlich geklappt! Ich muß da ein großes Lob an die Verfasser des Handbuchs machen:
Für mich verständlicher als das Tutorial auf pfSense und diese ganzen Videos der verschiedenen Trittbrettfahrer funktionieren oft nur in deren Fantasie.
So jetzt mache ich noch die Einrichtung von meinem IPSec Site to Site und dann mache ich mich an die Zertifikate. Wenn alles so wie am Schnürchen läuft, seid Ihr bald meine Anfängerfragen los
Update 2:
Auch die Einrichtung von IPsec lief nach der einwandfreien und fehlerlosen Anweisung von der Homepage von OPNSense wie aam Schürchen. Lediglich bin ich gestockt, als ich die Phase 1 nicht ans laufen brachte und das lag daran, daß bei meinem Provider zu Hause ein doppeltes NAT vorliegt, so daß ich als bei My und Peer Identifier statt dem Default die öffentliche IP angegeben habe und dann startete der Tunnel sofort. Jetzt ist OpenVPN an der Reihe.
Nach mehreren Tagen (und Nächten bis 3:00 Uhr früh), in den ich zahlreiche Videos und Tutorials durchgegangen bin, habe ich nach über 6 Jahren mit pfSense überlegt, eine Alternative zu suchen. Als Grund war eine ums Verrecken nicht zum Laufen zu bringende Instanz des HA Proxy. Die Tutorials alle zeigten Einstellungen, die ich in der Version auf der pfSense nicht finden konnte.
So landete ich bei OpenWRT und war sprachlos. Nach einigem Anlauf (man muß ziemlich viel manuell machen, um das Image auf die SSD eines Minirouters installieren) wurde ich mit einem rasend schnell startendem Linux OS belohnt. So etwas habe ich nicht gesehen, im Nu ist das OS bei Bedarf gebootet. Dann gin ich ans Eingemachte und installierte es auf einem dritten Minirouter. WireGuard habe ich trotz mehrerer Versuche nicht zum Laufen gebracht und als der zu Hause stationierte Router sich zweimal beim Neustart aufhing, habe ich in der dritten Nacht auf OPNSense zurückgegriffen.
Hier stockte ich schon am Anfang, als es um das Einrichten des Internetzugangs ging. Anders als bei pfSense, wo ich gewohnt war, die Interfaces und IP-Adressen von der Konsole aus einzustellen und sich erst dann an der GUI anzumelden und die restlichen Einstellungen zumachen, sollte man hier zwingend alles auf Standard lassen und sich gleich unter 192.168.1.1 verbinden und dann mit dem Wizzard die ersten Einstellungen vornehmen. Ansonsten ist es ein try and error, weshalb auch immer.
Dann machte ich mich an die Einrichtung des WireGuard-VPN. Ich habe Stundenlang zwei professionelle Videos umgesetzt, den Tunnel zum Laufen gebracht, aber konnte nicht auf mein entferntes LAN zugreifen. Dann erst bin ich auf der Originalseite von OPNSense in der Anleitung gelandet, und... Hier steht alles drin, sogar mit Bildern aber das ganz große AHA, es hat endlich geklappt! Ich muß da ein großes Lob an die Verfasser des Handbuchs machen:
Für mich verständlicher als das Tutorial auf pfSense und diese ganzen Videos der verschiedenen Trittbrettfahrer funktionieren oft nur in deren Fantasie.
So jetzt mache ich noch die Einrichtung von meinem IPSec Site to Site und dann mache ich mich an die Zertifikate. Wenn alles so wie am Schnürchen läuft, seid Ihr bald meine Anfängerfragen los
Update 2:
Auch die Einrichtung von IPsec lief nach der einwandfreien und fehlerlosen Anweisung von der Homepage von OPNSense wie aam Schürchen. Lediglich bin ich gestockt, als ich die Phase 1 nicht ans laufen brachte und das lag daran, daß bei meinem Provider zu Hause ein doppeltes NAT vorliegt, so daß ich als bei My und Peer Identifier statt dem Default die öffentliche IP angegeben habe und dann startete der Tunnel sofort. Jetzt ist OpenVPN an der Reihe.
OPNsense ist eh das bessere PFsense 
1
Mir hat auf pfSense gefallen, daß sie immer stabile lief und mich nie im Stich gelassen hat. Aber auch die besten Freunde müssen einmal auseinandergehen...
Guten Morgen,
jetzt habe ich mich in die Zertifikate und deren Erstellung sowohl manuell als auch mit Acme (Letsencrypt) auf einer OPNSense eingearbeitet. Ich habe erfolgreich zwei Zertifikate für meine beiden Domains mit je zwei Subdomains erstellt und über die Seite https://www.sslshopper.com/ssl-checker.html verifiziert.
Mein Problem: wenn ich meine OPNSense, TrueNAS und FritzBox aus dem LAN und die OPNSense über Wan aufrufe, bekomme ich die Meldung: ERR_CERT_COMMON_NAME_INVALID
Ich verstehe das nicht, wo doch die Webseiten wie oben ein OK bei der Zertifikatverifizierung ausgeben.
jetzt habe ich mich in die Zertifikate und deren Erstellung sowohl manuell als auch mit Acme (Letsencrypt) auf einer OPNSense eingearbeitet. Ich habe erfolgreich zwei Zertifikate für meine beiden Domains mit je zwei Subdomains erstellt und über die Seite https://www.sslshopper.com/ssl-checker.html verifiziert.
Mein Problem: wenn ich meine OPNSense, TrueNAS und FritzBox aus dem LAN und die OPNSense über Wan aufrufe, bekomme ich die Meldung: ERR_CERT_COMMON_NAME_INVALID
Ich verstehe das nicht, wo doch die Webseiten wie oben ein OK bei der Zertifikatverifizierung ausgeben.
Moin,
Gruß,
Dani
Mein Problem: wenn ich meine OPNSense, TrueNAS und FritzBox aus dem LAN und die OPNSense über Wan aufrufe, bekomme ich die Meldung: ERR_CERT_COMMON_NAME_INVALID
rufst du die Anwendungen mit den selben Subdomains auf, wie aus dem Internet?Gruß,
Dani
@Dani
Nachdem ich testweise in der OPNSense hostname: photoprism domain: domain.com eingetragen habe,
funktioniert das Zertifikat endlich und meldet keinen Fehler.
Abschließend daher die Bitte, wie ich es schaffe, ein Zertifikat für *.domain.com zu erstellen.
Soweit ich weiß, funktioniert Wildcard (*.domain.com) nur bei DNS-01-Verifizierung geht und nicht bei HTTP-01. Da Strato die DNS-Challenge nicht unterstützt, benutze ich HTTP-01.
Müssen nun alle Hostnames meiner Server meines LAN bei der Zertifikaterstellung als Subdomains eingetragen werden? Wenn das nur so geht, wäre es ungünstig, weil dann jeder sieht, welche Serverstruktur ich habe...
Auf jeden Fall bin ich froh, heute ein weiteres Stück weitergegangen zu sein - danke!
Nachdem ich testweise in der OPNSense hostname: photoprism domain: domain.com eingetragen habe,
funktioniert das Zertifikat endlich und meldet keinen Fehler.
Abschließend daher die Bitte, wie ich es schaffe, ein Zertifikat für *.domain.com zu erstellen.
Soweit ich weiß, funktioniert Wildcard (*.domain.com) nur bei DNS-01-Verifizierung geht und nicht bei HTTP-01. Da Strato die DNS-Challenge nicht unterstützt, benutze ich HTTP-01.
Müssen nun alle Hostnames meiner Server meines LAN bei der Zertifikaterstellung als Subdomains eingetragen werden? Wenn das nur so geht, wäre es ungünstig, weil dann jeder sieht, welche Serverstruktur ich habe...
Auf jeden Fall bin ich froh, heute ein weiteres Stück weitergegangen zu sein - danke!
Ein weiteres Update kurz vor Weihnachten:
Nachdem ich nach Jahren eines fehlerfreien Einsatzes von pfSense so meine Schwierigkeiten mit HA Proxy hatte, stieg ich kurz auf OpenWRT und dann auf OPNSense um. Beim letzteren bin ich dann doch enttäuscht gewesen, denn nach Erstellung von Letsencrypt-Zertifikaten mit Acme-Plugin stellte sich heraus, daß ich die Firewall neu booten mußtem, damit das im Zertifikatlager gelistete Zertifikat auch zu sehen, herunterladen oder löschen war. Es war zwar gelistet, aber es tat sich nichts. Ich habe dann kurzerhand pfSense wieder aufgespielt und mein Backup von vor zwei Woche aufgespielt und nun ist es gut. Zudem habe ich eine Wireguard-VPN-Site-to-Site-Verbindung aufgebaut und war angenehm überrascht, einen x-schnelleren Durchsatz als zuvor über IPSec zu verzeichnen. Mit WG haben 6 GB rund 10 Minuten gedauert und bei IPSec zeigte es mir an über 1 Stunde, also habe ich es gar nicht abgewartet
HA Proxy habe ich jetzt auch soweit verstanden, daß ich meine TrueNAS mit einem über Acme und HTTP-01 erstelltes Letsencrypt-Zertifikat aus dem WWW erreichen kann und es mir eine sichere Verbindung anzeigt.
Ich bekomme es aber immer noch nicht hin, daß ich die Server auf meiner TrueNAS aus dem WWW erreiche. Hier mein Setting:
1) pfSense
2) TrueNAS Scale (die GUI ist aus www über HA Proxy erreichbar)
3) Mehrere Apps im Docker (nextcloud, photoprism), deren GUI aus dem Land über IP-der-TrueNAS:Port zu erreichen ist, aber nicht aus dem WWW
4) Mehrere Linux-Server (darunter ein Acme-DNS), die in einer VM auf einer TrueNAS-Core laufen und aus dem LAN über eine feste IP zu erreichen sind, aber nicht aus dem WWW
Da ich alle virtuellen Server und Docker-Apps im HAProxy-Backend genauso eingestellt habe, wie die beiden TrueNAS, schließe ich eine Fehlkonfiguration des Backend aus. Also muß das Problem daran liegen, daß der HAProxy die Anfrage nicht richtig weiterleitet. Wenn ich beispielsweise die Webseite https://photoprism.mydomain.com aufrufe, bekomme ich 400 Bad Request, The plain HTTP request was sent to HTTPS port, nginx.
Wie soll ich vorgehen, um den Fehler zu finden?
Danke und allesn schöne Weihnachten und ein gesundes und friedliches Neues Jahr!!!
vafk18
Nachdem ich nach Jahren eines fehlerfreien Einsatzes von pfSense so meine Schwierigkeiten mit HA Proxy hatte, stieg ich kurz auf OpenWRT und dann auf OPNSense um. Beim letzteren bin ich dann doch enttäuscht gewesen, denn nach Erstellung von Letsencrypt-Zertifikaten mit Acme-Plugin stellte sich heraus, daß ich die Firewall neu booten mußtem, damit das im Zertifikatlager gelistete Zertifikat auch zu sehen, herunterladen oder löschen war. Es war zwar gelistet, aber es tat sich nichts. Ich habe dann kurzerhand pfSense wieder aufgespielt und mein Backup von vor zwei Woche aufgespielt und nun ist es gut. Zudem habe ich eine Wireguard-VPN-Site-to-Site-Verbindung aufgebaut und war angenehm überrascht, einen x-schnelleren Durchsatz als zuvor über IPSec zu verzeichnen. Mit WG haben 6 GB rund 10 Minuten gedauert und bei IPSec zeigte es mir an über 1 Stunde, also habe ich es gar nicht abgewartet
HA Proxy habe ich jetzt auch soweit verstanden, daß ich meine TrueNAS mit einem über Acme und HTTP-01 erstelltes Letsencrypt-Zertifikat aus dem WWW erreichen kann und es mir eine sichere Verbindung anzeigt.
Ich bekomme es aber immer noch nicht hin, daß ich die Server auf meiner TrueNAS aus dem WWW erreiche. Hier mein Setting:
1) pfSense
2) TrueNAS Scale (die GUI ist aus www über HA Proxy erreichbar)
3) Mehrere Apps im Docker (nextcloud, photoprism), deren GUI aus dem Land über IP-der-TrueNAS:Port zu erreichen ist, aber nicht aus dem WWW
4) Mehrere Linux-Server (darunter ein Acme-DNS), die in einer VM auf einer TrueNAS-Core laufen und aus dem LAN über eine feste IP zu erreichen sind, aber nicht aus dem WWW
Da ich alle virtuellen Server und Docker-Apps im HAProxy-Backend genauso eingestellt habe, wie die beiden TrueNAS, schließe ich eine Fehlkonfiguration des Backend aus. Also muß das Problem daran liegen, daß der HAProxy die Anfrage nicht richtig weiterleitet. Wenn ich beispielsweise die Webseite https://photoprism.mydomain.com aufrufe, bekomme ich 400 Bad Request, The plain HTTP request was sent to HTTPS port, nginx.
Wie soll ich vorgehen, um den Fehler zu finden?
Danke und allesn schöne Weihnachten und ein gesundes und friedliches Neues Jahr!!!
vafk18
Moin,
Aber evtl. ist dort schon eine Reverse Proxy integriert (so ist es mal bei Synology DSM). Dann könntest du auf dem NAS die Zuordnung vornehmen. Um so die Komplexität zu verringern.
Gruß,
Dani
Zudem habe ich eine Wireguard-VPN-Site-to-Site-Verbindung aufgebaut und war angenehm überrascht, einen x-schnelleren Durchsatz als zuvor über IPSec zu verzeichnen. Mit WG haben 6 GB rund 10 Minuten gedauert und bei IPSec zeigte es mir an über 1 Stunde, also habe ich es gar nicht abgewartet face-smile
sehr schön... das bestätigen auch unzählige Berichte und Blogartikel im WWW. HA Proxy habe ich jetzt auch soweit verstanden, daß ich meine TrueNAS mit einem über Acme und HTTP-01 erstelltes Letsencrypt-Zertifikat aus dem WWW erreichen kann und es mir eine sichere Verbindung anzeigt.
Wunderbar. Damit ist der erste Teil geschafft.3) Mehrere Apps im Docker (nextcloud, photoprism), deren GUI aus dem Land über IP-der-TrueNAS:Port zu erreichen ist, aber nicht aus dem WWW
Du brauchst für jede App eine Sub Domain (z.B. next.truenas.domain.de). Darüber kannst du dann die Zuordnung zur dem Docker Container vornehmen. Ich kenne TrueNAS nicht.Aber evtl. ist dort schon eine Reverse Proxy integriert (so ist es mal bei Synology DSM). Dann könntest du auf dem NAS die Zuordnung vornehmen. Um so die Komplexität zu verringern.
Da ich alle virtuellen Server und Docker-Apps im HAProxy-Backend genauso eingestellt habe, wie die beiden TrueNAS, schließe ich eine Fehlkonfiguration des Backend aus.
Lass mal die Konfiguration für das Backend sehen.ekomme ich 400 Bad Request, The plain HTTP request was sent to HTTPS port, nginx.
Das sagt doch schon alles. Hast du durchgehend Zertifikate im Einsatz bzw. evtl. Self-Signed-Zertifikate?Gruß,
Dani
