Lorawan-stack: Apache + ttn-Stack auf demselben Computer + letsencrypt Acme-Zertifikat bekomme Problem

Erstellt am 19. Dez. 2019  ·  5Kommentare  ·  Quelle: TheThingsNetwork/lorawan-stack

Vielen Dank für die Übermittlung eines Fehlerberichts. Bitte füllen Sie die untenstehende Vorlage aus, ansonsten können wir diesen Fehlerbericht nicht bearbeiten.

Zusammenfassung

Problem, wenn Apache installiert und aktiviert ist (Listening 80/443) auf dem ttn-Rechner.
TTN-Konsole auf 80/443-Ports blockiert und funktioniert auf 1885,8885-Ports.

In diesem Fall kann ttn kein Zertifikat abrufen/aktualisieren.
Es ist eine sehr häufige Situation, wenn jemand einen TTN-Stack und eine DB / Web-App auf demselben Gerät installieren möchte.

https://github.com/TheThingsNetwork/lorawan-stack/issues/1731

TTN zeigt Fehler: fehlendes Zertifikat / oder Host nicht in der White List.

Schritte zum Reproduzieren

Wie können wir das Problem reproduzieren?

1) Wenn Apache aktiv ist (lauscht auf 80, 443) Portkonfiguration - ttn-Stack erlaubt keine Aktivierung von 80, 443 Ports (80.443 muss # in docker-compose.yml sein - Ports 1885, 8885 werden verwendet) . In diesem (docker-compose erhält das letsencrypt-Zertifikat nicht).

docker-compose.yml Datei:

   ports:
(hashed)      - '80:1885'
(hashed)     - '443:8885'
      - '1882:1882'
      - '8882:8882'
      - '1883:1883'
      - '8883:8883'
      - '1884:1884'
      - '8884:8884'
      - '1885:1885'
      - '8885:8885'
      - '8886:8886'
      - '1887:1887'
      - '8887:8887'
      - '1700:1700/udp'
    env_file: '.env'

.env Datei hat den Port auf 8885 statt auf 443 verschoben:

TTN_LW_IS_EMAIL_NETWORK_CONSOLE_URL=https://subdomain.example.com:8885/console
TTN_LW_IS_EMAIL_NETWORK_IDENTITY_SERVER_URL=https://subdomain.example.com:8885/oauth

TTN_LW_IS_OAUTH_UI_CANONICAL_URL=https://subdomain.example.com:8885/oauth
TTN_LW_IS_OAUTH_UI_IS_BASE_URL=https://subdomain.example.com:8885/api/v3

TTN_LW_CONSOLE_OAUTH_AUTHORIZE_URL=https://subdomain.example.com:8885/oauth/authorize
TTN_LW_CONSOLE_OAUTH_TOKEN_URL=https://subdomain.example.com:8885/oauth/token

TTN_LW_CONSOLE_UI_CANONICAL_URL=https://subdomain.example.com:8885/console
TTN_LW_CONSOLE_UI_AS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_GS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_IS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_JS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_NS_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_EDTC_BASE_URL=https://subdomain.example.com:8885/api/v3
TTN_LW_CONSOLE_UI_QRG_BASE_URL=https://subdomain.example.com:8885/api/v3

2) Wenn wir:
Apache stoppen (service Apache2 stoppen)
ttn-stack zum Aktivieren neu konfigurieren (80, 443 Port - entfernen (Hashes) )
Verbinden Sie sich mit dem Webbrowser mit der Haupt-Subdomain, es wird das Zertifikat erfolgreich abgerufen (auf 80/443-Ports)

docker-compose.yml Datei:

  ports:
      - '80:1885'
      - '443:8885'
      - '1882:1882'
      - '8882:8882'
      - '1883:1883'
      - '8883:8883'
      - '1884:1884'
      - '8884:8884'
(hashed)      - '1885:1885'
(hashed)     - '8885:8885'
      - '8886:8886'
      - '1887:1887'
      - '8887:8887'
      - '1700:1700/udp'
    env_file: '.env'

.env Datei Standardports verwendet 443 - in diesem Fall ttn letsencrypt-Zertifikat abrufen

