On Fri, Oct 14, 2016 at 9:53 AM Alan Doherty <i...@alandoherty.net> wrote:

> 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
>
Really? That's great news.

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

Picture this, I have a host running 100 docker containers, each exposing a
single web application through an ephemeral port. Inside each of these
docker environments is the ACME client running with Nginx which is
reverse-proxy to a web application of any type. Haproxy is installed on the
host as is using TLS-SNI based routing to route TCP requests to the proper
docker container.

>
>
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
>
won't I need a certificate then? I'm calling the client before nginx has
started.

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