# SSL handshake failure on Cloudfront backend server

**URL:** <https://discourse.haproxy.org/t/ssl-handshake-failure-on-cloudfront-backend-server/6027>\
**Category:** Help!\
**Created:** [December 15, 2020, 10:12am UTC](https://discourse.haproxy.org/t/ssl-handshake-failure-on-cloudfront-backend-server/6027 "2020-12-15T10:12:32Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![minaev](https://avatars.discourse-cdn.com/v4/letter/m/7ea924/32.png) [@minaev](https://discourse.haproxy.org/u/minaev)\
**Post date:** [December 15, 2020, 10:12am UTC](https://discourse.haproxy.org/t/ssl-handshake-failure-on-cloudfront-backend-server/6027/1 "2020-12-15T10:12:32Z")

</div>

Hello,  
I have a HAProxy instance that should serve as a proxy to [Here.com](http://Here.com) maps, adding the API key to all passing requests. However the following backend configuration fails with messages 'SSL handshake failure

> backend freehere\_maps\_redirect  
> http-send-name-header Host  
> http-request set-uri http://%[req.hdr(Host)]%[path]?apiKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxx&%[query]  
> server [1.base.maps.ls.hereapi.com](http://1.base.maps.ls.hereapi.com) [1.base.maps.ls.hereapi.com:443](http://1.base.maps.ls.hereapi.com:443) check ssl verify none check resolvers mydns  
> server [2.base.maps.ls.hereapi.com](http://2.base.maps.ls.hereapi.com) [2.base.maps.ls.hereapi.com:443](http://2.base.maps.ls.hereapi.com:443) check ssl verify none check resolvers mydns  
> server [3.base.maps.ls.hereapi.com](http://3.base.maps.ls.hereapi.com) [3.base.maps.ls.hereapi.com:443](http://3.base.maps.ls.hereapi.com:443) check ssl verify none check resolvers mydns  
> server [4.base.maps.ls.hereapi.com](http://4.base.maps.ls.hereapi.com) [4.base.maps.ls.hereapi.com:443](http://4.base.maps.ls.hereapi.com:443) check ssl verify none check resolvers mydns

I have tried adding options like `sni str(1.base.maps.ls.hereapi.com)`, but the error persists. Here is what ssldump shows:

> New TCP connection #1: localhost.localdomain(34914) ↔ [server-205-251-219-9.arn1.r.cloudfront.net](http://server-205-251-219-9.arn1.r.cloudfront.net)(443)  
> 1 1 0.1257 (0.1257) C\>S Handshake  
> ClientHello  
> Version 3.3  
> cipher suites  
> TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384  
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384  
> TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_DH\_DSS\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_DHE\_DSS\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_DH\_RSA\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_DHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_DHE\_RSA\_WITH\_AES\_256\_CBC\_SHA256  
> TLS\_DHE\_DSS\_WITH\_AES\_256\_CBC\_SHA256  
> TLS\_DH\_RSA\_WITH\_AES\_256\_CBC\_SHA256  
> TLS\_DH\_DSS\_WITH\_AES\_256\_CBC\_SHA256  
> TLS\_DHE\_RSA\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_DHE\_DSS\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_DH\_RSA\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_DH\_DSS\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_DHE\_RSA\_WITH\_CAMELLIA\_256\_CBC\_SHA  
> TLS\_DHE\_DSS\_WITH\_CAMELLIA\_256\_CBC\_SHA  
> TLS\_DH\_RSA\_WITH\_CAMELLIA\_256\_CBC\_SHA  
> TLS\_DH\_DSS\_WITH\_CAMELLIA\_256\_CBC\_SHA  
> TLS\_ECDH\_RSA\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_ECDH\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_ECDH\_RSA\_WITH\_AES\_256\_CBC\_SHA384  
> TLS\_ECDH\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384  
> TLS\_ECDH\_RSA\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_ECDH\_ECDSA\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA256  
> TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_RSA\_WITH\_CAMELLIA\_256\_CBC\_SHA  
> TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256  
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256  
> TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256  
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA256  
> TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_DH\_DSS\_WITH\_AES\_128\_GCM\_SHA256  
> TLS\_DHE\_DSS\_WITH\_AES\_128\_GCM\_SHA256  
> TLS\_DH\_RSA\_WITH\_AES\_128\_GCM\_SHA256  
> TLS\_DHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256  
> TLS\_DHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256  
> TLS\_DHE\_DSS\_WITH\_AES\_128\_CBC\_SHA256  
> TLS\_DH\_RSA\_WITH\_AES\_128\_CBC\_SHA256  
> TLS\_DH\_DSS\_WITH\_AES\_128\_CBC\_SHA256  
> TLS\_DHE\_RSA\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_DHE\_DSS\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_DH\_RSA\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_DH\_DSS\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_DHE\_RSA\_WITH\_SEED\_CBC\_SHA  
> TLS\_DHE\_DSS\_WITH\_SEED\_CBC\_SHA  
> TLS\_DH\_RSA\_WITH\_SEED\_CBC\_SHA  
> TLS\_DH\_DSS\_WITH\_SEED\_CBC\_SHA  
> TLS\_DHE\_RSA\_WITH\_CAMELLIA\_128\_CBC\_SHA  
> TLS\_DHE\_DSS\_WITH\_CAMELLIA\_128\_CBC\_SHA  
> TLS\_DH\_RSA\_WITH\_CAMELLIA\_128\_CBC\_SHA  
> TLS\_DH\_DSS\_WITH\_CAMELLIA\_128\_CBC\_SHA  
> TLS\_ECDH\_RSA\_WITH\_AES\_128\_GCM\_SHA256  
> TLS\_ECDH\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256  
> TLS\_ECDH\_RSA\_WITH\_AES\_128\_CBC\_SHA256  
> TLS\_ECDH\_ECDSA\_WITH\_AES\_128\_CBC\_SHA256  
> TLS\_ECDH\_RSA\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_ECDH\_ECDSA\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_RSA\_WITH\_AES\_128\_GCM\_SHA256  
> TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256  
> TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_RSA\_WITH\_SEED\_CBC\_SHA  
> TLS\_RSA\_WITH\_CAMELLIA\_128\_CBC\_SHA  
> TLS\_ECDHE\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA  
> TLS\_ECDHE\_ECDSA\_WITH\_3DES\_EDE\_CBC\_SHA  
> TLS\_DHE\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA  
> TLS\_DHE\_DSS\_WITH\_3DES\_EDE\_CBC\_SHA  
> TLS\_DH\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA  
> TLS\_DH\_DSS\_WITH\_3DES\_EDE\_CBC\_SHA  
> TLS\_ECDH\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA  
> TLS\_ECDH\_ECDSA\_WITH\_3DES\_EDE\_CBC\_SHA  
> TLS\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA  
> TLS\_RSA\_WITH\_IDEA\_CBC\_SHA  
> TLS\_ECDHE\_RSA\_WITH\_RC4\_128\_SHA  
> TLS\_ECDHE\_ECDSA\_WITH\_RC4\_128\_SHA  
> TLS\_ECDH\_RSA\_WITH\_RC4\_128\_SHA  
> TLS\_ECDH\_ECDSA\_WITH\_RC4\_128\_SHA  
> TLS\_RSA\_WITH\_RC4\_128\_SHA  
> TLS\_RSA\_WITH\_RC4\_128\_MD5  
> TLS\_EMPTY\_RENEGOTIATION\_INFO\_SCSV  
> compression methods  
> NULL  
> 1 2 0.2422 (0.1164) S\>C Alert  
> level fatal  
> value handshake\_failure  
> 1 3 0.2422 (0.0000) S\>C Alert  
> level warning  
> value close\_notify  
> 1 0.2428 (0.0005) S\>C TCP FIN  
> 1 0.2599 (0.0171) C\>S TCP RST

However, Curl can establish TLS connection to this server:

> New TCP connection #1: localhost.localdomain(60630) ↔ [server-13-33-243-73.hel50.r.cloudfront.net](http://server-13-33-243-73.hel50.r.cloudfront.net)(443)  
> 1 1 0.2425 (0.2425) C\>S Handshake  
> ClientHello  
> Version 3.3  
> cipher suites  
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256  
> Unknown value 0xcca9  
> TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256  
> Unknown value 0xcca8  
> TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_DHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_DHE\_RSA\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_DHE\_DSS\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_DHE\_RSA\_WITH\_AES\_256\_CBC\_SHA256  
> TLS\_DHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256  
> Unknown value 0xccaa  
> TLS\_DHE\_RSA\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_DHE\_DSS\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_DHE\_RSA\_WITH\_AES\_128\_CBC\_SHA256  
> TLS\_DHE\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA  
> TLS\_DHE\_DSS\_WITH\_3DES\_EDE\_CBC\_SHA  
> TLS\_RSA\_WITH\_AES\_256\_GCM\_SHA384  
> TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA  
> TLS\_RSA\_WITH\_AES\_256\_CBC\_SHA256  
> TLS\_RSA\_WITH\_AES\_128\_GCM\_SHA256  
> TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA  
> TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256  
> TLS\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA  
> TLS\_RSA\_WITH\_RC4\_128\_SHA  
> TLS\_RSA\_WITH\_RC4\_128\_MD5  
> compression methods  
> NULL  
> 1 2 0.3793 (0.1367) S\>C Handshake  
> ServerHello  
> Version 3.3  
> session\_id[32]=  
> f8 f2 8b 5b 48 eb bb 7f d8 5c 70 e0 9c 86 30 0d  
> f7 3d 6c 52 2f 66 b7 33 84 09 1f bb 25 14 d9 f6  
> cipherSuite TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256  
> compressionMethod NULL  
> 1 3 0.3994 (0.0201) S\>C Handshake  
> Certificate  
> 1 4 0.3994 (0.0000) S\>C Handshake  
> ServerKeyExchange  
> 1 5 0.3994 (0.0000) S\>C Handshake  
> ServerHelloDone  
> and so on

I tried to specify `ciphers ECDHE-RSA-AES128-GCM-SHA256` in the server configuration, but the result is the same.

The following HAProxy versions were tested on CentOS7:

> HA-Proxy version 1.8.4-1deb90d 2018/02/08  
> Copyright 2000-2018 Willy Tarreau [willy@haproxy.org](mailto:willy@haproxy.org)
> 
> Build options :  
> TARGET = linux2628  
> CPU = generic  
> CC = gcc  
> CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-unused-label  
> OPTIONS = USE\_LINUX\_TPROXY=1 USE\_ZLIB=1 USE\_REGPARM=1 USE\_OPENSSL=1 USE\_LUA=1 USE\_SYSTEMD=1 USE\_PCRE=1
> 
> Default settings :  
> maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
> 
> Built with OpenSSL version : OpenSSL 1.0.2k-fips 26 Jan 2017  
> Running on OpenSSL version : OpenSSL 1.0.2k-fips 26 Jan 2017  
> OpenSSL library supports TLS extensions : yes  
> OpenSSL library supports SNI : yes  
> OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2

and

> HA-Proxy version 2.2.2 2020/07/31 - [https://haproxy.org/](https://haproxy.org/)  
> Status: long-term supported branch - will stop receiving fixes around Q2 2025.  
> Known bugs: [http://www.haproxy.org/bugs/bugs-2.2.2.html](http://www.haproxy.org/bugs/bugs-2.2.2.html)  
> Running on: Linux 3.10.0-862.11.6.el7.x86\_64 #1 SMP Tue Aug 14 21:49:04 UTC 2018 x86\_64  
> Build options :  
> TARGET = linux-glibc  
> CPU = generic  
> CC = gcc  
> CFLAGS = -O2 -g -Wall -Wextra -Wdeclaration-after-statement -fwrapv -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered -Wno-missing-f  
> ield-initializers -Wtype-limits  
> OPTIONS = USE\_PCRE2=1 USE\_LINUX\_TPROXY=1 USE\_CRYPT\_H=1 USE\_GETADDRINFO=1 USE\_OPENSSL=1 USE\_ZLIB=1 USE\_SYSTEMD=1
> 
> Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE -PCRE\_JIT +PCRE2 -PCRE2\_JIT +POLL -PRIVATE\_CACHE +THREAD -PTHREAD\_PSHARED +BACKTRACE -STATIC\_PCRE -STATIC\_PCRE2  
> +TPROXY +LINUX\_TPROXY +LINUX\_SPLICE +LIBCRYPT +CRYPT\_H +GETADDRINFO +OPENSSL -LUA +FUTEX +ACCEPT4 +ZLIB -SLZ +CPU\_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51D  
> EGREES -WURFL +SYSTEMD -OBSOLETE\_LINKER +PRCTL +THREAD\_DUMP -EVPORTS
> 
> Default settings :  
> bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
> 
> Built with multi-threading support (MAX\_THREADS=64, default=1).  
> Built with OpenSSL version : OpenSSL 1.0.2k-fips 26 Jan 2017  
> Running on OpenSSL version : OpenSSL 1.0.2k-fips 26 Jan 2017  
> OpenSSL library supports TLS extensions : yes  
> OpenSSL library supports SNI : yes  
> OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2

What else can be done here?

Thanks  
Dimitri

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [December 15, 2020, 5:39pm UTC](https://discourse.haproxy.org/t/ssl-handshake-failure-on-cloudfront-backend-server/6027/2 "2020-12-15T17:39:44Z")

</div>

First of all, don’t health check other peoples cloud servers, this is just gonna get your IP banned from using there services.

Health checks, if enabled, would also need a separate SNI configuration ([check-sni](https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.2-check-sni)), which makes this even more complicated.

However I’d recommend to just disable health-checks, because it doesn’t make sense for the “forwarding” proxy scenario.

Use [option redispatch](https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-option%20redispatch) and [retries](https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#retries) for fail-over from one server to another.

---

<div class="post-metadata">

**Author:** ![minaev](https://avatars.discourse-cdn.com/v4/letter/m/7ea924/32.png) [@minaev](https://discourse.haproxy.org/u/minaev)\
**Post date:** [December 15, 2020, 6:16pm UTC](https://discourse.haproxy.org/t/ssl-handshake-failure-on-cloudfront-backend-server/6027/3 "2020-12-15T18:16:36Z")

</div>

Thanks for the idea with check-sni.

The problem is that these backend servers often change IP addresses. For this reason I had to enable DNS resolution, which, according to the manual, “is triggered by health checks. This makes health checks mandatory to allow DNS resolution”.

What is interesting is that on another set of [Here.com](http://Here.com) servers a very similar configuration works well:

```auto
        http-send-name-header Host
        http-request set-uri http://%[req.hdr(Host)]%[path]?app_code=xxxxxxxxxxxxxxxxxxxxx&app_id=xxxxxxxxxxxxxxxxxxxx&%[query]
        server 1.base.maps.api.here.com 1.base.maps.api.here.com:443 ssl verify none check resolvers mydns resolve-prefer ipv4
        server 2.base.maps.api.here.com 2.base.maps.api.here.com:443 ssl verify none check resolvers mydns resolve-prefer ipv4
        server 3.base.maps.api.here.com 3.base.maps.api.here.com:443 ssl verify none check resolvers mydns resolve-prefer ipv4
        server 4.base.maps.api.here.com 4.base.maps.api.here.com:443 ssl verify none check resolvers mydns resolve-prefer ipv4

```

---

<div class="post-metadata">

**Author:** ![minaev](https://avatars.discourse-cdn.com/v4/letter/m/7ea924/32.png) [@minaev](https://discourse.haproxy.org/u/minaev)\
**Post date:** [December 16, 2020, 6:38am UTC](https://discourse.haproxy.org/t/ssl-handshake-failure-on-cloudfront-backend-server/6027/4 "2020-12-16T06:38:56Z")

</div>

Unfortunately, changing `sni` to `check-sni` didn’t help. It adds the following to handshake:

```auto
          server_name
              host_name: str(1.base.maps.ls.hereapi.com)

```

But the result is the same, `handshake_failure`.  
It seems to be a problem specific to Cloudfront, because the other set of servers I mentioned in the last message runs on Akamai.

---

<div class="post-metadata">

**Author:** ![minaev](https://avatars.discourse-cdn.com/v4/letter/m/7ea924/32.png) [@minaev](https://discourse.haproxy.org/u/minaev)\
**Post date:** [December 16, 2020, 9:10am UTC](https://discourse.haproxy.org/t/ssl-handshake-failure-on-cloudfront-backend-server/6027/5 "2020-12-16T09:10:25Z")

</div>

Here’s a working configuration:

```auto
  http-request set-uri http://%[req.hdr(Host)]%[path]?apiKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&%[query]
  server 1.base.maps.ls.hereapi.com 1.base.maps.ls.hereapi.com:443 ssl sni req.hdr(Host) verify none
  server 2.base.maps.ls.hereapi.com 2.base.maps.ls.hereapi.com:443 ssl sni req.hdr(Host) verify none
  server 3.base.maps.ls.hereapi.com 3.base.maps.ls.hereapi.com:443 ssl sni req.hdr(Host) verify none
  server 4.base.maps.ls.hereapi.com 4.base.maps.ls.hereapi.com:443 ssl sni req.hdr(Host) verify none

```

However, it breaks as soon as I add `resolvers` or `check`. Without `resolvers`, it breaks (in a different way, though) when the DNS round robin changes the IP addresses.

One more interesting thing I noted while playing with Curl is that the requests pass when the server is identified with a DNS name, but fail during SSL handshake when the name is replaced with IP, even though `Host` header is present:

```auto
1.base.maps.ls.hereapi.com. 3586 IN CNAME d2t4vhngii5504.cloudfront.net.
d2t4vhngii5504.cloudfront.net. 46 IN A 99.84.11.118
d2t4vhngii5504.cloudfront.net. 46 IN A 99.84.11.65
d2t4vhngii5504.cloudfront.net. 46 IN A 99.84.11.19
d2t4vhngii5504.cloudfront.net. 46 IN A 99.84.11.54

$ curl -H 'Host: 1.base.maps.ls.hereapi.com' 'https://1.base.maps.ls.hereapi.com/maptile/2.1/version?apiKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
MRS: 2.1.70.15
MOS: 2.2.37-152.f3a0a2d9
Map: 8.30.115.154

$ curl -H 'Host: 1.base.maps.ls.hereapi.com' 'https://d2t4vhngii5504.cloudfront.net/maptile/2.1/version?apiKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
MRS: 2.1.70.15
MOS: 2.2.37-152.f3a0a2d9
Map: 8.30.115.154

$ curl -H 'Host: 1.base.maps.ls.hereapi.com' 'https://99.84.11.118/maptile/2.1/version?apiKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

```

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [December 16, 2020, 2:40pm UTC](https://discourse.haproxy.org/t/ssl-handshake-failure-on-cloudfront-backend-server/6027/6 "2020-12-16T14:40:59Z")

</div>

> [@minaev](#):
>
> Unfortunately, changing `sni` to `check-sni` didn’t help.

I never said that, if you need health checking, you need BOTH. After all, there is no point in having a working health check, when your actually traffic doesn’t work.

```
server 1.base.maps.ls.hereapi.com 1.base.maps.ls.hereapi.com:443 ssl sni req.hdr(Host) check check-sni 1.base.maps.ls.hereapi.com verify none

```

> [@minaev](#):
>
> The problem is that these backend servers often change IP addresses. For this reason I had to enable DNS resolution, which, according to the manual, “is triggered by health checks. This makes health checks mandatory to allow DNS resolution”.

This _WAS_ true in haproxy 1.7. In haproxy 1.8 and later, you don’t need health checks to trigger DNS resolution.

---

<div class="post-metadata">

**Author:** ![minaev](https://avatars.discourse-cdn.com/v4/letter/m/7ea924/32.png) [@minaev](https://discourse.haproxy.org/u/minaev)\
**Post date:** [December 17, 2020, 7:56am UTC](https://discourse.haproxy.org/t/ssl-handshake-failure-on-cloudfront-backend-server/6027/7 "2020-12-17T07:56:42Z")

</div>

I tried using `sni` and `check-sni` together, too. Didn’t help, unfortunately. Handshake failure.  
Also, I tried to remove checks. The configuration works only as long as there are no `resolvers`. With `resolvers` it returns 502.

---

<div class="post-metadata">

**Author:** ![minaev](https://avatars.discourse-cdn.com/v4/letter/m/7ea924/32.png) [@minaev](https://discourse.haproxy.org/u/minaev)\
**Post date:** [December 18, 2020, 4:45pm UTC](https://discourse.haproxy.org/t/ssl-handshake-failure-on-cloudfront-backend-server/6027/8 "2020-12-18T16:45:14Z")

</div>

So, `check-sni` was the key. Alone, without `sni`. But I used it in a wrong way. `check-sni` should be followed by a simple DNS name, as in your example above, not str() or req.hdr() call. The working configuration is:

` server 1.base.maps.ls.hereapi.com 1.base.maps.ls.hereapi.com:443 ssl verify none resolvers mydns check-sni 1.base.maps.ls.hereapi.com check`

Thanks for your help, @lukastribus!