Um Zertifikatfehler zu vermeiden, benötigen Sie das pi, um ein Zertifikat zu senden, das der verwendeten Domäne entspricht. Dafür gibt es zwei Ansätze:
- Verwenden Sie ein Zertifikat für beide Domänen, das sowohl auf dem Pi-Server als auch auf dem Hauptserver installiert ist. Es spielt keine Rolle, welche Domäne der Client in seiner Abfrage verwendet, das Zertifikat stimmt überein.
- Wählen Sie ein Zertifikat aus, das der Client erwartet, und senden Sie es.
Option 1 ist einfacher und gängiger. Schauen Sie sich das Zertifikat für google.com an! Sowohl auf dem Pi als auch auf dem Hauptserver wird dasselbe Zertifikat (für beide Domänen) installiert. Um ein solches Zertifikat von Let's Encrypt zu erhalten, benötigen Sie den Hauptserver, um auch eine Website für die dynamische Domäne von pi auszuführen, und verwenden Sie einen certbot-Befehl, um die Kontrolle über beide Domänen gleichzeitig zu überprüfen. Die Site des Hauptservers für den dyndns-Namen muss den Inhalt des pi nicht hosten - sie ist nur dort, sodass Let's Encrypt überprüfen kann, ob Sie die Kontrolle über diese Site haben (Sie können diese Site sogar zwischen Erneuerungen deaktivieren).
Beispiel für einen Certbot-Befehl (auf dem Hauptserver ausführen):
letsencrypt certonly --webroot --csr request.csr -w /http/pisite/www -d mypi.spdyn.de -w /http/mainwebsite/www -d maindomain.de
Wenn request.csreine Domäne als CN verwendet wird und beide Domänen im Feld SANs vorhanden sind, /http/pisite/wwwbezieht sich dies auf ein lokales Verzeichnis, das Sie für eine andere Website auf dem aktuellen Server erstellen, das an den dynamischen Namen des pi gebunden ist, und /http/mainwebsite/wwwist das vorhandene Verzeichnis Ihrer Hauptwebsite.
Option 2 ist umständlicher, liefert jedoch ein "saubereres" Ergebnis: Der Client erhält ein Zertifikat, das der von ihm eingegebenen Domäne entspricht. Führen Sie auf dem Himbeer-pi nginx mit dem Stream-Modul (oder einem gleichwertigen) aus, das beim Öffnen einer TLS-Verbindung das SNI-Feld untersucht (ohne die TLS-Verbindung zu akzeptieren), und wählt anhand der darin enthaltenen Domäne aus, welche Upstream-Komponente die Weiterleitung vornimmt Verbindung zu. Auf diese Weise können Sie auswählen, wie Sie Anforderungen der Hauptdomäne an dem externen Port behandeln möchten, die an das Himbeer-Pi weitergeleitet wird. Sie können sie an den Hauptserver senden, als ob sie auf dem richtigen Port erstellt wurden. Sie können sie an einen anderen Port auf dem Pi senden (z. B. Nextcloud oder irgendetwas anderes). Sie können sie mit derselben Nginx-Instanz und beenden Zeigen Sie die gewünschte Seite an oder schließen Sie einfach die Verbindung. Es ist deine Entscheidung.
Hier ist eine Beispielkonfiguration für diese Methode:
stream/sni-switch.conf
# Listen on 443, and on new connection: # if the SNI is mapped herein, handle it on this Nginx # else, forward the whole session to 192.168.1.80:443 (TCP passthrough, no decryption) upstream mainwebserver { server 192.168.1.80:443; } upstream local_https { server 127.0.0.1:1443; } map $ssl_preread_server_name $name { default mainwebserver; pisite.spdyn.de local_https; } server { listen 443; ssl_preread on; proxy_pass $name; } Und in nginx.conf
load_module /usr/lib/nginx/modules/ngx_stream_module.so; stream { include /etc/nginx/stream/sni-switch.conf; } ... Um dies mit Apache zu tun, sehen Sie dies . Eine Beispielkonfiguration, die folgendermaßen aussehen könnte:
<VirtualHost *:*> ProxyPreserveHost On ProxyPass "/" "http://192.168.1.80/" ProxyPassReverse "/" "http://192.168.1.80/" ServerName maindomain.de </VirtualHost>