Our internal domain is a public suffix, example.com. We have application servers that can only use their own CSR (no access to the OS) and these add entries to the SAN that Let’s Encrypt finds invalid (hostname with no domain suffix for instance). So domain-validated, manually created certificates cant be made.
We are happy to install our own CA for our domain and issue certificates for these edge cases but it would perfect to have our internal CA become a sub-CA and so the certificate chain is publically trusted. Or am I misunderstanding something and wishing for the impossible?
we have certbots working flawlessly for IIS websites and want to use it more for other things (VPN connections, telephony etc) but are frustrated by the application vendors implementation of raising CSRs.
Currently, i don't think Let's Encrypt have any plan to allow other operate a subCA under their root certificate. (As this have been asked in previous threads)
Let’s Encrypt’s delegation from the DST root has a path length constraint which would prevent Let’s Encrypt from designating any other sub-CAs (at least using that path). Currently, Let’s Encrypt does not offer this kind of service at all; Let’s Encrypt is only meant for issuing publicly-trusted certificates, which are subject to industry rules that require that they be FQDNs controlled by the subscriber who receives the certificate.
Creating sub-CAs would be very costly for Let’s Encrypt because of audit requirements and human intervention. The reason that Let’s Encrypt certificates are free of charge is that the entire DV issuance process can be automated, so there’s no marginal cost in human labor for issuing a new end-entity cert. But this woudn’t be true for a hypothetical sub-CA delegation, which would involve human beings reviewing policy documents and contracts—expensive activities.
Normally, in order to operate an internal CA you’d have to add trust for your internal CA to all of the devices that are going to accept its certs.
Is your organisation a publicly trusted Certificate Authority? No? Then what you want is impossible. Sub-CAs should obviously also be trusted. Otherwise, the "origin CA" would loose their trust if they'd enable non-trusted sub-CAs.
If there was a way to restrict sub-CAs to only issue certs for the domain they own/control…
But that is not the case.
A sub-CA would be able to issue valid certs for any and every domain out there.
The name constraint extension exists, though clients don't necessarily implement it.
The old Let's Encrypt X1 and X2 intermediates used a name constraint to block .mil for contractual reasons. (Which is why Windows XP rejected them, IIRC.)
I shall continue with plan A of using LE for externally facing resources and internal for internal only and distribute the trust of our CA around the internal servers with GPO etc
You can also proxy those systems and secure the connections.
Via full FQDNs to the proxy.
And then only the proxy would have to trust the individual SHORTNAMEs.
Could save some time - depending on how large the many-to-many area is.
Breaking it in two; A many-to-one and a one-to many.