Re: [Acme] Support for domains with redundant but not immediately synchronized servers

2015-12-04 Thread Peter Eckersley 
There's a fairly good solution available with the current protocol,
which is to serve a (long lived) redirect from
/.well-known/acme-challenge/ on all of the servers to a different URL
that is always answered by the machine you run an ACME client on.

Are there any cases where that is sufficiently unworkable to warrant a
protocol change?

On Mon, Nov 30, 2015 at 06:17:21PM +0100, Jonas Wielicki wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi list,
> 
> I have asked this in the IRC and was pointed to this mailing list. I
> tried to get a certificate for klausurschokola.de via Let’s Encrypt
> during the currently running limited beta (we have the domain
> whitelisted). The name has the following address records:
> 
> 1800  IN  A   176.9.101.187
> 1800  IN  A   217.115.12.71
> 
> (in addition, there is one  record for each of the machines
> addressed by the A records)
> 
> As you can see, two different machines are addressed. Those are
> physically separated machines with different main administrators.
> Both are pulling their web content from the same source, but it is not
> supposed to be dynamic, so there is no "fast" (order of seconds) way
> to mirror the content.
> 
> Our wish would be to be able to use different private keys and
> certificates for both hosts, and renew these independently from the
> other host. We thought that this would be possible using Let’s Encrypt.
> 
> The problem is that currently, the Let’s Encrypt server sometimes
> chooses the wrong of the two IPs to ask for the file in
> /.well-known/acme-challenge. Ideally, it would use the IP of the
> requester (of course only after it has verified that the IP is in the
> DNS) or allow the requester to specify a preferred IP.
> 
> For example, on 176.9.101.187:
> 
> # letsencrypt certonly -c ~/schoko.ini -d klausurschokola.de -d
> www.klausurschokola.de
> 
> [… curses …]
> 
> Failed authorization procedure. klausurschokola.de (http-01):
> unauthorized :: The client lacks sufficient authorization :: Invalid
> response from
> http://klausurschokola.de/.well-known/acme-challenge/c5HJrtp8t8JhfNgTXVC
> 8N7OsCrguAWGw-JTIJxCFeIQ
> [217.115.12.71]: 404
> 
> 
> Is such a thing planned? Are there security reasons against doing
> this? Are there security reasons against doing this on a DNSSEC signed
> domain (which klausurschokola.de is)?
> 
> best regards,
> Jonas
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIcBAEBCgAGBQJWXIShAAoJEMBiAyWXYliKJ1wP/iGVeGRxnAkrAstfjeGLvLeC
> TXnF76X/8xC3s4dd/UR0DE2n9Pdn0FYCK+6jRTn+Xpa0MvrA2ME20AZMh070Ghy0
> JRbdTWqjQTHzvjXYQHjSkW24pyZNgdfnmwd0HiAhn1mANv3dhVTnHR4hibZww+Su
> ty3XzsyZYjrfQ3K5/bTb/jz+QZUoZ/fJJuNlyMsVInF3rzagj34WWR4sYbAIwKEF
> CTvBFxINY04pUeemYlywPYrUOmcJTOK/wVi1ya2BgLgTqNJP5FJOX5jCHHr8m5ej
> A7G/nGWFSybOG1GkjMOdST3uMeL7HlpqhUnuNzsiC3ZAfmgVwceLsG3bTCAxcrgB
> 7XiSs3MrURuEk17w2QB0Oyt487DrmftzFo3vzvCrrl42au9JV69Y14/0W3z5piYM
> DIGpd/KNSL2m6xvzoJHoi+o5lTl9GiP6KQKlJiIUtn2cz8Ro6CiwXkhD0FmG8sP7
> 4wqg+vnpcTdhrzsWuAPrpGej+GT1LlWOLERnyPOfVhQ8EUPanwgUbGo1uTfHB2mj
> T2CdCCZhcmJFurvz+7FVI1WaVgGR/rdZbu4ueC+0YNZEOICXE0pIJEw8rKWJbqe3
> lKchgpR6jR3TKHHwNFDIZj049TBiEGxMXsdEaGlLOHdnr4ZlIDgfycumhYVTNJUi
> IDHRifjFUchCynluOhZi
> =3akD
> -END PGP SIGNATURE-
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

-- 
Peter Eckersleyp...@eff.org
Chief Computer Scientist  Tel  +1 415 436 9333 x131
Electronic Frontier FoundationFax  +1 415 436 9993

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

Re: [Acme] Support for domains with redundant but not immediately synchronized servers

2015-12-04 Thread Martin Thomson 
This seems to be a common problem, so I opened a PR that someone on
that project can merge.

On 4 December 2015 at 08:08, Salz, Rich  wrote:
>> Should I open an issue on the protocol draft repository? (Which I assume is 
>> at [1])
>>   [1]: https://github.com/letsencrypt/acme-spec
>
>
> No!  Please use the IETF WG repo, at 
> https://github.com/ietf-wg-acme/acme/issues
>
> ___
> 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

Re: [Acme] Support for domains with redundant but not immediately synchronized servers

2015-12-04 Thread Ted Hardie 
On Fri, Dec 4, 2015 at 12:46 AM, Peter Eckersley  wrote:

