As the one who asked you to mail the ACME list, no apologies needed. Glad you've got a path forward!
On 08/18/2016 01:00 PM, Jostein Kjønigsen wrote: > I would like to thank everyone for their interesting and insightful > feedback to my email. It has been above and beyond expectations. > > I was unaware of the fact that the ACME client is supposed to follow > redirection, but armed with such knowledge I should be able to devise > a workaround to support the scenarios I have envisioned. > > Sorry for bothering you all, with what in retrospect seems to have > been a tech-support like issue. > > My only excuse is that I was explicitly told to do so. I hope I can be > pardoned :) > > -- > Best regards > Jostein Kjønigsen > > > On Wed, Jul 27, 2016, at 04:22 PM, Alan Doherty wrote: >> currently they can in the acme client >> >> one method is dns auth (the client is run on the machine with access to >> dns records and authenticates each at same time) >> >> another used by many is as the client follows redirections >> >> on primary domain and each sub-domain server redirect /acme-url/ to >> acme.primary-domain/acme-url/ >> run acme client on machine that a record for acme.primary-domain points >> at once all san certs retrieved copy them to the relevant member servers >> >> or what i do, i run a 3rd party bash letsencrypt.sh client and after auth >> key is retrieved it rsyncs the key to all other servers in the >> cdn/cluster then proceeds (thus which server the letsencript server >> connects to it irrelevant) >> >> >> >> At 14:31 26/07/2016 Tuesday, Jostein Kjønigsen wrote: >> >> Dear Ladies and gentlemen of the IETF. >> >> I was commenting on a Github issue for the ACME-spec with regard >> to issuing certificates for subdomains based on proven higher >> level domain ownership. As a response I was asked to forward my >> request here. And so I will. >> >> The scenario of wanting to issue certificates for specific hosts >> while at the same time having a secondary subject (a top level >> DNS round robin for redundancy) is a very normal use-case. One >> example would be IRC-servers. >> >> My request for the ACME would be: If I can prove I own the top >> level domain, I should also be allowed to issue certs for any >> subdomain without need for verification of those. >> >> A concrete example of this would be allowing users to connect to >> "toplevel.net" (a DNS round-robin), This can resolve to a number >> of hosts. Let's say this resolves to an IP which is also >> equivalent to "host-a.toplevel.net". For a user to be able to >> either use the DNS round-robin or a specific host, that host need >> a certificate which can cover both these DNS names. Same applies >> to "host-b.toplevel.net", "hots-c.toplevel.net" etc. >> >> Certificates for a redundant setup like this cannot currently be >> setup using letsencrypt and ACME, because both domains cannot be >> verified on the one machine running the ACME client. >> >> Without support for this, I'm forced to use StartSSL for my cert >> needs (as they will issue certificates for any subdomains of a >> domain I can prove ownership of). >> (For those curious, the full github issue and related discussion >> can be found >> here:<https://github.com/letsencrypt/acme-spec/issues/104> >> https://github.com/letsencrypt/acme-spec/issues/104) >> >> Thank you for your attention. >> >> -- >> Sincere Greetings >> Jostein Kjønigsen >> <https://jostein.kjonigsen.net>https://jostein.kjonigsen.net >> >> _______________________________________________ >> Acme mailing list >> [email protected] <mailto:[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
