Subject: [Acme] Discovery of directory URL

From: "Azoff, Justin S" <[email-masked]>
Date: Mon, 12 Mar 2018 19:02:28 +0000

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.

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 Azoff

---

From: Alan Doherty <[email-masked]>
Date: Mon, 12 Mar 2018 23:39:34 +0000

I wouldn't be a fan 

>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

>Justin Azofff
>_______________________________________________ Acme mailing list [email-masked] https://www.ietf.org/mailman/listinfo/acme

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 13 Mar 2018 12:40:13 -0400

>
>
> if the client is hardcoded for LE its not designed to be used with other
> acme services (so inappropriate to use with others)

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-masked]> wrote:

> if the client is hardcoded for LE its not designed to be used with other
> acme services (so inappropriate to use with others)
> 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)
>
> 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
> 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)
> 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)
>
> 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
>
>
>
> >_______________________________________________ Acme mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/acme
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: "Azoff, Justin S" <[email-masked]>
Date: Tue, 13 Mar 2018 16:42:17 +0000

> On Mar 12, 2018, at 7:39 PM, Alan Doherty <[email-masked]> wrote:
> 
> I wouldn't be a fan 
> 

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

> (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 o…

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.

> 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