The operating system my web server runs on is (include version): latest
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): HA
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): na
This seems to confuse many so I am starting a new topic. What is the easiest way to get https working on an exiting LOCAL web server with NO internet dependence??? By that I mean no access to the cloud/internet. COMPLETELY local. Move everything to ssl and shut down port 80/http on the server entirely.
What I am actually trying to do is change a HAOS server from local http to local https. HA has a Let's encrypt plug-in, but all of the instructions are geared toward remote access. Remote access (via internet), is NOT what I am trying to get. See above.
As near as I can tell, I need to gen a self signed cert, pki keys, and then distribute manually? Where does Let's Encrypt fit into this?? TIA!!!
Sure, you can use a self-signed cert and Let's Encrypt is not involved at all. Each device you connect with will need to recognize and trust that self-signed cert.
Let's Encrypt requires, at minimum, your domain name to be in the public DNS system. These are publicly trusted certs, after all.
EDIT:
This isn't exactly your situation but you may find it helpful
step certificate is a pretty handy command for creating your own PKI hierarchy. I use it regularly at my day job. Much better than the hell of trying to do things with OpenSSL.
It doesn't, at all. Obtaining and renewing Let's Encrypt certs requires Internet access, which you've said you don't want for the system in question. Create a self-signed CA and distribute its cert to whatever client systems will be accessing the system. Use that CA to sign a long-lived cert for the HA machine. Then configure that machine for SSL just as you would with any other cert.
Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
Thus you need to own and have control over the Domain Name (or have a subdomain under an existing domain name, for example pointed to your server by your employer or school) you wish to obtain a certificate for, from an ICANN Accredited Registrar.
No domain name at all. It is a private IP address on a web server. It seems issuing legit certs to private IP's is heavily frowned upon and most CA won't even allow it.
That totally makes sense......for internet web. I am just surprised that no one has come up with a clean solution for local/private IP on ssl. I see many asking for the same thing that I assumed was created since the last time I did this years ago. Some combination of local dns and key/cert management would add to the security of the many who are running local web servers. I see sooo many asking for a solution here. I am shocked nothing better is out there. I smell opportunity, but I more focused on embedded dev. I think Let's Encrypt should step up. C'mon....be a hero.
You're asking for something that the current web/browser PKI simply cannot solve. It's like asking "I want a car that drives at 300 km/h, but it must use no energy!".
Non-routable IP addresses are by definition not unique: Anyone can use them as they like. Your subnet might use the IP address 10.2.3.4, and so do I. Now, imagine you were able to get a publicy trusted certificate for that IP. If you can do that, so can I - since I use that IP address too! Therefore, we both have a certificate for the same IP. Now, since I have a valid certificate, I can use that for an attack against your systems. Once I break into your LAN, I can spoof all your certificates. That gives you exactly the same security you would have if you were using no certificates at all (which you can do by the way, this is called unauthenticated operation).
The web PKI works like a notary: It assures the entire world that some entity (an operator, or subscriber in ACME-speak) controls another entity (an IP address, a domain name, email address...). Now, if that entity is not unique that assurance becomes impossible to make, because everyone controls it, making the entire idea of assuring identity useless.
If you run your own PKI you can avoid that issue, because that's not global: It only operates at a local scale and is only trusted at a local scale, so certificates created by my PKI are not trusted by yours and vice versa. This is actually an advantage, because it maintains authenticity on both PKI systems. Of course it may mean more work for you - setting up a PKI can be really hard - , but it's the only way to ensure security.
If you're just looking for software to setup your own PKI, there are various options available:
Smallstep, which is available both as a local and hosted product
Dogtag, a fully-featured PKI system for various RedHat systems
EJBCA, another fully-featured open source PKI system
CFSSL, an intentionally simple software to manage local certificates and PKI
Boulder, the CA software that Let's Encrypt runs on
And many more not listed here
For certificates for development/local webservers in particular, there are many more solutions available. A search for "certificates for localhost" on Github shows over 40 repositories. Let's Encrypt also maintains an article about this topic, which mentions the typical OpenSSL solution.
OpenSSL is kind of the proverbial kitchen sink; it supports all sorts of weird and obscure features of X.509 and TLS and encryption. And its configuration file formats (when using openssl ca) are also fairly arcane.
It is wonderful that OpenSSL is available and can do almost anything we might need related to TLS and PKI, but it's not exactly optimized for convenient use for any specific PKI task (although openssl x509 and openssl s_client are positively awesome for debugging purposes).
An analogy here might be trying to register a business and insisting that one's address is "The top floor of this building" (or maybe "Suite 32 of this building").
Yes, it might be perfectly true! But unfortunately that address has a different meaning depending on who is saying it, and so if the business registry accepted it, it would naturally be expected to lead to unacceptable ambiguity and confusion. From other people's point of view, there are many other completely different places that are also accurately described by that same reference, and so you don't want a public registry asserting that a particular entity "owns" it in an absolute sense.
If Let's Encrypt would start issuing certs for non-public entities, their root certs would be removed from root certificate stores and there would be no Let's Encrypt left.
Get a public name and issue public certs for it. There’s some solutions for this, like Plex does: How Plex is doing HTTPS for all its users . Let’s Encrypt can issue these. This isn’t “completely local”. Some other services like Tailscale VPN can also issue certs like this using LE.
That is because doing so would create a giant security flaw for all users.
There are hundreds of options: ranging from creating a self-signed cert (like @MikeMcQ suggested), to using tools like step (which @_az suggested or the other tools like @Nummer378 and @mcpherrinm suggested).
All of those require the browsers/clients to opt-in to trusting your personal root certificate, because it is fundamentally impossible to let someone create trusted ad-hoc certificates while also maintaining basic security promises for everybody else.
Simply put, you can not have a publicly trusted certificate without some sort of internet access - which is required to prove ownership of the domain name or IP address. (LetsEncrypt does not offer IP address certificates, select other CAs do, however the IPs must be public and publicly validated; reserved private ranges are ineligible). If you can not let Certificate Authorities validate a public domain or public IP address, you can not rely on the public root certificates packaged with browers/clients/operating-systems and must rely on your own Root Certificate and installing it on clients.
Help to understand that comment. How does creating a local cert on a non-routable IP create a flaw for "all" users? It would only be known and used be me and my devices. On my network, trust should be what I say it is. On the public net, completely different.
Imagine you create a cert for 192.168.0.1 or router.local on your network from a globally trusted CA on your network, but then you bring that cert over to my network: now you can impersonate my router.
This is why private networks need private CAs, so they can be scoped appropriately.
Also the CA is a remote API to request certificates, so it’s not going to be completely local. So you need a piece of software, not a service.
I believe there should be easier solutions for this, but it’s outside of what Let’s Encrypt does. Some sort of network-scoped secure transport with a local issuance plan would be doable but that would require significant cooperation of browsers, operating systems, and embedded devices to get it all working together. The closest thing to this is Tailscale VPN offering certs, but they just use Let’s Encrypt so it’s not totally local — but they handle the challenges etc.
Thanks, I followed about half of that. Where the term "CA" is used can make things more confusing. I think we agree that locally scoped https should be easier. Something that requires no config on the clients. I am ok with a complex server config to achieve zero, or near zero config on the many types of clients I use. When I think through all of the possible connections to my HA server, including software integrations, I definitely need something that minimizes client requirements. I need to re-read through all of these posts and some that I have going on another forum. THANKS again!!
Explaining this a bit more: the private address spaces are private - not public - so they can and do overlap. If you are given a publicly trusted certificate for 192.168.0.1, that doesn't just work on your private network but will work on any private network – so you could easily impersonate any of the network devices at a business, university, vpn, coffee shop, etc -- or if you were able to get onto a private home network like @mcpherrinm's, you could impersonate the router.
That is fundamentally impossible with the current Internet architecture and modern Browser Security.
You must either configure the clients to use the publicly trusted roots (PUBLIC Certificate Authority roots), or explicitly configure them to use a PRIVATE Certificate Authority (either one of the projects mentioned above, or a self-signed certificate).
The CA/B forum and browser/software/os vendors coalesced onto this security model, because requiring zero configuration for the average end-user was the most important thing to achieve. While the architecture and goals you are trying to implement is incredibly common... it is the expected and accepted outlier to the standard security model. That is why there are hundreds of open source projects and commercial services that exist to streamline implementing it, by creating and managing a private CA, and deploying its' private roots to devices.