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

Ted Hardie <ted.ietf@gmail.com> Fri, 04 December 2015 19:35 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6762E1B32C6 for <acme@ietfa.amsl.com>; Fri, 4 Dec 2015 11:35:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM4GyXoquKcg for <acme@ietfa.amsl.com>; Fri, 4 Dec 2015 11:35:05 -0800 (PST)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA2C1A8AD3 for <acme@ietf.org>; Fri, 4 Dec 2015 11:35:05 -0800 (PST)
Received: by qgec40 with SMTP id c40so96555370qge.2 for <acme@ietf.org>; Fri, 04 Dec 2015 11:35:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rfE64Ge1LrBy3sKzkgZu0lvQX3Mz7GEDDzR51BI8tn4=; b=ioLPhA81CDkBfoajOWI2yg5ubzAOtaCWW+FBBMtBmCcAKN81/WWp9hXmNLQ3STikb0 +rJH7B/19HPxJUQgjlEjZ3h9NA14X2fVwBwDuzXJILbUCxAwdNsvhkJUnc7Ncmdgjxyq vwd5zQtbQIXrXXeSv2pigcZ6FYBYiIIzMT7KoGVm9zlZocXi3KMWjt74UmJMA0XyEjqs 6QqIfKSpJtlkfAvTTE2Yhkpm1lVuocntv9KPTBQfXuKlf6Yw3CXJ7DRh4drHlMcEuL+d O7N4JQS9F5cA/kGU3S/LfaUK8S7cpbYbFturvPvgI3+KNPam11EKi3SukAOzWpyBSjux 0fNw==
MIME-Version: 1.0
X-Received: by 10.140.172.3 with SMTP id s3mr22226490qhs.6.1449257704445; Fri, 04 Dec 2015 11:35:04 -0800 (PST)
Received: by 10.55.14.211 with HTTP; Fri, 4 Dec 2015 11:35:04 -0800 (PST)
In-Reply-To: <20151204084601.GQ18430@eff.org>
References: <565C84A1.9040102@wielicki.name> <20151204084601.GQ18430@eff.org>
Date: Fri, 4 Dec 2015 11:35:04 -0800
Message-ID: <CA+9kkMByRa_JrK_whLQqcL5R1eEzAPV=a=wwDap1f5B5-2LznQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Peter Eckersley <pde@eff.org>
Content-Type: multipart/alternative; boundary=001a113a6e8ea9648c0526179aeb
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/oETHNIQuvXjYganmyY0JdO4b85Q>
Cc: Jonas Wielicki <jonas@wielicki.name>, "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] Support for domains with redundant but not immediately synchronized servers
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2015 19:35:08 -0000

On Fri, Dec 4, 2015 at 12:46 AM, Peter Eckersley <pde@eff.org> 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 AAAA 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 Eckersley                            pde@eff.org
> Chief Computer Scientist          Tel  +1 415 436 9333 x131
> Electronic Frontier Foundation    Fax  +1 415 436 9993
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>