Device42’s certificate discovery functionality has been enhanced with the latest release (enhanced support in 10.5.0+), now supporting Server Name Indication (“SNI”), bolstering the SSL Certificate Management module’s capabilities.
Before the SNI enhancements, certificate discovery of a server that hosted multiple domains off of a single IP address (usually utilizing what’s known as virtual hosting functionality, aka a “vhost” or “vhosting”) resulted in the discovery of whatever certificate was configured to be served up as the “default” certificate, and outside of a certificate discovery situation (e.g. visiting the URL in a web browser) could result in a certificate mismatch, and your browser issuing an “invalid certificate” warning. SNI is an extension to the TLS protocol and supplies the hostname a client is requesting in the request itself at the start of the handshake, allowing the correct certificate to be served.
A demonstration of what this update brings to Device42 is pictured in the screenshots below, both pre- and post-SNI update.
[one_half]
[/one_half]
[one_half_last]
Within Device42, from the “Software” menu → “Certificates” screen, choosing “Add Certificate”, and then “Load from URL” presents the following “Load from Domain Name” dialog box:
[/one_half_last]
Previously, pre-SNI, the *.zendesk.com wildcard was served even though we requested the certificate for “support.device42.com”, as this is the default certificate configured (in the server’s SSL configuration file). Because Device42 did not previously supply Server Name Indication information, the server was left to make an assumption about which domain we were headed to, or in this particular use-case, which certificate to send for the SSL handshake.
Post-SSI update, the Device42 discovered certificate for an SSL virtual host is now the correct certificate, and matches the URL you requested. SNI information is now passed by Device42 at the start of the SSL handshake process, and the server, no longer forced to fall back to a default configuration, returns the correct certificate. In this case, though we asked Device42 to discover the same URL as before (pictured above, support.device42.com), post-update Device42 retrieves the matching *.device42.com wildcard certificate.
Though this situation can currently be considered an “edge” case, as the push toward SSL-everywhere continues and more and more servers default to SSL, servers hosting multiple SSL domains on the same IP will become more the norm, and Device42’s support for SNI ever more important.
We’d love to hear what you think about Device42, how you’ve been using it, any questions or comments on this feature, or anything else that might be on your mind! Please leave a comment, or if you aren’t currently a Device42 user, download a 30-day free trial @ www.device42.com/download today!