TTN_LW_IS_EMAIL_NETWORK_CONSOLE_URL=https://subdomain.example.com/console
TTN_LW_IS_EMAIL_NETWORK_IDENTITY_SERVER_URL=https://subdomain.example.com/oauth


TTN_LW_IS_OAUTH_UI_CANONICAL_URL=https://subdomain.example.com/oauth
TTN_LW_IS_OAUTH_UI_IS_BASE_URL=https://subdomain.example.com/api/v3

TTN_LW_CONSOLE_OAUTH_AUTHORIZE_URL=https://subdomain.example.com/oauth/authorize
TTN_LW_CONSOLE_OAUTH_TOKEN_URL=https://subdomain.example.com/oauth/token

TTN_LW_CONSOLE_UI_CANONICAL_URL=https://subdomain.example.com/console
TTN_LW_CONSOLE_UI_AS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_GS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_IS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_JS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_NS_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_EDTC_BASE_URL=https://subdomain.example.com/api/v3
TTN_LW_CONSOLE_UI_QRG_BASE_URL=https://subdomain.example.com/api/v3

3) Wenn wir nun das Zertifikat aktualisiert haben, können wir zurück zur ersten Konfiguration wechseln (Port 80/443 von Apache verwendet, ttn 1885/8885 für die Konsole verwenden) - und die erfolgreich geöffnete Konsole auf https://subdomain.domain.com :8885 /.

Was siehst du jetzt?

Bitte fügen Sie die Terminalausgabe ein, laden Sie Protokolle (als .txt) hoch oder laden Sie Screenshots hoch.

...

Was möchtest du stattdessen sehen?

Bitte fügen Sie gegebenenfalls einige Beispiele oder Mock-ups hinzu.

...

Umfeld

Ihre Umgebung: Betriebssystem/Browser/Gateway/Gerät/...? Versionen? Ausweise/EUIs? Fügen Sie ggf. die Ausgabe von "ttn-lw-cli version" oder "ttn-lw-stack version" ein.

...

Wie wollen Sie dies umsetzen?

Gibt es eine Möglichkeit, sowohl ttn als auch Apache auf demselben Computer zu konfigurieren?oder erzwingen Sie die Verschlüsselung, um eine Zertifizierung auf einem anderen Port zu erhalten?

Können Sie dies selbst tun und einen Pull Request senden?

Sie können auch Experten @erwähnen , wenn Sie dabei Hilfe benötigen.

...

documentation
Quelle
picture ecities

Hilfreichster Kommentar

Wenn Sie The Things Stack hinter einem Reverse-Proxy ausführen, müssen Sie TLS in der Konfiguration vollständig deaktivieren und den Proxy für das Beenden aller TLS-Verbindungen (nicht nur HTTP, sondern auch gRPC, MQTT usw.) verantwortlich machen. Ich nehme an, wir könnten dokumentieren, wie alle TLS-Listener von The Things Stack deaktiviert werden und welche Ports im Reverse-Proxy zugeordnet werden müssen.

Ich denke, wir können erwarten, dass Leute, die dies tun würden, bereits wissen, wie ihr Proxy funktioniert, daher denke ich nicht, dass wir dies speziell mit Apache/nginx/haproxy/envoy/etc dokumentieren sollten.

picture htdvisser am 19. Dez. 2019
👍2

Alle 5 Kommentare

Wenn Sie The Things Stack hinter einem Reverse-Proxy ausführen, müssen Sie TLS in der Konfiguration vollständig deaktivieren und den Proxy für das Beenden aller TLS-Verbindungen (nicht nur HTTP, sondern auch gRPC, MQTT usw.) verantwortlich machen. Ich nehme an, wir könnten dokumentieren, wie alle TLS-Listener von The Things Stack deaktiviert werden und welche Ports im Reverse-Proxy zugeordnet werden müssen.

Ich denke, wir können erwarten, dass Leute, die dies tun würden, bereits wissen, wie ihr Proxy funktioniert, daher denke ich nicht, dass wir dies speziell mit Apache/nginx/haproxy/envoy/etc dokumentieren sollten.

htdvisser picture htdvisser am 19. Dez. 2019
👍2

Hallo @htdvisser , Danke für die Antwort.

