Lorawan-stack: apache + ttn stack en la misma máquina + letsencrypt acme certificate get problem

Creado en 19 dic. 2019 · 5Comentarios · Fuente: TheThingsNetwork/lorawan-stack

Gracias por enviar un informe de errores. Complete la plantilla a continuación; de lo contrario, no podremos procesar este informe de error.

Resumen

problema cuando apache está instalado y habilitado (escucha 80/443) en la máquina ttn.
Consola TTN bloqueada en puertos 80/443 y funcionando en 1885,8885 puertos.

En este caso, ttn no puede obtener / actualizar el certificado.
Es una situación muy común, si alguien quiere poner TTN stack y alguna aplicación DB / web en el mismo dispositivo.

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

TTN muestra error: certificado perdido / o Host que no está en la lista blanca.

Pasos para reproducir

¿Cómo podemos reproducir el problema?

1) Cuando apache está activo (escuchando en 80, 443) configuración de puertos - ttn stack no permite habilitar 80, 443 puertos (80,443 deben estar # en docker-compose.yml - se usan los puertos 1885, 8885). En esto (docker-compose no obtiene el certificado letsencrypt).

docker-compose.yml archivo:

   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 file movió el puerto a 8885 en lugar de 443:

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) Cuando nosotros:
detener apache (servicio apache2 detener)
reconfigure ttn-stack para habilitar (puerto 80, 443 - eliminar (hashes))
conéctese con el navegador web al subdominio principal, obtiene el certificado con éxito (en los puertos 80/443)

docker-compose.yml archivo:

  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 file puertos estándar usados 443 - en este caso ttn obtiene el certificado 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) Ahora, si tenemos el certificado actualizado, podemos volver a la primera configuración (puerto 80/443 usado por apache, ttn usa 1885/8885 para la consola) - y su consola abierta con éxito en https://subdomain.domain.com : 8885 /.

¿Qué ves ahora?

Pegue la salida del terminal, cargue registros (como .txt) o cargue capturas de pantalla.

...

¿Qué quieres ver en su lugar?

Agregue algunos ejemplos o maquetas si corresponde.

...

Medio ambiente

Su entorno: sistema operativo / navegador / puerta de enlace / dispositivo / ...? Versiones ID / EUI? Pegue la salida de "ttn-lw-cli version" o "ttn-lw-stack version" si corresponde.

...

¿Cómo se propone implementar esto?

¿Hay alguna forma de configurar ttn y apache en la misma máquina?¿O forzar permite encriptar para obtener la certificación en un puerto diferente?

¿Puede hacer esto usted mismo y enviar una solicitud de extracción?

También puede @mencionar a expertos si necesita ayuda con esto.

...

documentation

Fuente

ecities

Comentario más útil

Cuando ejecuta The Things Stack detrás de un proxy inverso, tendrá que deshabilitar completamente TLS en la configuración y hacer que el proxy sea responsable de terminar todas las conexiones TLS (no solo HTTP, sino también gRPC, MQTT, etc.). Supongo que podríamos documentar cómo deshabilitar todos los oyentes TLS de The Things Stack y qué puertos deben asignarse en el proxy inverso.

Creo que podemos esperar que las personas que hagan esto ya sepan cómo funciona su proxy, por lo que no creo que debamos documentar cómo hacer esto específicamente con apache / nginx / haproxy / envoy / etc.

htdvisser en 19 dic. 2019

👍2

Todos 5 comentarios

htdvisser en 19 dic. 2019

👍2

Hola @htdvisser , Gracias por la respuesta.

Probé en una computadora local con una dirección IP pública / estática (basada en lte); no sé cuál es la estructura de la red.
También probé en VPS (ovh.eu) directamente en el lado de Internet; según el proveedor, no tiene proxies ni firewalls (solo algunos DoS).

Ambas variantes requieren lo mismo (inicialización del certificado en el puerto estándar 80/443 para cada cliente / estación ip).
Más tarde, la consola podría cambiarse a otros puertos (1885/8885).

Hay otros problemas relacionados con el VPS o cualquier dispositivo

Miro la "pantalla de registro de la consola" por un tiempo y hay muchas "pruebas de actividad de piratas informáticos" informadas por la pila TTN (y solo vemos ataques web en el puerto http / htts estándar en la pantalla). El dominio / subdominio solo tiene registros dns y no se ha utilizado para la página web que los robots / motores de búsqueda pueden descubrir. Supongo que los robots de los piratas informáticos buscan en todas las direcciones IP4 estáticas los dispositivos de respuesta, y tarde o temprano el dispositivo será encontrado y atacado por máquinas de piratas informáticos. Por lo tanto, es muy fácil hacer que cualquier servidor esté ocupado con ataques masivos para puertos http / https conocidos, incluso si son 100% seguros.

Creo que es muy razonable no usar puertos 80/443 para la interfaz de consola / web y tener la posibilidad de cambiarlos para la consola de pila TTN. Es para fines de administración (no públicos) y los administradores conocen esta configuración.

Las únicas preguntas son:
Plan A) ¿Cómo podemos crear / actualizar certificados acme / letsencrypt automáticamente en diferentes puertos?
Plan B) ¿Es posible automatizar el procedimiento manual anterior, descrito aquí al menos para algunos hosts conocidos (por ejemplo, IP estática) para la administración?

ecities en 19 dic. 2019

Las especificaciones para los desafíos HTTP-01 y TLS-ALPN-01 de ACME requieren el uso del puerto 80/443. No puede obtener ni renovar certificados usando esos desafíos si usa puertos diferentes.

Puede intentar solicitar certificados ACME utilizando el desafío DNS-01 con una herramienta como certbot (esto está fuera del alcance de nuestra documentación) o de una autoridad de certificación pagada (también fuera del alcance de nuestra documentación).

Cuando tenga dichos certificados, puede configurar The Things Stack de acuerdo con las instrucciones de "Certificados personalizados": https://thethingsstack.io/v3.3.2/guides/getting-started/certificates/#custom -certificates y con el siguiente entorno :

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

htdvisser en 19 dic. 2019

👍1

Creé el problema https://github.com/TheThingsNetwork/lorawan-stack/issues/1760 para documentar cómo configurar The Things Stack para que se ejecute detrás de un proxy con terminación TLS.

Creé el problema https://github.com/TheThingsNetwork/lorawan-stack/issues/1761 para documentar cómo configurar certificados solicitados externamente en The Things Stack.

htdvisser en 19 dic. 2019

Gracias

ecities en 19 dic. 2019

¿Fue útil esta página

0 / 5 - 0 calificaciones