Lorawan-stack: Apache + pilha ttn na mesma máquina + letsencrypt certificado acme get problem

Criado em 19 dez. 2019  ·  5Comentários  ·  Fonte: TheThingsNetwork/lorawan-stack

Obrigado por enviar um relatório de bug. Por favor, preencha o modelo abaixo, caso contrário não seremos capazes de processar este relatório de bug.

Resumo

problema quando o apache está instalado e habilitado (ouvindo 80/443) na máquina ttn.
Console TTN bloqueado nas portas 80/443 e funcionando em 1885.8885 portas.

Neste caso, não é possível obter / atualizar o certificado.
É uma situação muito comum, se alguém quiser colocar a pilha TTN e algum aplicativo DB / web no mesmo dispositivo.

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

TTN mostra erro: certificado perdido / ou Host não na Lista Branca.

Passos para reproduzir

Como podemos reproduzir o problema?

1) Quando o apache está ativo (ouvindo em 80, 443), configuração de porta - pilha ttn não permite habilitar 80, 443 portas (80.443 devem ser # em docker-compose.yml - portas 1885, 8885 são usadas). Neste (docker-compose não obtém o certificado letsencrypt).

docker-compose.yml arquivo:

   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 arquivo 

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) Quando nós:
parar apache (serviço apache2 parar)
reconfigure ttn-stack para habilitar (80, 443 porta - remover (hashes))
conectar com o navegador da web ao subdomínio principal, ele obtém o certificado com sucesso (em portas 80/443)

docker-compose.yml arquivo:

  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 portas padrão de arquivo usadas 443 - neste caso ttn get letsencrypt certificate

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) Agora, se tivermos atualizado o certificado, podemos voltar para a primeira configuração (porta 80/443 usada pelo apache, ttn usar 1885/8885 para o console) - e seu console aberto com sucesso em https://subdomain.domain.com : 8885 /.

O que você vê agora?

Cole a saída do terminal, faça upload de registros (como .txt) ou faça upload de capturas de tela.

...

O que você quer ver em vez disso?

Adicione alguns exemplos ou maquetes, se aplicável.

...

Ambiente

Seu ambiente: OS / Browser / Gateway / Device / ...? Versões? IDs / EUIs? Cole a saída de "versão ttn-lw-cli" ou "versão ttn-lw-stack" se aplicável.

...

Como você pretende implementar isso?

Existe uma maneira de configurar ttn e apache na mesma máquina?ou force permite criptografar para obter a cerfication em uma porta diferente?

Você pode fazer isso sozinho e enviar uma solicitação pull?

Você também pode @mencionar especialistas se precisar de ajuda com isso.

...

documentation
Fonte
picture ecities

Comentários muito úteis

Ao executar o The Things Stack atrás de um proxy reverso, você terá que desabilitar completamente o TLS na configuração e tornar o proxy responsável por encerrar todas as conexões TLS (não apenas HTTP, mas também gRPC, MQTT etc.). Suponho que possamos documentar como desabilitar todos os ouvintes TLS de The Things Stack e quais portas precisam ser mapeadas no proxy reverso.

Acho que podemos esperar que as pessoas que fariam isso já saibam como seu proxy funciona, então não acho que devemos documentar como fazer isso especificamente com apache / nginx / haproxy / envoy / etc.

picture htdvisser em 19 dez. 2019
👍2

Todos 5 comentários

Ao executar o The Things Stack atrás de um proxy reverso, você terá que desabilitar completamente o TLS na configuração e tornar o proxy responsável por encerrar todas as conexões TLS (não apenas HTTP, mas também gRPC, MQTT etc.). Suponho que possamos documentar como desabilitar todos os ouvintes TLS de The Things Stack e quais portas precisam ser mapeadas no proxy reverso.

Acho que podemos esperar que as pessoas que fariam isso já saibam como seu proxy funciona, então não acho que devemos documentar como fazer isso especificamente com apache / nginx / haproxy / envoy / etc.

htdvisser picture htdvisser em 19 dez. 2019
👍2

Olá @htdvisser , Obrigado pela resposta.

Testei em um computador local com endereço IP público / estático (baseado em lte) - não sei qual é a estrutura da rede.
Também testei em VPS (ovh.eu) diretamente no lado da Internet - de acordo com o provedor, não há proxies e firewalls (apenas alguns DoS).

Ambas as variantes requerem o mesmo (inicialização do certificado na porta 80/443 padrão para cada cliente / estação ip).
Posteriormente, o console pode ser alternado para outras portas (1885/8885).

Há outras questões relacionadas ao VPS ou a quaisquer dispositivos

Eu olho para a "tela de log do console" por um tempo e há muitos "testes de atividade de hackers" relatados pela pilha TTN (e vemos apenas ataques da web na porta http / htts padrão na tela). O domínio / subdomínio tem apenas registros dns e não foi usado para páginas da web que robôs / motores de busca podem descobrir. Eu suponho que os robôs hackers pesquisem todos os endereços IP4 estáticos em busca de dispositivos de resposta e, mais cedo ou mais tarde, o dispositivo será encontrado e atacado por máquinas hacker. Portanto, é muito fácil deixar qualquer servidor ocupado com ataques em massa para portas http / https conhecidas, mesmo que sejam 100% seguras.

Eu acho que é muito razoável não usar portas 80/443 para console / interface web e ter a possibilidade de alterá-las para console de pilha TTN. É para fins de administração (não público) e os administradores estão cientes dessas configurações.

As únicas perguntas são:
Plano A) Como podemos criar / atualizar certificados acme / letsencrypt automaticamente em portas diferentes?
Plano B) É possível automatizar o procedimento manual acima, descrito aqui pelo menos para alguns hosts conhecidos (por exemplo, ip estático) para administração?

ecities picture ecities em 19 dez. 2019

As especificações para os desafios HTTP-01 e TLS-ALPN-01 do ACME requerem o uso da porta 80/443. Você não pode obter ou renovar certificados usando esses desafios se usar portas diferentes.

Você pode tentar solicitar certificados ACME usando o desafio DNS-01 com uma ferramenta como o certbot (isso está fora do escopo de nossa documentação) ou de uma autoridade de certificação paga (também fora do escopo de nossa documentação).

Quando você tem esses certificados, pode configurar The Things Stack de acordo com as instruções de "Certificados personalizados": https://thethingsstack.io/v3.3.2/guides/getting-started/certificates/#custom -certificates e com o seguinte ambiente :

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 em 19 dez. 2019
👍1

Criei o problema https://github.com/TheThingsNetwork/lorawan-stack/issues/1760 para documentar como configurar o The Things Stack para ser executado por trás de um proxy de terminação TLS.

Criei o problema https://github.com/TheThingsNetwork/lorawan-stack/issues/1761 para documentar como configurar certificados solicitados externamente no The Things Stack.

htdvisser picture htdvisser em 19 dez. 2019

obrigado

ecities picture ecities em 19 dez. 2019
Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

adriansmares picture adriansmares  ·  8Comentários
johanstokking picture johanstokking  ·  5Comentários
htdvisser picture htdvisser  ·  9Comentários
htdvisser picture htdvisser  ·  4Comentários
adriansmares picture adriansmares  ·  9Comentários