I am not sure whether hints to commercial products are okay in this forum. If not, please excuse.
At Secorvo we have a brand new product offering of an ACME enrollment gateway, branded “EaSy - certificates ready2go”, that acts as a proxy between internal ACME clients and external CAs like Let’s Encrypt - provided that the internal systems use only registered DNS names that externally point to the enrollment gateway in a split-DNS configuration.
Using the enrollment gateway it becomes possible to enroll Let’s Encrypt certificates for appliances etc. that usually are never connected to the Internet. Therfore we are also looking into getting ACME clients to work on boxes that are not running one of the standard OS platforms.
Currently we have an acme.sh based prototype running that enrolls (and of course automatically renews) certificates directly from a VMware ESXi hypervisor.
Best regards,
Hans-Joachim Knobloch
Secorvo Security Consulting GmbH
Could your ACME gateway store and share the same certificate to different ACME clients, if they submitted matching CSRs (same identifiers, same public key)?
For example, to re-use a wildcard on different appliances without issuing N different certificates. Or to share an identical certificate to a clustered services.
This is not yet a feature, but we might add such a functionality. The issued certificates are already stored in the gateway’s database for auditing, troubleshooting, statistics and manual revocation (all available through the gateway’s web UI).
One difficulty would be to differentiate such a “secondary” request from a regular cert renewal request. But maybe that could be solved by doing a renewal with Let’s Encrypt if the stored certificate has less than x days lifetime and delivering the stored certificate otherwise.
The bigger issue would probably be how to transfer the private key between the “cluster” members. This is not an ACME feature and must be securely done out of band.
And even for a cluster the question is why you would require identical keys and certificates instead of multiple certificates issued for the same subject and SAN names. Except of course that either you run against Let’s Encrypt’s rate limits and/or you need to configure info about the certificate identically on all cluster nodes (like the ominous registry value with the cert hash on MS SQL Server clusters).