Update: I managed to make ACME work, so at least it will auto install the certificates where it needs to. I can now access via HTTPS correctly, but I still face the same Token Exchange Refused message.
Update 2: I DID IT! Turns out, you need to change most of the config options so that instead of localhost you point to your own domain name.
Example of a chunk of the changes I added to docker-compose.yml:
TTN_LW_CONSOLE_UI_AS_BASE_URL: https://mydomain:8885/api/v3
TTN_LW_CONSOLE_UI_IS_BASE_URL: https://mydomain:8885/api/v3
TTN_LW_OAUTH_SERVER_ADDRESS: https://mydomain:8885/oauth
TTN_LW_IS_OAUTH_UI_CANONICAL_URL: https://mydomain:8885/oauth
TTN_LW_IS_OAUTH_UI_IS_BASE_URL: https://mydomain:8885/api/v3
TTN_LW_APPLICATION_SERVER_GRPC_ADDRESS: mydomain:8884
TTN_LW_DEVICE_CLAIMING_SERVER_GRPC_ADDRESS: mydomain:8884
To know all the parameters you need to change just call ttn-lw-stack config | grep localhost and see what should be changed and what already works as is.
Also make sure the ports are open and accessible from the IP you are testing from AND from the server itself at least. Port 80 also needs to be open to Let’s Encrypt.
Also also I added the port 8885 to the command that creates the oauth client, so it ends up like this:
docker-compose run --rm stack is-db create-oauth-client --id console --name "Console" --owner admin --secret "console" --redirect-uri "https://mydomain:8885/console/oauth/callback" --redirect-uri "/console/oauth/callback" --logout-redirect-uri "https://mydomain:8885/console" --logout-redirect-uri "/console"
Not sure if this was really needed though, but it works for me so I’m not touching it ^^’.
2 Likes
Hi @christophmerscher if you don’t mind, I can use your help on how you got a self signed certificate working as part of your config? I am running a VM on a local network and using my own domain name? Eventually I will assign it to a public IP and use Let’s Encrypt automatically, but for now I would like some clear help on self signed certificate.
At the moment I have
Token Exchange Refused errors which as per configuration instructions is when you try to log in to The Things Stack Console, because an authorization request generated from within the container will not be redirected to port 1885 or 8885, where The Things Stack is listening.
Could you please help?
Hi @Tigere, I spent a bit of time facing this issue too but eventually got it to work. I was running TTS v3.9.4 in docker in a VM running Ubuntu 20.04, using self signed certificates in a made up domain name (ttn.local.com) that had not entries in any DNS.
To get mine to work I had to ensure the mapping of domain name to TTS stack docker network gateway ip address was put into both the VM machine /etc/hosts file AND in the TTS docker container /etc/hosts file (ie. 172.25.0.1 ttn.local.com).
Note to add the mapping to the tts stack docker container /etc/hosts file I found it easiest to add the extra-hosts property to the docker-compose.yml file so it adds the mapping to the docker /etc/hosts file automatically upon starting the container. Here’s a snippet of my docker-compose.yml file:
services:
…
stack:
…
extra_hosts:
- “ttn.local.com:172.25.0.1” # Ensure this IP address matches the docker network gateway address.
…
1 Like
Hi @TheIronNinja, the configuration options you’re specifying here are in our example ttn-lw-stack-docker.yml file -> https://thethingsstack.io/getting-started/installation/configuration/#example-configuration-files
If you set up The Things Stack according to the documentation, i.e with folder structure like
docker-compose.yml # defines Docker services for running {{% tts %}}
config/
└── stack/
└── ttn-lw-stack-docker.yml # configuration file for {{% tts %}}
And you use our example docker-compose.yml file, when you start the stack, the entrypoint line loads the ttn-lw-stack-docker.yml file with all of the configuration options:
stack:
# In production, replace 'latest' with tag from https://hub.docker.com/r/thethingsnetwork/lorawan-stack/tags
image: thethingsnetwork/lorawan-stack:latest
entrypoint: ttn-lw-stack -c /config/ttn-lw-stack-docker.yml
Glad you got this working. Running self signed certificates inside a Docker container with no DNS address is complicated! We’ve added instructions for using the machine’s local IP address, but adding the DNS records manually is a good solution.
@benolayinka, I can’t see any of @TheIronNinja’s config settings in the example ttn-lw-stack-docker.yml file. That file only contains TTN_LW_BLOB_LOCAL_DIRECTORY, TTN_LW_REDIS_ADDRESS, and TTN_LW_IS_DATABASE_URI. @TheIronNinja has specified 7 additional settings in their post, as well as adding port 8885 to the console oauth client registration.
Following up: I have managed to set up The Things Stack and log in to the console by following @TheIronNinja’s instructions above and using these steps for setting up https.
I am still having some issues with ttn-lw-cli (it’s trying to hit localhost and my certificate is for my machine’s static IP), but ttn-lw-stack config | grep localhost shows that there are some more config options using localhost which I can probably tweak to fix that.
Also of note is the following github issue which describes the IronNinja has mentioned: https://github.com/TheThingsNetwork/lorawan-stack/issues/1230
Referencing the open source configuration file here
TTN_LW_CONSOLE_UI_AS_BASE_URL: line 86
TTN_LW_CONSOLE_UI_IS_BASE_URL: line 80
TTN_LW_OAUTH_SERVER_ADDRESS: this is not a The Things Stack config option
TTN_LW_IS_OAUTH_UI_CANONICAL_URL: line 27
TTN_LW_IS_OAUTH_UI_IS_BASE_URL: line 29
TTN_LW_APPLICATION_SERVER_GRPC_ADDRESS: this is not a The Things Stack config option
TTN_LW_DEVICE_CLAIMING_SERVER_GRPC_ADDRESS: this is not a The Things Stack config option
1 Like
Thanks for clarifying, I didn’t realise some of those environment variables overlapped with the other settings in the file. I have now got ttn-lw-cli working properly after changing all the config variables in the github issue I linked. I’m going over my tts install process again to see which of these extra variables were needed. Once that’s done I’ll post the full process here so that (a) people googling this in the future can find it and (b) the install documentation can be updated as needed.
I’ve recorded the complete process for setting up TTS open source with a self-signed certificate here. It’s a bit long for a forum post, hence the pastebin link. Note that I’m using solution 1, replacing localhost with the static IP of my machine.
The key parts missing from the current TTS documentation are as follows:
- Uncomment the custom certs sections at the bottom of
docker-compose.yml(@benolayinka is adding this to the docs) - Uncomment the custom certs section near the top of
ttn-lw-stack-docker.ymland comment out the Let’s Encrypt section (@benolayinka is adding this to the docs) - Add additional environment variables to
docker-compose.yaml. In particular, I needed to add the following variables:
TTN_LW_APPLICATION_SERVER_GRPC_ADDRESS: 192.168.1.13:8884
TTN_LW_DEVICE_TEMPLATE_CONVERTER_GRPC_ADDRESS: 192.168.1.13:8884
TTN_LW_GATEWAY_SERVER_GRPC_ADDRESS: 192.168.1.13:8884
TTN_LW_IDENTITY_SERVER_GRPC_ADDRESS: 192.168.1.13:8884
TTN_LW_JOIN_SERVER_GRPC_ADDRESS: 192.168.1.13:8884
TTN_LW_NETWORK_SERVER_GRPC_ADDRESS: 192.168.1.13:8884
TTN_LW_OAUTH_SERVER_ADDRESS: https://192.168.1.13:8885/oauth
I’ve selected these variables by taking the full list from the relevant github issue and removing the variables which are already specified via config in ttn-lw-stack-docker.yml. Some (or all) of these variables could specified as config in ttn-lw-stack-docker.yml instead of as environment variables.
- Add port
8885tois.email.network.console-urlandis.email.network.identity-server-url. - Add port
8885to every url nested underconsole
Would it be possible to add these additional steps to the official configuration docs? I was not able to get my installation working until I found this thread and the linked github issue.
@htdvisser are these configuration options used somewhere? They aren’t documented. Is TTN_LW_NETWORK_SERVER a valid alias for TTN_LW_NS?
https://thethingsstack.io/reference/configuration/network-server/
Ah. @dsmith, how did you configure the CLI? Doing
$ ttn-lw-cli use 192.168.1.13
will configure the CLI to use that IP.
I was configuring the CLI using the environment variables specified in my message, because I was unaware of the use configuration option.
This is important for working with a custom IP so I suggest there should be a link to the CLI config page from the Localhost section of the installation instructions.
EDIT: I am not using use <ip_address> to configure the CLI because I’ve hit an issue with port binding on 8884 and needed to specify a different port. The use configuration didn’t seem to play nicely with this so I’m once again using env vars in docker-compose.yml.
I think it would also be helpful to add this to the config instructions for ttn-lw-stack-docker.yml when using a custom IP, because it is currently not mentioned
Done, great input, thank you → doc: Add localhost certificates note by benolayinka · Pull Request #147 · TheThingsIndustries/lorawan-stack-docs · GitHub
What’s the issue with port binding?
1 Like
SSL Port 443 is redirected to Port 8885 inside the container in our example docker-compose.yml, so this shouldn’t be necessary. What did you experience without adding these?
Something on my windows machine is listening on port 8884 (the process belongs to System so I can’t kill it), so I had to bind 3884:8884 instead of 8884:8884.
I tried ttn-lw-cli use 192.168.1.13:3884 but that didn’t work:
/ # ttn-lw-cli users list
WARN [core]grpc: addrConn.createTransport failed to connect to {192.168.1.13:8884 192.168.1.13:8884 <nil> 0 <nil>}. Err: connection error: desc = "transport: error while dialing: dial tcp 192.168.1.13:8884: connect: connection refused". Reconnecting...
connection error: desc = "transport: error while dialing: dial tcp 192.168.1.13:8884: connect: connection refused"
Specifying 192.168.1.13:3884 in the ttn-lw-cli environment variables worked.
I don’t have my linux machine on hand right now, but I think ttn-lw-cli use x.x.x.x would work fine there as it doesn’t have any clashes on port 8884
You are correct, that adding :8885 to those urls is not necessary. I thought I was getting caught in a redirect loop the other day but I just tried to reproduce it and I cannot, so that must have been a separate issue.