LetsEncrypt Certs Functional?

[trafflux]

Is anyone able to skip the absolutely unusable user onboarding flow of self signed certs having to be manually downloaded and applied for the client connections? I have traefik proxying and its using CF api to generate certs for my subdomains so they can use ssl, one of which is ots. I have 443 going to the webui and 8089 tcp routed for the api. This should be the bare minimum for only SSL connections.

There's a lot of issues with this project outside of this and really the only thing civil i can say about it is that it needs an overhaul and docker deployment should be the highest priority. And really, this ought to have the LetsEncrypt API as part of its install process. Self signed certs are sketchy as hell and having to onboard people of different tech levels and trying to get them to save & install certs on iphones etc is a laughable prospect. Onboarding should be send email invite link. User clicks, sets password, and any basic account details. Or admin emails login credentials and users go straight to itak/atak etc and logs in. No zip files or playing tech support for 20 guys to get their iphone to accept that joebob's janky self signed cert is totally trustworthy.

[brian7704]

Sounds like you don't have a full understanding of the software architecture and you've setup traefik incorrectly.

There are three main ports used for SSL connections in the TAK ecosystem, 8089 (socket connection for CoT data), 8443 (https), and 8446 (https for certificate enrollment). OpenTAKServer additionally uses 443 for its web UI while the official government takserver uses 8443. A list of all ports and their uses can be found in the documentation..

You should be proxying ports 443 and 8446 with your Let's Encrypt cert. This will remove the certificate warning when browsing the UI and also allow your users to be onboarded using certificate enrollment without needing to download and import your server's public truststore certificate first. It will also allow them to be onboarded using a QR code.

Ports 8443 and 8089 need to use the self signed cert. The self signed cert is important because the client certs are generated from the server's certificate authority. Then when clients connect they use their client cert to verify the server's certificate as well as to authenticate. This ensures that only clients with a certificate signed by the server's CA can connect. It also lets the clients verify that they're connecting to the genuine server and not an attackers imposter server. This behavior is identical to the official government takserver.

There's a lot of issues with this project outside of this and really the only thing civil i can say about it is that it needs an overhaul and docker deployment should be the highest priority

What other issues have you seen? As for needing an overhaul, I'm open to both suggestions and PRs. And there is a community made docker image as well as one that I'm working on myself. You're also free to make your own.

And really, this ought to have the LetsEncrypt API as part of its install process.

Self signed certs are the default for ports 443 and 8446 because not everyone has a domain name and exposes their server to the Internet. For those that do, there are instructions in the documentation on how to get a Let's Encrypt cert. For this reason the installer won't incorporate the Lets Encrypt API.

Self signed certs are sketchy as hell and having to onboard people of different tech levels and trying to get them to save & install certs on iphones etc is a laughable prospect

I disagree that self signed certs are sketchy for onboarding. In order to enroll on a server with self signed certs, the client needs the server's truststore cert to do verification. As long as the truststore cert is passed to the client using secure methods there is absolutely nothing wrong with using self signed certs. Though I do agree that it's cumbersome and difficult for the average user. That's why there is documentation for the server admin to setup a Let's Encrypt cert.

Onboarding should be send email invite link

Users are able to register their own accounts if the server admin enables email support. If you'd like to submit a PR for an email invitation link I'd be happy to merge it.

Or admin emails login credentials and users go straight to itak/atak etc and logs in

While I highly discourage emailing usernames and passwords, there's nothing stopping a server admin from doing this already assuming they've setup a Let's Encrypt cert on the server. In that case no zip file is required.

No zip files or playing tech support for 20 guys to get their iphone to accept that joebob's janky self signed cert is totally trustworthy

Again, the self signed cert is validated by the the client using the truststore cert and assuming the truststore cert is passed to the client by secure means, trust can be verified

[Humble-Helper-96]

I just stood up a test server about a week ago using Lets Encrypt. The process was pretty straight forward and on-boarding is now as easy as having the user scan a QR code where they are prompted for a username and password. Done. So far the server has been stable the entire time and only needed a few "bugs" fixed after the install.

I tossed together a whole markdown file outlining an install so it can be repeated if you would like it?