> On Mar 12, 2018, at 7:39 PM, Alan Doherty <i...@alandoherty.net> wrote:
> I wouldn't be a fan 
> At 19:02 12/03/2018  Monday, Azoff, Justin S wrote:
>> I've been investigating the possibility of offering an ACME compatible 
>> endpoint for local users
>> to use to obtain certificates through our normal CA process.  One of the 
>> issues I have identified
>> is that if I were to run a local ACME server, every client would have to be 
>> configured to point at it.
>> Some clients only have a 'staging' flag, and don't even allow specifying the 
>> full endpoint.
> if the client is hardcoded for LE its not designed to be used with other acme 
> services (so inappropriate to use with others)
> most acme clients aren't as its configurable on all I've used 
> and of those that are hardcoded for LE most are open source (so maintaining 
> your own version hard coded for your private acme would be easy)
> but as many users could/would 
> A have multiple domains they obtain certs for (san certs)
> user A (webserver admin at company providing web services for example ltd.)  
> uses acme provider 1 for the public SAN for http covering www.example.com 
> www.example.net www.example.org
> (thus if any of these 3 specified a different provider by some dns method it 
> messes with this)

Sure, but a CAA record would also mess with this.

> B have potentially multiple acme servers that would be used by different 
> clients for the same domain
> user B (mailserver admin at company that provides/maintains mail serveces for 
> example ltd. ) uses acme provider 2 for the public SAN for smtp-tls 
> mx.example.com mx.example.net mx.example.org
> public SAN for http covering webmail.example.com example.com example.net 
> example.org mx.example.com mx.example.net mx.example.org  1 being a real site 
> (the others being a 301 to www.whichever)
> (thus any provider specified in example.com would break same)

a CAA record blocking a specific acme provider would have the same affect.

> C its much easier/faster to point a client at a single trusted(by you) acme 
> server at setup than to modify potentially countless dns zones (or setting up 
> local pinholes for customer zones just to override their choice of acme 
> provider that your admin may disagree with)

Ah.. this is probably the biggest difference from my standpoint.  We have 
primarily one domain, but a large diverse user base using many different 
clients - certbot, kubernetes ingress controllers, etc.

> D dns isn't a good place to put this sort of stuff IMHO

Perhaps.. I figured since a CAA record could block LE, a similar record could 
redirect it instead.

> E even in the simple one domain small org scenario say all clients talk to 
> private example.com  acme server to obtain internally valid certs
> but the 1 in-house server needing to talk to LE (or some other) to get a 
> publicly valid cert for www.example.com or mx.example.com etc can't because 
> this record exists in in-house dns zone

I suppose..

Justin Azoff

Acme mailing list

Reply via email to