> On Mar 12, 2018, at 7:39 PM, Alan Doherty <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/acme
