I'm currently working on an embedded Linux project that includes a local web dashboard managed by Nginx. This interface allows users to configure hardware parameters locally, without any public access. We recently added HTTPS support and are trying to figure out the best way to handle the certificate management long-term. My three options are:
A) Pre-generate a self-signed certificate and include it in the root filesystem.
B) Dynamically generate a self-signed certificate with each build.
C) Use a trusted Certificate Authority, such as Let's Encrypt or an internal commercial CA.
Since we release software updates every few weeks, I want to ensure that our HTTPS implementation is stable and future-proof. We're also planning to introduce login/auth features and possibly integrate with cloud services (like OneDrive and Samba). Given that this device operates in a semi-offline mode, what's considered the best practice for managing HTTPS certificates? Thanks in advance for your insights!
6 Answers
Just a heads up—Let's Encrypt certificates have a valid lifespan of only 90 days. Plus, why does an isolated/internal network even need HTTPS?
How about generating a self-signed cert on first startup and allowing users to add their own certs if desired? There should be an option to register their certificate with your system; that way, you don’t have to keep it on file.
I suggest going with option C, but you'll need a plan for renewing certificates, as they can't last indefinitely. A good approach would be to set up a private VPN on each device, like WireGuard, so you can push certificate updates securely. You might find this method more manageable in the long run.
That's a great suggestion! I initially overlooked the need for updates because these devices are running an older version of Ubuntu. I'll have to run some tests to see if adding this VPN layer is feasible.
Absolutely choose option C, and automate the whole process! Even if you need a domain for validation, you don't have to expose the server, just use lightweight HTTP or DNS verification. I’ve made it where I can get certificates in minutes, including wildcards and SANs. It simplifies the entire process, and trust me, you don’t want to go with options A or B.
Great tips! The challenge for us is that our devices often sit behind NAT on customer networks, making DNS validation tough.
Going with a trusted CA (option C) is ideal, but it can be tricky since your devices are not internet-facing. If that's the case, I’d recommend option B—dynamically generating self-signed certificates during each build. Additionally, consider allowing users to import their own certificates if you can manage that later on. It can simplify things for isolated environments.
Thanks for your insight! I'm intrigued by the idea of user-imported certs but need to learn more about how that works. I want to keep things straightforward and user-friendly.
If you're accessing through local IPs, you’re limited to options A or B. Most users would see the warning that the site is untrusted. For proper security, you really need a fully qualified domain name (FQDN). If you're targeting professionals, consider setting up a system where they can route subdomains to internal IPs, allowing valid certificates. A cloud-based configuration tool, while complex, is ideally suited for effective management.
You make a valid point! We've decided to stick with unique self-signed certificates for now and face the browser warning, but I want to come up with a solid long-term solution. The cloud-based management system definitely sounds like a better approach, albeit more complicated.
I completely agree! This approach feels more secure and customer-friendly for the long-term, so I'm looking into it.