Lorawan-stack: apache + ttn stack on the same machine + letsencrypt acme certificate get problem

Created on 19 Dec 2019  ·  5Comments  ·  Source: TheThingsNetwork/lorawan-stack

Summary

problem when apache is installed and enabled (listening 80/443) on the ttn machine.
TTN console blocked on 80/443 ports and working on 1885,8885 ports.

In this case ttn cant' get/update certifiate.
Its very common situation, if somebody wants to put TTN stack and some DB/web app on the same device.

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

TTN shows error: missed certificate /or Host not in White List.

Steps to Reproduce

1) When apache is active (listening on 80, 443) port configuration - ttn stack do not allow to enable 80, 443 ports (80,443 must be # in docker-compose.yml - ports 1885, 8885 are used) . In this (docker-compose do not get the letsencrypt certificate).

docker-compose.yml file:

   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 moved port to 8885 instead 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) When we:
stop apache (service apache2 stop)
reconfigure ttn-stack to enable (80, 443 port - remove (hashes) )
connect with web browser to main subdomain it gets the certificate sucessfully (on 80/443 ports)

docker-compose.yml file:

  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 standard ports used 443 - in this case 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) Now if we have updated certificate we can switch back to first configuration (port 80/443 used by apache, ttn use 1885/8885 for console) - and its succefully open console on https://subdomain.domain.com:8885/. It is possible it's working only for current host/ip and until certificate will expire (3months)

What do you see now?

...

What do you want to see instead?

...

Environment

...

How do you propose to implement this?

Is there a way to configure both ttn and apache on the same machine?
or force lets encrypt to get cerfication on different port?

Can you do this yourself and submit a Pull Request?

...

documentation
Source
picture ecities

Most helpful comment

When you run The Things Stack behind a reverse proxy, you'll have to completely disable TLS in the configuration and make the proxy responsible for terminating all TLS connections (not only HTTP, but also gRPC, MQTT etc.). I suppose we could document how to disable all TLS listeners of The Things Stack, and what ports need to be mapped in the reverse proxy.

I think we can expect that people who would do this already know how their proxy works, so I don't think we should document how to do this specifically with apache/nginx/haproxy/envoy/etc.

picture htdvisser on 19 Dec 2019
👍2

All 5 comments

When you run The Things Stack behind a reverse proxy, you'll have to completely disable TLS in the configuration and make the proxy responsible for terminating all TLS connections (not only HTTP, but also gRPC, MQTT etc.). I suppose we could document how to disable all TLS listeners of The Things Stack, and what ports need to be mapped in the reverse proxy.

I think we can expect that people who would do this already know how their proxy works, so I don't think we should document how to do this specifically with apache/nginx/haproxy/envoy/etc.

htdvisser picture htdvisser on 19 Dec 2019
👍2

Hi @htdvisser , Thanks for response.

I tested on local computer with public/static IP address (lte based) - I don't know what the structure of network are.
I also tested on VPS (ovh.eu) directly on internet side - according to the provider it is without proxies and firewalls (only some DoS).

Both variants require the same (initializaton of certificate on standard 80/443 port for each client/ip station).
Later on the console could be switched to other ports (1885/8885).

There is another issues regarding to VPS or any Public/Static IP devices - no matter the structure of network is.

I look at the "console log screen" for a while and there is a lot of "hackers activity trials" reported by TTN stack (and we see only only web attacks on standard http/htts port on the screen). The domain/subdomain have only dns records and not been used for webpage which robots/search engines may discover. I asume hackers robots search all Static IP4 address for responding devices, and sooner or later device will be found and atacked by hacker machines. So, its very easy to make any server busy with mass attacks for known http/https ports, even if they 100% are secure.

I think it is very reasonable not to use 80/443 ports for console/web interface and have possibility to change them for TTN stack console. It's for administation purposes (not public) and the administators are aware of this settings.

The only questions are:
Plan A) How can we create/refresh acme/letsencrypt certificates automatically on different ports?
Plan B) Is it possible to automate above manual procedure, described here at least for a few known host (eg static ip) for administration?

ecities picture ecities on 19 Dec 2019

The specifications for the HTTP-01 and TLS-ALPN-01 challenges of ACME require using port 80/443. You can not get or renew certificates using those challenges if you use different ports.

You can try requesting ACME certificates using the DNS-01 challenge with a tool like certbot (this is outside the scope of our documentation) or from a paid certificate authority (also outside the scope of our documentation).

When you have such certificates, you can configure The Things Stack according to the "Custom Certificates" instructions: https://thethingsstack.io/v3.3.2/guides/getting-started/certificates/#custom-certificates and with the following environment:

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 on 19 Dec 2019
👍1

I created issue https://github.com/TheThingsNetwork/lorawan-stack/issues/1760 for documenting how to configure The Things Stack for running behind a TLS-terminating proxy.

I created issue https://github.com/TheThingsNetwork/lorawan-stack/issues/1761 for documenting how to configure externally requested certificates in The Things Stack.

htdvisser picture htdvisser on 19 Dec 2019

thanks

ecities picture ecities on 19 Dec 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

htdvisser picture htdvisser  ·  9Comments
johanstokking picture johanstokking  ·  6Comments
thinkOfaNumber picture thinkOfaNumber  ·  4Comments
ZeroSum24 picture ZeroSum24  ·  3Comments
adriansmares picture adriansmares  ·  8Comments