I deal with data center equipment such as BMCs, routers, switches, etc.
These all have web interfaces that need HTTPS Certificates. However most
all of these devices are behind firewalls and often do not have a FQDN.
I realize this is a tall order to fill using LE and ACME.
But just looking to see how others have solved theses types of issues.
I also am a developer for such data center equipment as well.
With wearing this hat I am looking for advice on how to reduce
the issues I described above so new products are more secure
and less reliance on self signed certificates. As having customers
constantly having to "Proceed Unsafe" I find embarrassing and annoying.
Take this opinion with a grain of salt because I haven't had to use this type of equipment in many years now.
Taking LE/ACME out of the picture entirely, historically these devices have terrible web interfaces for managing the certificates they use, they rely on ancient versions of cryptography libraries, and have poor API support if they have an API at all (needing to run commands via SSH doesn't count as an API). So even before you think about how to get the certs, you have to deal with how you're going to import them to the devices. And if you have a lot of devices, you're going to want a way to do it that doesn't involve manually logging into a web interface or SSH console.
Assuming you've solved the cert deployment problem, then it's more a matter of privacy and scale. While you can get public (LE or otherwise) certificates for internal-only hostnames if you can satisfy the challenges via DNS, all of those names are still submitted to Certificate Transparency logs which some argue gives potential attackers "sensitive" info about your network.
From a scale perspective, if you have on the order of 10's of devices and you've accepted the security implications of CT logs, it's totally reasonable to get public ACME certs for them. But too far beyond that, and you start getting into potential rate limiting issues and just general impolite abuse of free services. Most orgs with a large internal device presence like this have an internal PKI that is a better fit for certificates for these devices. With an internal PKI, you also have the freedom to generate certs for IP addresses and non-public DNS names.
As a developer for these devices, you're in a very similar boat to the IoT device providers in terms of what choices you have for pre-configuring certs on devices or allowing devices to provision their own certs. Users tend to like options though. While one org might be fine with a device that is capable of provisioning its own public ACME cert, others will likely want it integrated into their own internal PKI. Some manufacturers may even host their own non-publicly trusted PKI and ask clients to trust their CA. There's really no one-true-way to do it and each solution has tradeoffs.
Thank you @rmbolger ; I agree with everything you said.
Just thought it was worth seeing if there better ways to
provide a good user experience. I do not like being trained
and training users to "Proceed Unsafely", it just feel wrong.
I would consider including the cert within the code update.
That also leads to multiple paths:
globally signed cert
locally signed cert
Both have their pros and cons.
I would also consider getting a wildcard cert.
[with the benefit of great scalability]
You then only need to have the local DNS point to the local systems for their specific FQDNs.
It would be great if there was a standard API devices could use to fetch and use a certificate, e.g.
Each device:
boots up (and on a regular schedule) contacts a local (or cloud) API using it's own credentials (configured on the device once). Trust store gets updated with required roots and intermediates.
device refreshes its credentials (if required, i.e. a fresh auth token)
device gets it's latest certs from the API (as determined by the cert administrator)
device applies the certs as necessary
Cert API:
manages which devices can get which certificates
performs cert renewal independently of cert consumers, from any CA (could be internal CA)
I assume this already exists in various enterprise PKI things but for it to be easy you'd need a simple way to set it up in the management interface for each equipment item. You'd know better than me if there are any standards in this area.
[You can use SSH per device to push certificates, if each device supports that, but it's complex and brittle].
