Subject: Re: [Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified

From: Jostein Kjønigsen <[email-masked]>
Date: Thu, 18 Aug 2016 22:00:18 +0200

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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 18 Aug 2016 13:37:16 -0700

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:
> 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.
>
>> one method is dns auth (the client is run on the machine with access to
>> 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
>>     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.
>>
>>     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.
>>
>>     "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.
>>
>>     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>
>>     [email-masked] <mailto:[email-masked]>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 18 Aug 2016 20:48:42 +0000

> Sorry for bothering you all, with what in retrospect seems to have been a tech-support like issue.

Speaking as co-chair:  not at all.

If we all had to be experts before doing anything, we'd do nothing. :)

	/r$

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz