At 16:31 14/10/2016  Friday, Ben Irving wrote:

>On Thu, Oct 13, 2016 at 1:10 PM Alan Doherty 
><<mailto:i...@alandoherty.net>i...@alandoherty.net> wrote:
>At 17:39 13/10/2016Â  Thursday, Ben Irving wrote:
>>Hello,
>>
>>I have ran into a very similar use case. In my case I'm using Haproxy to 
>>route tcp requests based on the server name indication to upstream web 
>>servers where the TLS request is terminated. The ACME client is also running 
>>on these upstream web servers. I'm forced to use HTTP-01 challenges and am 
>>forced to open up port 80 as well on these upstream servers, which I don't 
>>want to do. I don't expect the protocol to solve my particular use case, but 
>>I'm also curious as to why acme.invalid was used as the suffix for all 
>>TLS-SNI based challenges?
>
>you shouldnt have to open port 80 to upstreams
>(assuming on the haproxy you do the normal http redirecting on port 80Â  aka 
>requests for <http://whatever>http://whatever get a 301 redirect to 
><https://same-domain/same-path>https://same-domain/same-path
>
>Maybe I'm misunderstanding, but I don't think there is an ACME client that 
>runs on port 443 for challenge type http-01. The major hurdle here is that I'm 
>running the ACME client upstream. However, since I'm not able to route the 
>TLS-SNI challenges to the correct upstream client, I'm forced to use HTTP-01 
>and open up port 80. 

your misunderstanding i said http-01 does not require opening port 80 to 
upstreams

http-01 will follow redirects 

thus if your proxy is directing www.domain1.com:443 at the upstream correctly

and 301 redirecting http://www.domain1.com:80 to https://www.domain1.com:443
which would be normal in most setups

http-01 will work fine without any use of port 80 on upstream server

(but on further thinking since)

(though if doing proxy why on earth would the upstream need anything other than 
a self signed cert (as its cert is never seen by public)

and just have the proxy run the acme client and answer rather than forward 
/.well-known/acme-challenge/
and update its own publicly visible cert only

btw in http-01 the acme client can specify to the server whether to use 
http://www.domain1.com/.well-known/acme-challenge/
or https://www.domain1.com/.well-known/acme-challenge/
directly

"The client’s response to this challenge indicates whether it would prefer for 
the validation request to be sent over TLS:

type (required, string):  
The string “simpleHttp” 
tls (optional, boolean, default true):  
If this attribute is present and set to “false”, the server will perform its 
validation check over unencrypted HTTP (on port 80) rather than over HTTPS. 
Otherwise the check will be done over HTTPS, on port 443." 
https://letsencrypt.github.io/acme-spec/#rfc.section.7.1

>Â 
>
>
>
>
>as the http-01 challenge will happily follow redirects and thus find/connect 
>to 
><https://whatever-domain/acme-specific-url>https://whatever-domain/acme-specific-url
>
>
>>- BenÂ
>>
>>
>>On Thu, Oct 13, 2016 at 8:00 AM Daniel McCarney 
>><<mailto:c...@letsencrypt.org><mailto:c...@letsencrypt.org>c...@letsencrypt.org>
>> wrote:
>>Hi Tim,
>>
>>Thanks for sharing your thoughts. This was the first time I've heard about 
>>this
>>sort of SNI multiplexing middleware in the context of IPv6 hosting.
>>
>>I'm newer to the list/draft process but I suspect your idea of using
>>"<<http://x.y.token.acme.client2-example.com>http://x.y.token.acme.client2-example.com><http://x.y.token.acme.client2-example.com>x.y.token.acme.client2-example.com"
>> to support the SNI multiplexing decision
>>will run counter to the intent behind using the ".acme.invalid" suffix as
>>described in the current draft. Perhaps someone with more historical context 
>>can
>>help clarify why that particular suffix strategy was selected.
>>
>>It would help me understand your feedback better if you could speak to why it
>>doesn't make more sense for users of this sort of middleware to favour the
>>HTTP-01 or DNS-01 challenge type. My own opinion leans towards thinking that
>>using a more appropriate challenge type is preferred to trying to address TLS
>>middleware in the context of the TLS-SNI-02 challenge design. This class of
>>middleware can introduce all sorts of complication that might end up
>>significantly complicating the challenge design.
>>
>>- Daniel/cpu
>>
>>
>>On Wed, Oct 12, 2016 at 6:45 AM, Tim Small 
>><<mailto:t...@seoss.co.uk>t...@seoss.co.uk> wrote:
>>Hello,
>>
>>Having read draft-ietf-acme-acme-02, and made a number of early
>>deployments using the tls-sni-01 mechanism, I thought I'd highlight what
>>I perceive to be a possible shortcoming with the tls-sni-02 draft.
>>
>>It's becoming more wide-spread (as a result of IPv4 exhaustion) to
>>deploy TLS SNI "switches" to provide IPv4 connectivity to autonomously
>>managed web servers.
>>
>>The typical deployment pattern is that a web server is assigned a
>>publicly accessible IPv6 address only - this can be used for direct
>>management and direct IPv6 https requests etc.  The TLS request are
>>terminated on the web server itself.
>>
>>The customer is also informed of an IPv4 addresses to be used for web
>>access by IPv4-only clients, and asked to provide a list of FQDNs which
>>they will serve.  IPv4 https requests are answered by proxy software,
>>which direct the IPv4 https request to the correct web server's IPv6
>>address (or an RFC-1918 IPv4 address etc.) based on SNI.
>>
>>e.g. this haproxy example configuration fragment:
>>
>>use-server customer1-staging if { req.ssl_sni -m beg
>><<http://staging.customer1-example.com>http://staging.customer1-example.com><http://staging.customer1-example.com>staging.customer1-example.com
>> }
>>use-server customer2-live if { req.ssl_sni -m beg
>><<http://staging.customer2-example.com>http://staging.customer2-example.com><http://staging.customer2-example.com>staging.customer2-example.com
>> }
>>
>>
>>I believe this will become increasingly common-place during the
>>transition to IPv6, and the current form of tls-sni-02 makes it hard to
>>use in this sort of environment.
>>
>>The problem comes when using tls-sni-02 ACME challenges:
>>
>>"The client MUST ensure that the certificate is served to TLS
>>connections specifying a Server Name Indication (SNI) value of SAN A."
>>
>>i.e. the SNI string which the proxy sees during the challenge is always
>>"SAN A" (x.y.token.acme.invalid), for any server for which it acts as
>>the "https switch" for.
>>
>>... so the proxy has no way of knowing which server the challenge
>>request should be directed to.  Some mechanism by which the proxy can
>>direct the request would be useful.
>>
>>One which may provide an easy route for the service providers offering
>>this sort of setup (many would require no changes to their existing
>>configuration at all) would be to append the FQDN in the TLS SNI value
>>e.g. 
>><<http://x.y.token.acme.client2-example.com>http://x.y.token.acme.client2-example.com><http://x.y.token.acme.client2-example.com>x.y.token.acme.client2-example.com
>>
>>The client in question may have limited or no influence on the
>>configuration of the SNI proxy, so the more straight-forward the proxy
>>configuration, the-better.
>>
>>For another example of a similar use-case with the same issue:
>>
>><<https://scriptthe.net/2015/02/08/pass-through-ssl-with-haproxy/>https://scriptthe.net/2015/02/08/pass-through-ssl-with-haproxy/>https://scriptthe.net/2015/02/08/pass-through-ssl-with-haproxy/
>>
>>HTH,
>>
>>Tim.
>>
>>_______________________________________________
>>Acme mailing list
>><mailto:Acme@ietf.org><mailto:Acme@ietf.org>Acme@ietf.org
>>https://www.ietf.org/mailman/listinfo/acme
>>
>>
>>_______________________________________________
>>Acme mailing list
>><mailto:Acme@ietf.org><mailto:Acme@ietf.org>Acme@ietf.org
>>https://www.ietf.org/mailman/listinfo/acme
>>
>>_______________________________________________
>>Acme mailing list
>><mailto:Acme@ietf.org>Acme@ietf.org
>>https://www.ietf.org/mailman/listinfo/acme

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

Reply via email to