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) 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) 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) D dns isn't a good place to put this sort of stuff IMHO 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 >We could use a CAA record to prevent a cert from being issued using the >default LE endpoint, but >it would be nice if we could have a SRV record similar to > > _acmev2._tcp.example.org ..... acme.services.example.org > >that clients could use to auto discover what the appropriate directory >endpoint is. > >I could see one additional requirement that the SRV record must point >to a server under the same domain. > >Is this a crazy idea? > > >Justin Azofff > >_______________________________________________ Acme mailing list >[email protected] https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
