© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
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.
I get L7OK from all the 3 upstreams. If I do:
curl --cacert /etc/ssl/
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.
http-request set-header Host letsencrypt.
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!