It works just fine! This is a general question and I don't really know where to ask it. Using a command line (e.g., openssl) is there a way to effectively use the certificate for this domain as an 'intermediate certificate' and sign other certificates using it?
Here is the use case: We sometimes deploy edge computing devices within a client network. Those devices do not have an actual domain name, and may not even have general access to the Internet because of firewall rules. The devices have access to our backend (and specifically to the domain above). We would like to have the various OTHER devices on the client network access the edge computing device using TLS. To do this we need to issue a certificate with a SAN that is its IP address and then access it using https://ip.add.re.ss/ whatever. But mobile platforms such as Android will not permit access to this via TLS if the site is self-signed. It needs to have a real root certificate.
So what we hope is there is a way to have our registry server issue a signed certificate for the edge device that WILL have a valid root certificate by using our domain cert as an intermediate. Is this possible?
Even if you could get a cert from LE, they would only last 90 days.
That wouldn't be valid for very long in such a closed environment.
It sounds like you would need to create your own CA and make certs from it.
But then all your clients would have to trust your CA [as a root CA].
So, you really would need to ask for a cert from the clients' CA [if they have one].
That way, they would be in control of the certs they trust [since they issue them].
The long answer is also No -- you can't sign other certificates with a leaf certificate, and you can't generally get an intermediate from a trusted CA. There's a generally different approach to solving this, though.
You do need to get public names for your devices to use a public domain. You probably want to purchase a domain for this, or use some subdomain of an existing domain.
Your backend needs to assign a unique ID to each edge computing device, and then map a name like abcd1234.device.example.com to whatever the appropriate IP address is. That could be handled during initial setup of the device.
Your edge devices should phone-home to your backend, tell it what its IP is probably to update DNS, and probably provide a CSR for a key it has generated. The backend uses Let's Encrypt's APIs to issue that certificate, probably using DNS validation, and provides that certificate to the device.
As an example of where this is deployed, Stripe Terminal readers get a name like [random-string].device.stripe-terminal-local-reader.net which are issued by their backend.
Your application/website which needs to talk to the devices can get the hostnames to use for local communication from the backend API.
You can't get new certs issued by an end leaf certificate. There are measures against that (set in the certificates themselves). If you'd like to issue your own publicly trusted certificates, you'd need to bring a lot of money and make an arrangement with a publicly trusted CA and become a "(Technically Constrained) Subsidiary CA" (but Let's Encrypt doesn't offer that).
Usually for local certs one simply sets up their own CA with their own root/intermediates and adds those root(s) to the local systems.
I still think there is an inherent trust issue created when the device potentially might have no Internet access.
Which can only be overcome by having the clients issue the certs themselves for you to place in the device that they will be using.
OR
Use a domain that is obviously NOT of a real trust concern - like: example.com
Anyone can use such a domain with a self-signed certificate and just have the clients add that cert as trusted. [not from a private CA - that creates a possible misuse/abuse]
Now that I hear myself say that, they can "trust" any self-signed cert you put there [even something that ends with your real domain name - just NOT a publicly signed cert for it].
If that is too convoluted ...
You could ask the clients to place your device behind a proxy they operate [then they can put whatever name/cert they want to access it].
So that only the proxy would see the device [and it might even do that part via HTTP (if close enough to it)].
There are a handful of popular methods to handle your situation.
If you control the devices, using your own CA and installing it's root is often a good idea.
Someone mentioned Stripe. A variant of that technique was used by one of the streaming device makers a few years ago - I don't recall if it was slingbox or plex, but I am sure one of them had done this and shared their technique publicly. IIRC, they would pre-generate the domains to get certificates (via http-01 or dns-01), and on bootup/reset/periodically, clients would fetch a new cert from their server via an API and also instruct their API to change the public DNS for that hostname to the local IP address of the device. Everything was coordinated by a cloud API.
There are a handful of posts in this forum with other techniques that worked, and some that did not. I recall one company has a lot of bricked/worthless devices in the wild, because they did not build in an ability to update the trust stores or install new technology – and those devices have neither a useable trust store, or the ability to speak modern TLS levels or ciphers.
The archives here will have a lot of the information you need.
You should add your Root Certificate's Public Key to the devices as a Trusted Root, issue your first Intermediary Certificate from it, then very securely store the Root's Private Key offline.
Ideally you will never have to change the intermediary, but you should ensure your app can handle the Intermediary changing in the future. Perhaps there can be an API endpoint that publishes active intermediaries and suggests what should be favored during issuance; your app can check that endpoint if it receives a new Intermediary and needs to reconfigure itself.
