Lorawan-stack: apache + pile ttn sur la même machine + problème de certificat acme Letsencrypt

Créé le 19 déc. 2019 · 5Commentaires · Source: TheThingsNetwork/lorawan-stack

Merci d'avoir soumis un rapport de bogue. Veuillez remplir le modèle ci-dessous, sinon nous ne pourrons pas traiter ce rapport de bogue.

Sommaire

problème lorsque Apache est installé et activé (écoute 80/443) sur la machine ttn.
Console TTN bloquée sur 80/443 ports et fonctionnant sur 1885,8885 ports.

Dans ce cas, ttn ne peut pas obtenir/mettre à jour le certificat.
C'est une situation très courante, si quelqu'un veut mettre une pile TTN et une application DB/web sur le même appareil.

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

TTN affiche l'erreur : certificat manqué/ou hôte absent de la liste blanche.

Étapes pour reproduire

Comment peut-on reproduire le problème ?

1) Lorsque Apache est actif (écoute sur 80, 443) configuration des ports - la pile ttn ne permet pas d'activer les 80, 443 ports (80 443 doivent être # dans docker-compose.yml - les ports 1885, 8885 sont utilisés). En cela (docker-compose n'obtient pas le certificat letsencrypt).

Fichier docker-compose.yml :

   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 fichier

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) Quand on :
arrêter apache (service apache2 stop)
reconfigurer ttn-stack pour activer (port 80, 443 - supprimer (hachages))
connectez-vous avec le navigateur Web au sous-domaine principal, il obtient le certificat avec succès (sur les ports 80/443)

Fichier docker-compose.yml :

  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 fichiers ports standard utilisés 443 - dans ce cas, ttn obtient le certificat Letsencrypt

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) Maintenant, si nous avons mis à jour le certificat, nous pouvons revenir à la première configuration (port 80/443 utilisé par apache, ttn utiliser 1885/8885 pour la console) - et sa console ouverte avec succès sur https://subdomain.domain.com :8885 /.

Que voyez-vous maintenant?

Veuillez coller la sortie du terminal, télécharger les journaux (au format .txt) ou télécharger des captures d'écran.

...

Que veux-tu voir à la place ?

Veuillez ajouter des exemples ou des maquettes, le cas échéant.

...

Environnement

Votre environnement : OS/Navigateur/Gateway/Device/... ? des versions ? ID/IUE ? Collez la sortie de « ttn-lw-cli version » ou « ttn-lw-stack version » le cas échéant.

...

Comment proposez-vous de mettre cela en œuvre ?

Existe-t-il un moyen de configurer à la fois ttn et apache sur la même machine ?ou forcer permet de chiffrer pour obtenir une cerfication sur un port différent ?

Pouvez-vous le faire vous-même et soumettre une Pull Request ?

Vous pouvez également @mentionner des experts si vous avez besoin d'aide.

...

documentation

Source

ecities

Commentaire le plus utile

Lorsque vous exécutez The Things Stack derrière un proxy inverse, vous devez désactiver complètement TLS dans la configuration et rendre le proxy responsable de la terminaison de toutes les connexions TLS (non seulement HTTP, mais également gRPC, MQTT, etc.). Je suppose que nous pourrions documenter comment désactiver tous les écouteurs TLS de The Things Stack et quels ports doivent être mappés dans le proxy inverse.

Je pense que nous pouvons nous attendre à ce que les personnes qui feraient cela sachent déjà comment fonctionne leur proxy, donc je ne pense pas que nous devrions documenter comment le faire spécifiquement avec apache/nginx/haproxy/envoy/etc.

htdvisser le 19 déc. 2019

👍2

Tous les 5 commentaires

htdvisser le 19 déc. 2019

👍2

Salut @htdvisser , merci pour la réponse.

J'ai testé sur un ordinateur local avec une adresse IP publique/statique (basée sur lte) - je ne sais pas quelle est la structure du réseau.
J'ai aussi testé sur VPS (ovh.eu) directement côté internet - selon le fournisseur c'est sans proxys et pare-feux (seulement quelques DoS).

Les deux variantes nécessitent la même chose (initialisation du certificat sur le port standard 80/443 pour chaque client/poste ip).
Plus tard, la console pourrait être basculée sur d'autres ports (1885/8885).

Il existe un autre problème concernant le VPS ou tout périphérique

Je regarde "l'écran du journal de la console" pendant un moment et il y a beaucoup d'"essais d'activité de pirates" signalés par la pile TTN (et nous ne voyons que des attaques Web sur le port http/htts standard à l'écran). Le domaine/sous-domaine n'a que des enregistrements DNS et n'a pas été utilisé pour la page Web que les robots/moteurs de recherche peuvent découvrir. Je suppose que les robots des pirates recherchent toutes les adresses IP4 statiques pour les appareils qui répondent, et tôt ou tard, les appareils seront trouvés et attaqués par des machines pirates. Ainsi, il est très facile d'occuper n'importe quel serveur avec des attaques de masse pour les ports http/https connus, même s'ils sont 100% sécurisés.

Je pense qu'il est très raisonnable de ne pas utiliser les ports 80/443 pour l'interface console/web et d'avoir la possibilité de les changer pour la console de la pile TTN. C'est à des fins d'administration (non publiques) et les administrateurs sont au courant de ces paramètres.

Les seules questions sont :
Plan A) Comment pouvons-nous créer/actualiser des certificats acme/letsencrypt automatiquement sur différents ports ?
Plan B) Est-il possible d'automatiser la procédure manuelle ci-dessus, décrite ici au moins pour quelques hôtes connus (par exemple, une adresse IP statique) pour l'administration ?

ecities le 19 déc. 2019

Les spécifications pour les défis HTTP-01 et TLS-ALPN-01 d'ACME nécessitent l'utilisation du port 80/443. Vous ne pouvez pas obtenir ou renouveler des certificats en utilisant ces défis si vous utilisez des ports différents.

Vous pouvez essayer de demander des certificats ACME en utilisant le défi DNS-01 avec un outil tel que certbot (cela sort du cadre de notre documentation) ou auprès d'une autorité de certification payante (également en dehors du cadre de notre documentation).

Lorsque vous disposez de tels certificats, vous pouvez configurer The Things Stack selon les instructions « Certificats personnalisés » : https://thethingsstack.io/v3.3.2/guides/getting-started/certificates/#custom -certificates et avec l'environnement suivant :

TTN_LW_TLS_SOURCE=file
TTN_LW_TLS_CERTIFICATE=/path/to/cert-chain.pem
TTN_LW_TLS_CERTIFICATE=/path/to/key.pem

htdvisser le 19 déc. 2019

👍1

J'ai créé le problème https://github.com/TheThingsNetwork/lorawan-stack/issues/1760 pour documenter comment configurer The Things Stack pour qu'il s'exécute derrière un proxy de terminaison TLS.

J'ai créé le problème https://github.com/TheThingsNetwork/lorawan-stack/issues/1761 pour documenter comment configurer les certificats demandés en externe dans The Things Stack.

htdvisser le 19 déc. 2019

Merci

ecities le 19 déc. 2019

Cette page vous a été utile?

0 / 5 - 0 notes