Merge "BUG/MEDIUM: server: Also copy "check-sni" for server templates."

Upstream 2.0 branch commit: https://git.haproxy.org/?p=haproxy-2.0.git;a=commit;h=21944019cabcb46ceb95b7fd925528b9dace4e35

Looks like this was fixed before the release of the 2.0 series, so this is Fix Released for the development release.

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Is there an upstream bug link for this issue please?

If any upstream bug does not provide this information already, please could you provide exact steps to reproduce the problem and an explanation of how it impacts haproxy users? We need this information to be able to decide if it is appropriate to patch the Ubuntu stable releases, and to be able to QA any such fix prior to landing it.

Once done, please change the bug status back to New. Thanks!

Triage notes: probably server-next, but we need SRU information before this can be actionable so it doesn't qualify yet.

Set up HAProxy with the attached configuration. The server-template directive will generate 3 upstreams based on the DNS-answers for letsencrypt.status.io. This is basic HAProxy DNS-service-discovery.

If you now check back with the stats socket or the webinterface, you will notice that while the first upstream will be L7OK, all the following upstreams are going to be L6RSP, doe to the fact that the check-sni setting does not get replicated for any of the generated upstreams than the first.

The patch fixes this so the check-sni argument gets applied to all generated upstreams. With a patched version of HAProxy all the 3 upstreams will be L7OK.

Hello Malte,

I tried to reproduce the behavior you describe using the haproxy.cfg you provided, but without success. I have some questions that may help us getting in sync with what are observing.

1. Your haproxy.cfg doesn't work in Bionic and Eoan because haproxy complains that the following two lines:

    nameserver dns1 8.8.8.8
    nameserver dns2 8.8.4.4

do not specify an UDP port. Changing them to:

    nameserver dns1 8.8.8.8:53
    nameserver dns2 8.8.4.4:53

make it work, but I don't see how it could have worked for you. Can you confirm you tested the conf file with the haproxy package shipped with Ubuntu?

2. Even with the fix above, with Bionic I still get L6RSP errors in all the three upstreams, while you wrote that the first one should work and be listed as L7OK. The error is: "SSL handshake failure (Bad file descriptor)" for all of them. Can you confirm it the first one should work with your conf file and Bionic's haproxy?

If I change the server-template line to:

  server-template letsencrypt.status.io 3 letsencrypt.status.io:80 check resolvers res_statusio

I get L7OK from all the 3 upstreams. If I do:

  curl --cacert /etc/ssl/certs/ca-certificates.crt https://letsencrypt.status.io:444

I get the expected response, so my networking should be working fine.

3. In your haproxy.conf you set:

  option httpchk GET / HTTP/1.1\r\nHost:\ letsencrypt.status.io
  http-request set-header Host letsencrypt.status.io

It seems you are setting the Host header twice here. I doubt it's related with the check-sni issue, but worth checking and maybe dropping the first one

4. I tried the same configuration on Eoan, where the check-sni patch should be included, however I get SOCKERR errors for all the three upstreams. In the journal I see several errors like:

   OpenSSL error[0x14094410] ssl3_read_bytes: sslv3 alert handshake failure

which I didn't see on Bionic. Is it actually working for you on Eoan?

Please remember to set the report status back to New after providing additional information. Thanks!

FTR: I couldn't find an upstream bug for this.