Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Ability to customize where linux hosts load the TLS key material from #5944

Open
kquinsland opened this issue Jan 27, 2025 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@kquinsland
Copy link

Platform

Linux Native

Description

I am in the process of adding LetsEncrypt/Certbot to my meshtastic-on-debian node and was curious about where the key material lived so that I could provide my own...


After a bit of digging, found that the web server will generate it's own certificate if one can't be found

But where does the webserver look for the certificate?
I can't find any directive in the config.yaml file that would let me set this :(.

I can see that the key material has hard-coded names: certificate.pem and private_key.pem.

But those are just file names... there's no path/folder structure in the code!

Where do those files live? Let's try to find them:

root@meshtastic:/# find / -name "private_key.pem"
/private_key.pem

One result and it's in the root!?!! I bet it's sibling is there, too:

root@meshtastic:/# ls -lah *.pem
-rw-r--r-- 1 root root 1.1K Jan 18 19:02 certificate.pem
-rw-r--r-- 1 root root 1.7K Jan 18 19:02 private_key.pem

The file names match up, but let's confirm:

root@meshtastic:/# openssl x509 -in /certificate.pem -noout -fingerprint -sha256
sha256 Fingerprint=56:D3:F6:<omitted>:0B:CD:30
root@meshtastic:/# openssl s_client -connect meshtastic.local:443 -servername meshtastic.local < /dev/null | openssl x509 -noout -fingerprint -sha256
depth=0 C = DE, O = Meshtastic, CN = meshtastic.local
verify error:num=18:self-signed certificate
verify return:1
depth=0 C = DE, O = Meshtastic, CN = meshtastic.local
verify return:1
DONE
sha256 Fingerprint=56:D3:F6:<omitted>:0B:CD:30

Yep! The fingerprint for the file (/certificate.pem) matches the fingerprint from the web server.


The Ask

Please extend the config.yaml file to allow setting a directory where key material can be set/read from.
The "generate if not found" behavior is good and should be kept, the ask is for a user-configurable directory to be used instead of /.

Ideally something like this:

Webserver:
  Port: 443 
  RootPath: /usr/share/meshtasticd/web
  tls:
    # Dir that is prefixed to argument fed to `read_file_into_string()` calls
    path: /etc/meshtasticd/pki       
    # Allow specifying the cert/key name. If not explicitly set, keep the defaults
    cert: certificate.pem                  
    key: private_key.pem

Which would result in the webserver reading key material from /etc/meshtasticd/pki/{certificate,private_key}.pem

The why

There are a few reasons but they boil down to

  • Nobody likes a messy /
  • I am trying to build a more sophisticated node that leverages a read-only file system for most things. It is impossible to do this well if / needs to be writable. Ideally, only the /root/.portduino directory would be on a writable partition and everything else would be loaded from a read only partition
  • It's a lot easier/cleaner if I can pick the directory where the file(s) are read from, especially for hooks/scripts that are called after CertBot gets a certificate issued to it.

Related, I think but I'm not sure if the ticket is just asking for TLS support or the ability to change settings about TLS.

#5740

@kquinsland kquinsland added the enhancement New feature or request label Jan 27, 2025
@fifieldt
Copy link
Contributor

Thanks for the detailed investigation. Yes, specifying TLS cert location is a fairly standard ask for linux daemons, so we should probably do this :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants