Add support for SNI: Fixes #1049

[ewan-chalmers]

Set opts.servername in lib/connect/tls.js

This enables connection to be established when SNI is required.

Fix for #1049

[YoDaMa]

Background on this would be appreciated. Do you have an example of how this succeeds when the property is added? I don't know SNI so I don't know if servername is the correct header, and I'd rather not go off just trusting what you're doing works.

[YoDaMa]

We should also add a test for it, so we know if this works now and if it breaks in the future

[ewan-chalmers]

SNI is Server Name Indication: https://en.wikipedia.org/wiki/Server_Name_Indication

By including servername in the connection options, the desired server name is indicated as part of the TLS handshake.

This enables the client to successfully make a TLS connection to a 'virtual domain' of a multi-domain server.

This is typical, for example, in a kubernetes environment where the ingress host (e.g. ingress.foo.com is in front of one or more virtual domains, e.g. app.bar.com). DNS for app.bar.com resolves ingress.foo.com, but by including the desired virtual host using SNI, the TLS connection is established to the virtual host.

I don't know how to add a test for this.

[ewan-chalmers]

See https://nodejs.org/api/tls.html#tls_tls_connect_options_callback

This is the document for the tls.connect(opts) done at

MQTT.js/lib/connect/tls.js

Line 14 in 3c63df8

connection = tls.connect(opts)

servername: Server name for the SNI (Server Name Indication) TLS extension. It is the name of the host being connected to, and must be a host name, and not an IP address. It can be used by a multi-homed server to choose the correct certificate to present to the client, see the SNICallback option to tls.createServer().

[YoDaMa]

Thanks, let me see if I can cook up a test for this.

[YoDaMa]

@ewan-chalmers I'm going to close this PR and I have a carryover PR that implements the testing for this.

[ewan-chalmers]

Super. Thank you @YoDaMa