Proxy error when connecting to API backends that reject non-SNI requests

[GUI]

If an API backend requires SNI for establishing an SSL connection, then api.data.gov currently returns a 502 Bad Gateway error when trying to access the API. This doesn't appear to affect most servers, since nginx and Apache appear to always return at least some default certificate, even when SNI isn't present. However, today we ran into this issue since a backend server doesn't complete the SSL handshake when SNI isn't present:

$ openssl s_client -connect discovery.gsa.gov:443
CONNECTED(00000003)
140735288418384:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:

---
no peer certificate available

---

You can also see that the connection is closed when making a request directly to the IP:

$ curl "https://$(dig +short discovery.gsa.gov | head -n 1)"
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

At first I thought this might be related to how we resolve the DNS for API backends, but luckily the issue is more straightforward. nginx simply does not enable SNI when establishing connections to backend servers by default. Luckily, there's a couple of configuration options we can use to easily control this (proxy_ssl_server_name and proxy_ssl_name).

[GUI]

Fixed by NREL/api-umbrella@139ea9e We've added this specific type of SSL & SNI setup to our test suite.