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 
>Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme 

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to