Ich habe auf einem lokalen Computer mit einer öffentlichen / statischen IP-Adresse (lte-basiert) getestet - ich weiß nicht, wie das Netzwerk aufgebaut ist.
Ich habe auch auf VPS (ovh.eu) direkt auf der Internet-Seite getestet - laut Anbieter ohne Proxys und Firewalls (nur einige DoS).

Beide Varianten erfordern dasselbe (Initialisierung des Zertifikats auf dem Standard-80/443-Port für jede Client/IP-Station).
Später konnte die Konsole auf andere Ports umgestellt werden (1885/8885).

Es gibt noch weitere Probleme in Bezug auf VPS oder öffentliche/statische IP- Geräte – unabhängig von der Netzwerkstruktur.

Ich schaue mir eine Weile den "Konsolen-Log-Bildschirm" an und es werden viele "Hacker-Aktivitätsversuche" vom TTN-Stack gemeldet (und wir sehen nur Webangriffe auf den Standard-http/htts-Port auf dem Bildschirm). Die Domain/Subdomain hat nur DNS-Einträge und wurde nicht für Webseiten verwendet, die von Robotern/Suchmaschinen entdeckt werden können. Ich gehe davon aus, dass Hacker-Roboter alle statischen IP4-Adressen nach reagierenden Geräten durchsuchen, und früher oder später wird das Gerät von Hacker-Maschinen gefunden und angegriffen. Es ist also sehr einfach, jeden Server mit Massenangriffen auf bekannte http/https-Ports zu beschäftigen, selbst wenn diese zu 100% sicher sind.

Ich denke, es ist sehr vernünftig, keine 80/443-Ports für die Konsole/Webschnittstelle zu verwenden und die Möglichkeit zu haben, diese für die TTN-Stack-Konsole zu ändern. Es dient Verwaltungszwecken (nicht öffentlich) und die Administratoren sind sich dieser Einstellungen bewusst.

Die einzigen Fragen sind:
Plan A) Wie können wir acme/letsencrypt-Zertifikate automatisch auf verschiedenen Ports erstellen/aktualisieren?
Plan B) Ist es möglich, das obige manuelle Verfahren, das hier beschrieben wird, zumindest für einige wenige bekannte Hosts (zB statische IP) für die Verwaltung zu automatisieren?

ecities picture ecities am 19. Dez. 2019

Die Spezifikationen für die HTTP-01- und TLS-ALPN-01-Herausforderungen von ACME erfordern die Verwendung von Port 80/443. Sie können mit diesen Herausforderungen keine Zertifikate abrufen oder erneuern, wenn Sie unterschiedliche Ports verwenden.

Sie können versuchen, ACME-Zertifikate mithilfe der DNS-01-Challenge mit einem Tool wie certbot (dies liegt außerhalb des Umfangs unserer Dokumentation) oder von einer kostenpflichtigen Zertifizierungsstelle (ebenfalls außerhalb des Umfangs unserer Dokumentation) anzufordern.

Wenn Sie über solche Zertifikate verfügen, können Sie The Things Stack gemäß den Anweisungen zu "Custom Certificates" konfigurieren: https://thethingsstack.io/v3.3.2/guides/getting-started/certificates/#custom -certificates und mit der folgenden Umgebung :

TTN_LW_TLS_SOURCE=file
TTN_LW_TLS_CERTIFICATE=/path/to/cert-chain.pem
TTN_LW_TLS_CERTIFICATE=/path/to/key.pem
htdvisser picture htdvisser am 19. Dez. 2019
👍1

Ich habe das Problem https://github.com/TheThingsNetwork/lorawan-stack/issues/1760 erstellt, um zu dokumentieren, wie The Things Stack für die Ausführung hinter einem TLS-terminierenden Proxy konfiguriert wird.

Ich habe das Issue https://github.com/TheThingsNetwork/lorawan-stack/issues/1761 erstellt, um zu dokumentieren, wie extern angeforderte Zertifikate in The Things Stack konfiguriert werden.

htdvisser picture htdvisser am 19. Dez. 2019

Danke

ecities picture ecities am 19. Dez. 2019
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

kschiffer picture kschiffer  ·  6Kommentare
johanstokking picture johanstokking  ·  6Kommentare
johanstokking picture johanstokking  ·  3Kommentare
MatteMoveSRL picture MatteMoveSRL  ·  7Kommentare
bafonins picture bafonins  ·  5Kommentare