In practice most non-Internet PKIs don't actually want to do proof of control which is ACME's secret sauce. As you'll see much of the document is about the proof of control, because that's both the hardest problem and the only reason for ACME to exist at all.
In private PKIs either proof of control over the name is considered an out-of-band problem or it's elided altogether. I wrote about this when Peter Gutmann was being angry about ACME years ago, Gutmann saw ACME as redundant because of existing protocols like SCEP. If you want certificate issuance automation but you don't need proof of control over the names then you don't need ACME - SCEP (or half a dozen others) are fine for this purpose and you should use those.
Now, of course if you don't want proof of control but you do want automation it's worth taking a moment to reconsider exactly what your goals really are: What is a certificate doing for me here? What exactly am I certifying, if anything? But if the technical requirement is there, regardless of whether it makes philosophical sense, SCEP delivers and ACME is overkill.
As I wrote in my thread with Peter, it's usual with things like SCEP to provide a default implementation in which the part where you only give certificates to the Right People is left marked /* TODO */. Thus often the result is pure security theatre, certificates are issued equally to bad guys or good guys without distinction and nothing at all is really being certified.
Manual processes may or may not be better in terms of actually certifying anything.
Sure, distribute your own root CA, but then how do people get signed certificates? I tend to work with large companies, where getting a signed certificate involves opening a ticket and waiting for someone on the other side to respond.
ACME would be ideal, but the official response of Let's Encrypt is that ACME is overkill for corporate environments and you should roll your own certificate automation.
Delegating enroll permissions is a solved problem technically at least in a windows domain. At that point it's an org policy problem and ACME won't help.
In an enterprise, you use the API that a CA provides, and build it into the ticketing system. I helped build a system that took care of this with ServiceNow a few times now.
At one place we aggressively policed external facing certificates. Don’t follow the process, your service gets whacked.
It’s a process you should look into, because the compliance regimes will start paying attention to it someday soon.
Unless your DNS public. That still allows Let's Encrypt to verify you and is actually used by RavenDB to provide SSL certificates to internal instances.
