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

[Jacob Hoffman-Andrews]

(Picking up an old thread)
> >> 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.
>
> > This redirect-based workaround feels far from ideal. It assumes 1
> > server does all the ACME bits, which discourages per-hardware
> > keys.
Having one server that can be relied on to initiate and validate
challenges does not discourage per-hardware certificate keys. The
individual boxes are always free to generate their own CSRs and request
issuance independently, once the challenge is completed. This assumes
that you want to trust the individual boxes with copies of the account
key, but the same is true in the model you're proposing.
> It requires more coordination between servers (1 is
> > different; others need its IP; need some extra mechanism to
> > distribute key+cert once issued).
In any fleet so large that you can't reliably push out a token to all
frontends within a week, there's already this degree of coordination.

A little more detail on why I'm so opposed to this change: It introduces
complexity into the protocol to solve something that is relatively
deployment specific. It also conflicts with established validation
practice in other CAs. I don't think any current CA allows you to
specify which IP address to visit for HTTP-based domain validation.

Additionally, this duplicates the intent of other parts of the spec.
Specifically, the DNS challenge is intended to offer a way to validate
hostnames that are served by large fleets of load-balanced machines. I
realize there are reasons why the DNS challenges is not convenient for
every deployment scenario, but I think we need a stronger argument than
that to justify adding the extra complexity here.

___
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

