> > > 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
Many ACME clients default to using the production Let's Encrypt directory endpoint URL, but it is *very* often configurable. Certbot, ACME4J, Dehydrated, acme.sh, win-acme, and many other clients certainly do. I don't believe the assertion that a client that defaults to the Let's Encrypt production directory URL is not designed to be used with other ACME services. - Daniel / cpu On Mon, 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) > > 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 >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