> There's a fairly good solution available with the current protocol,
> which is to serve a (long lived) redirect from
> /.well-known/acme-challenge/ on all of the servers to a different URL
> that is always answered by the machine you run an ACME client on.
>
> Are there any cases where that is sufficiently unworkable to warrant a
> protocol change?
>
>
​So, the initial use case Jonas laid out was for a service where they
wanted two different certs associated with the domain, which could be
maintained independently.  The draft currently says:

The path at which the resource is provisioned is comprised of the fixed
> prefix ".well-known/acme-challenge/", followed by the "token" value in the
> challenge. The value of the resource MUST be the ASCII representation of
> the key authorization.
>
> .well-known/acme-challenge/evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA
>
>
> The client's response to this challenge indicates its agreement to this
> challenge by sending the server the key authorization covering the
> challenge's token and the client's account key:
>
​If I understand your suggestion, to get what he wants, whoever is running
the machine on which the ACME client is run would have to generate two URIs
of the form

http://{domain}/.well-known/acme-challenge/{token}

do the signing with the account for the bodies created for each, and so
on.   That seems a little different from the work flow he had in mind, but
it is probably doable if we have the CAs recognize that having more than
one token outstanding may match this workflow rather than a replacement
workflow.

regards,

Ted



> On Mon, Nov 30, 2015 at 06:17:21PM +0100, Jonas Wielicki wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Hi list,
> >
> > I have asked this in the IRC and was pointed to this mailing list. I
> > tried to get a certificate for klausurschokola.de via Let’s Encrypt
> > during the currently running limited beta (we have the domain
> > whitelisted). The name has the following address records:
> >
> > 1800  IN  A   176.9.101.187
> > 1800  IN  A   217.115.12.71
> >
> > (in addition, there is one  record for each of the machines
> > addressed by the A records)
> >
> > As you can see, two different machines are addressed. Those are
> > physically separated machines with different main administrators.
> > Both are pulling their web content from the same source, but it is not
> > supposed to be dynamic, so there is no "fast" (order of seconds) way
> > to mirror the content.
> >
> > Our wish would be to be able to use different private keys and
> > certificates for both hosts, and renew these independently from the
> > other host. We thought that this would be possible using Let’s Encrypt.
> >
> > The problem is that currently, the Let’s Encrypt server sometimes
> > chooses the wrong of the two IPs to ask for the file in
> > /.well-known/acme-challenge. Ideally, it would use the IP of the
> > requester (of course only after it has verified that the IP is in the
> > DNS) or allow the requester to specify a preferred IP.
> >
> > For example, on 176.9.101.187:
> >
> > # letsencrypt certonly -c ~/schoko.ini -d klausurschokola.de -d
> > www.klausurschokola.de
> >
> > [… curses …]
> >
> > Failed authorization procedure. klausurschokola.de (http-01):
> > unauthorized :: The client lacks sufficient authorization :: Invalid
> > response from
> > http://klausurschokola.de/.well-known/acme-challenge/c5HJrtp8t8JhfNgTXVC
> > 8N7OsCrguAWGw-JTIJxCFeIQ
> > [217.115.12.71]: 404
> >
> >
> > Is such a thing planned? Are there security reasons against doing
> > this? Are there security reasons against doing this on a DNSSEC signed
> > domain (which klausurschokola.de is)?
> >
> > best regards,
> > Jonas
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> >
> > iQIcBAEBCgAGBQJWXIShAAoJEMBiAyWXYliKJ1wP/iGVeGRxnAkrAstfjeGLvLeC
> > TXnF76X/8xC3s4dd/UR0DE2n9Pdn0FYCK+6jRTn+Xpa0MvrA2ME20AZMh070Ghy0
> > JRbdTWqjQTHzvjXYQHjSkW24pyZNgdfnmwd0HiAhn1mANv3dhVTnHR4hibZww+Su
> > ty3XzsyZYjrfQ3K5/bTb/jz+QZUoZ/fJJuNlyMsVInF3rzagj34WWR4sYbAIwKEF
> > CTvBFxINY04pUeemYlywPYrUOmcJTOK/wVi1ya2BgLgTqNJP5FJOX5jCHHr8m5ej
> > A7G/nGWFSybOG1GkjMOdST3uMeL7HlpqhUnuNzsiC3ZAfmgVwceLsG3bTCAxcrgB
> > 7XiSs3MrURuEk17w2QB0Oyt487DrmftzFo3vzvCrrl42au9JV69Y14/0W3z5piYM
> > DIGpd/KNSL2m6xvzoJHoi+o5lTl9GiP6KQKlJiIUtn2cz8Ro6CiwXkhD0FmG8sP7
> > 4wqg+vnpcTdhrzsWuAPrpGej+GT1LlWOLERnyPOfVhQ8EUPanwgUbGo1uTfHB2mj
> > T2CdCCZhcmJFurvz+7FVI1WaVgGR/rdZbu4ueC+0YNZEOICXE0pIJEw8rKWJbqe3
> > lKchgpR6jR3TKHHwNFDIZj049TBiEGxMXsdEaGlLOHdnr4ZlIDgfycumhYVTNJUi
> > IDHRifjFUchCynluOhZi
> > =3akD
> > -END PGP SIGNATURE-
> >
> > ___
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
>
> --
> Peter Eckersleyp...@eff.org
> Chief Computer Scientist  Tel  +1 415 436 9333 x131
>