[Jonas Wielicki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 09.02.2016 14:53, Michael Wyraz wrote:
> Hello Jonas,
>> 
>>> IMO a better way to support your scenario as well as those I 
>>> described above would be to check for an SRV-Record before
>>> checking A-Records. This would be 100% compatible with existing
>>> acme http-01 clients. In your case you would resolve the SRV
>>> record to the machine that has the acme client running on. The
>>> acme-server would check for the SRV-Record for an address to
>>> lookup the challenge's response at. If no SRV record is
>>> specified, it would continue with A and  records.
>> 
>> I am not entirely sure I get what you want to say here. SRV
>> records contain not only a host name, but also priorities,
>> weights and ports, so I wonder how that information would be used
>> in this context.
>> 
>> Do you suggest to have the client use an SRV record to specify
>> the address (including the port?) to which the server connects to
>> complete the challenge? In that case, what would the effect of
>> multiple SRV records for the target name be?
> correct, that's exactly what I meant. Example:
> 
> _acme.http-01._tcp.mydomain.com. 3600 INSRV10 1 80 
> acme.mydomain.com.
> 
> For multiple SRV weight/priority should be respected.
> 
> Four your case you would resolve www.mydomain.com to several ip
> addresses: www.mydomain.com. IN A IP-Address-Server1 
> www.mydomain.com. IN A IP-Address-Server2
> 
> While acme.mydomain.com resolves to a single ip address of the
> server where the acme client runs on: acme.mydomain.com. IN A
> IP-Address-Server1

So if I understand this correctly, the ACME client would have to set
(or modify) the SRV records in such a way that the host which is
currently running the client is the one with the highest priority?
This sounds like you could just use the DNS challenge, right?

And it is a different use-case from the one I posted initially. If the
clients were able to modify the DNS properly, I could indeed use the
dns-01 challenge in my scenario. This is not the case though.

best regards,
jwi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWukChAAoJEMBiAyWXYliK18cQAIy62Y2z6Lgd0hKKoUcFWhgh
qoNzwv6MzJTeEbaUXid7yiNkO13eKMtg2eX5cly32yIYjSjO2/nehVCyUVNMFbis
wbWsko57oy+/spIq+ZSjTiEhtU//MNrWz563TC/ug2dZxrAemup/q3QsfvSfBGEc
C+7RedeOxmFcFEpNtP67ILTnXe+/yM9z3q6K8Oif2h/qHz+eVwFPb8b1sIJC5/jT
tbuHQa4f8+fzh3q6UDiNAgEhGrWudBNVUdYwheMCkv7cf/+tmw1xCGbtY2BvQpfj
Qm/KNGb0lzh5WXlmlDvZRGh4GS1tKaQiIKerHkQaxqADwDGVvq8U+76t48AkqXTg
vBfdk8OKKTe8GIGTEaBeKKtc7w0wASA73pehQY8hN278uAOURV43FE8JQFmQRmJp
uWPbgdcPysq/YVxH79zbBH6w4AkVJ6yK5+gJy0XKCtw4W5tcyQmzA+FMIAmSRJa0
u83zJQO+ax8kCOviRlQSzBcxwpeoziUlCtaqhhsnNVliQYMYwba+NnNJ5HDI+Vch
f4oz/WhjgNIDXrOE5+VqecxDMbD/So8ekCn1nIBg2orN+Mz8+OTPdohyr7jhE9fW
04qucj9MQyH9b6vnjSt+yE+rHONlk9ZIHSYwpO0wkY42h21NKd08dQjLvsAiWXWZ
9oIQdJ5IRft4WyN5mdX6
=likc
-END PGP SIGNATURE-

___
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

[Jonas Wielicki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 21.01.2016 15:13, Salz, Rich wrote:
> 
>> I am not at all familiar with the processes in an IETF WG. What
>> is the way forward to get my proposal either into the protocol or
>> officially dismissed?
> 
> This is the way it works. :)  People post to the mailing list and
> there's discussion.  At some point, the chairs will see if there is
> consensus to do it.
> 
> So things are working as designed.  It's informal and a bit messy.
> 
> What might help focus discussion is if you made a pull request with
> your specific wording changes.

I gave it a shot: https://github.com/ietf-wg-acme/acme/pull/82

I will appreciate any feedback on that proposal.

best regards,
jwi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWub2+AAoJEMBiAyWXYliKdPQP/RyadYaVYunmFn9/TKelN3CO
ewdgsnbneS7KZ8TbhDEi788N9w2t1EIUBuqmEtSmUy3SYbsSg2ufVFYIGn9LSsL1
GT0XpNQ16f/+x8qgNGGSyV9ZddORo4dq20Lkf5TTvj8TTuJOzGrQWIq9tKk7/Bcf
ytXVqQpAhZd933RSRaBfFfxFv2Yq4dcq9WiccLurtmTLOXDbUXWK1Ij1WEVlMNeD
9R7V9DRDIFtItEG/6haMqzNECeFeP+GDE85JqzK03aRxjE994Rp24Cb6VnloWvxH
tFxm+olRMmB7YqyQ3+Xk0CXMHqtnqTjVQzuQaqVVrSLMXB0200okmcTzcNbLGWpk
DCzOel2iVNtRxb/R4Oaw6TAPLj7UQZQD2n2GaqJL4bJVHttsFrW8AW0PY3MWurGr
0xCyleVyGeJGcqVF6c4x25chcN35sT1uP+JoqJufomHlF5Mp7zY8r8hVPzLHic38
Ym+nPGebs35x7uKgtwyctx89v5d0NoN3HzOu0nsvDGizyLtmVxKWxUhOcsKL5rfX
N/6FdW7aCo0qqtqlSt+OYTiBAeknktG5vV6N90o5NEvv8WhOPPGSPSJ/cmwWyKlD
jymlTNu0XUIH6kq+enby1/f4cgwbC1srTAulz68SDz67B8V71EeI0O50XLV91Zq+
Qpm9rpOURUoG1KAnlDnK
=YzqS
-END PGP SIGNATURE-

___
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

[Jonas Wielicki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Michael,

(re-sent to include the list, sorry for the noise, Michael)

On 09.02.2016 11:52, Michael Wyraz wrote:
> thank you for the proposal. I think addressing such setups is a 
> good idea.

Thank you for your feedback!

> The solution you propose works only if dns round robin is used 
> (i.e. all the real server ips in A or ). But there are similar 
> setups where the redundant servers are behind some load balancer 
> where a completely different ip is used. Another widely used 
> scenario is geo-based dns. In this case, the Acme server would
> only see his "nearest" ip address.

I agree.

> IMO a better way to support your scenario as well as those I 
> described above would be to check for an SRV-Record before
> checking A-Records. This would be 100% compatible with existing
> acme http-01 clients. In your case you would resolve the SRV record
> to the machine that has the acme client running on. The acme-server
> would check for the SRV-Record for an address to lookup the
> challenge's response at. If no SRV record is specified, it would
> continue with A and  records.

I am not entirely sure I get what you want to say here. SRV records
contain not only a host name, but also priorities, weights and ports,
so I wonder how that information would be used in this context.

Do you suggest to have the client use an SRV record to specify the
address (including the port?) to which the server connects to complete
the challenge? In that case, what would the effect of multiple SRV
records for the target name be?

best regards,
jwi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWueS7AAoJEMBiAyWXYliK57UP/ROcqyPJmLjHPTmPc8bxJNX0
HHxGbGMiUDmiUwcubkflzhOpwIYD+Zl9MyL58bz78wdyw/sVWDxIVEWWM4C79jKB
0cUW3NzLYG2uWXHNy7BtqyFbYp2Z7MkixY+miXCxxvtleuo4m4G67ttCHrzumaT8
M9Fj94TqDfI+0M2IVtw/FUah4rdFgguJMEfgrcK41HFy+liLOYZzZXwG8XdOCjQm
v5H0K8dspHFzIrTnvwbALTbz3fW1z1dv+r3GPe3LcOpmSBC4G8Hz/rHDdKDQH/eE
8qIqYZxx54yT40nmee8cPWUjwxnnTCQaa3IwimDSs12V0LTfl98oQkAqIkoBdQST
1TNpMHE9v4KtR5lY8lLfiI74Gb+Cu/tf0V4rYeGi6uUgNVFSuVdumN71DhbN5MVP
XArfAtXEAsJ3Xm2sq/6ZWf01weufXIb/85tzrnkZC/tqVn6da22U30geuI+5hcxZ
v1UMZGQDx7NXYWKbIVqageYbBClbi8hRECr0Nl5nu4ejXaNkZ7dLkZZVnLzfXUWU
lKk8M2LdvcIo28kbXZxsio40nK2seB96GkW+aIGqVpyn1VjJaR5iktWUEBeIVUEi
AaeGgfZSxL9sig4ceCTawvvnSdIi2XZ4gJ2rY6ZxlO0AQ3ZATQyHZLx1aMF2OxGq
iSbK90o/cIiHHd0c3IKh
=IeGZ
-END PGP SIGNATURE-

___
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

[Michael Wyraz]

Hello Jonas,
>
> > IMO a better way to support your scenario as well as those I
> > described above would be to check for an SRV-Record before checking
> > A-Records. This would be 100% compatible with existing acme http-01
> > clients. In your case you would resolve the SRV record to the
> > machine that has the acme client running on. The acme-server would
> > check for the SRV-Record for an address to lookup the challenge's
> > response at. If no SRV record is specified, it would continue with
> > A and  records.
>
> I am not entirely sure I get what you want to say here. SRV records
> contain not only a host name, but also priorities, weights and ports,
> so I wonder how that information would be used in this context.
>
> Do you suggest to have the client use an SRV record to specify the
> address (including the port?) to which the server connects to complete
> the challenge? In that case, what would the effect of multiple SRV
> records for the target name be?
correct, that's exactly what I meant. Example:

_acme.http-01._tcp.mydomain.com. 3600 INSRV10 1 80
acme.mydomain.com.

For multiple SRV weight/priority should be respected.

Four your case you would resolve www.mydomain.com to several ip addresses:
www.mydomain.com. IN A IP-Address-Server1
www.mydomain.com. IN A IP-Address-Server2

While acme.mydomain.com resolves to a single ip address of the server
where the acme client runs on:
acme.mydomain.com. IN A IP-Address-Server1




signature.asc
Description: OpenPGP digital signature
___
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

[Michael Wyraz]

Hi Jonas,
> So if I understand this correctly, the ACME client would have to set
> (or modify) the SRV records in such a way that the host which is
> currently running the client is the one with the highest priority?
> This sounds like you could just use the DNS challenge, right?
>
> And it is a different use-case from the one I posted initially. If the
> clients were able to modify the DNS properly, I could indeed use the
> dns-01 challenge in my scenario. This is not the case though.
You're right, I missunderstood your use case and thought, the client
only runs on a certain of the servers. Using SRV records will not solve
this special use case.




signature.asc
Description: OpenPGP digital signature
___
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

[Jonas Wielicki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello list,

On 07.12.2015 01:32, Manger, James wrote:
>>> Ideally, it [Let's Encrypt] 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.
> 
> This is quite a sensible feature request from Jonas. It supports 
> multiple servers for a domain while encouraging keys that are tied 
> to a single piece of hardware, without adding extra coordination 
> requirements. It doesn't feel too onerous for CAs to implement.

Having the keys bound to a single piece of hardware (or administrative
sub-domain) is also what we had in mind. Thank you for bringing that
up in clearer wording.

>> 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.
> 
> This redirect-based workaround feels far from ideal. It assumes 1 
> server does all the ACME bits, which discourages per-hardware
> keys. It requires more coordination between servers (1 is
> different; others need its IP; need some extra mechanism to
> distribute key+cert once issued).

We totally agree. The additional coordination overhead feels
unnecessary and error prone.

I am not at all familiar with the processes in an IETF WG. What is the
way forward to get my proposal either into the protocol or officially
dismissed?

best regards,
Jonas
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWoMVYAAoJEMBiAyWXYliKmPwP/AhkeVsagYurFxAUdImIVDlB
Dq8axBHes+WuZsYypmx7j1+zot4ljgZloxx6w//XfJyNyKdwNV1jrsFLBEELe3J9
kbcAYNZKO/DvN32GzluwF3yGqiovLCEsJ/DfRoIpcIzNSfCwutzR4h0vU9eZPjaR
aAzUiyVF6rOz+eC1kIZuOvNRVXEOgSHWBiNiZMTsYSciiYls0jakGFmAN33O13Bi
KJomFcQ8GWZJ261anTbLxgcGZYHFYjba4kZOShXX9VQnDkLrHC15aF0/afDZLjt5
ntSktX1JM+Qq1yN+FgJPPrk2B6JxvpS74um9DA8cwgMft+NU3hxpdwGaind3CVPp
GqYcU0+Rm20mJOUYgJC3n/F6EnCeN75aQpZp82DLGoa5/oyCffgqJdcr4vcJfNk1
uI+8jmV13cgn0gzJUtWjHH09VUsaUfu6Da8QYhBKILYc+Lt2FgBNH/OVLiXyc/t9
eQKVdIMYZGxjsgE9oRGIG0qVXgloCB+N/5KSh/zUEt1WrqU2rJrtCF1wrk/zPvGa
s2bh3DFCvf2GnPwDB3OrQzt3/1NpzLPKdccgvbAxUp1DAnrxeh3R1GHBji3k3dbj
+8yPpaBaYstkB8rK9azCsvZ/D3jBIV5pv1LeMZ3oKCCmj2xDCk7kXonpKEAdruaR
F2U+3WxFJbFMzpDocCIA
=ftJz
-END PGP SIGNATURE-

___
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

[Manger, James]

>> Ideally, it [Let's Encrypt] 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.

This is quite a sensible feature request from Jonas. It supports multiple 
servers for a domain while encouraging keys that are tied to a single piece of 
hardware, without adding extra coordination requirements. It doesn't feel too 
onerous for CAs to implement.

> 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.

This redirect-based workaround feels far from ideal. It assumes 1 server does 
all the ACME bits, which discourages per-hardware keys. It requires more 
coordination between servers (1 is different; others need its IP; need some 
extra mechanism to distribute key+cert once issued). Section 9.2 "Integrity of 
Authorizations" [draft-ietf-acme-acme-01] warns that an ACME CA following 
redirects can be risky as a web site might have a catch-all redirect rule. Even 
worse, the spec hints that CAs might not (or must not?) follow redirects at all 
due to the risk when it says: "suppose an ACME server follows HTTP redirects in 
Simple HTTP validation…".

App-level redirects might be necessary to cope with some load balancing 
schemes, but specifying that an ACME server must prefer the requester's IP or a 
specified IP from the A/ records DNS returns would still be useful.

--
James Manger


-Original Message-
From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Ryan Pendleton
Sent: Friday, 4 December 2015 8:53 PM

Personally, I think that's a more appropriate approach.

Even if a protocol change was made that allowed an ACME client to pin the 
challenge to a certain IP address, the requested IP may not always be returned 
by the authoritative DNS server. Any type of latency, geo or weighted routing 
algorithm could potentially get in the way.


-Original Message-
From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Peter Eckersley
Sent: Friday, 4 December 2015 7:46 PM
To: Jonas Wielicki 
Cc: acme@ietf.org
Subject: Re: [Acme] Support for domains with redundant but not immediately 
synchronized servers

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?


-Original Message-
From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Jacob Hoffman-Andrews
Sent: Friday, 4 December 2015 10:27 AM

I think there are a few possible approaches to domain validation for hostnames 
that resolve to multiple IP addresses:

1) It is sufficient to deploy a challenge response on any IP address.
2) The challenge response must be deployed on all IP addresses.
3) The server tries one deterministic IP address and succeeds or fails based on 
whether the challenge is deployed there.

Let's Encrypt currently does (3), but it's probably the worst of both worlds 
and we should fix it.

Arguably (2) is the most secure, since a single-machine compromise isn't 
sufficient to issue a certificate.

And (1) is the easiest and most user-friendly. I think it's also similar to 
existing practice in the wild.

Jonas, security-wise your proposal is equivalent to (1). Rather than adding a 
preferred IP address to the spec, why not specif that ACME servers SHOULD 
implement (1)? Alternately we could state in the spec that the choice of IP is 
a policy choice of the CA, and lay out the two most reasonable options (1 and 
2).

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 

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

[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

[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

[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
> 

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

[Hugo Landau]

> 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)?

Personally, I wouldn't think it unreasonable to allow an ACME client to
request that a specific IP be used for the purposes of a challenge. The
server would then verify that that IP is one of the candidate IPs,
rather than selecting one at random. I don't see that this causes any
loss of security, so it seems like a sensible inclusion.

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