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