Over the past few releases we’ve achieved a number of improvements to our SSL infrastructure (see our blog last year regarding Apple ATS support) and the result of that effort is starting to manifest in our customer facing APIs and StrikeTracker portal. I’d like to highlight two of those resulting features for you today.

SNI Support

Server Name Indication, or SNI, is a method by which clients such as web browsers can securely designate the domain that they are attempting to access before completing the SSL handshake. That means that custom SSL certificates can be used on a multi-tenant system like a CDN without having to consume scarce dedicated IPv4 address space, a necessity for a truly scalable secure web.

We’ve always felt strongly that selling inclusion on a Subject Alternative Name (SAN) certificate for the sake of showing users a 🔒 icon is insecure and violates the spirit of SSL design conventions. For that reason, we’ve only offered security via our own wildcard certificate (*.ssl.hwcdn.net) and via dedicated IP with custom certs. Highwinds’ newly unveiled SNI support means that our customers can genuinely secure the traffic of their own domains in a cost effective manner and without having to rely on a shared certificate.

While laying the groundwork for the SNI capability, we thought it would be interesting to look at how much of the web could be effectively covered just by offering an SNI secured domain. From our empirical testing, over 99% of ALL SSL connections originated from environments with full SNI support, and for some of our customers SNI support represented as high as 99.98% of their connections. For some applications a dedicated IP with its own standalone certificate is still going to be the proper approach, but with SNI support available on all modern browsers since 2010 it covers the vast majority of use cases.

With such an economical and useful capability now in place across our global network the critical question became how to remove all impediments to its deployment by all of our customers, which leads me to the second key capability we’ve released:

Secure Certificate Workflow

We’ve retooled the entire pipeline for accepting certificates from our customers and applying them to our rapidly expanding base of edge delivery servers. By employing a fully encrypted configuration queue on top of our real-time configuration capabilities we’re able to expose end points in both the StrikeTracker UI and our RESTful API to securely consume customer certificates and deliver them to our global PoP footprint with no human interaction and with sub-second completion times.

Using a simple two-step process under our new “Certificates” left nav item you:

1.) select the local copies of your relevant certificate definition

Add Certificate


2.) verify that the public metadata was read correctly from them


If you are enabled for our Shared IP Certificate service that’s all you need to do. Your end users will now safely and privately validate against your certificates on any host configurations you’ve defined with Highwinds.

Once again Highwinds has proven our belief in the future of a fully secured web with the means to make it happen. We’re still working on some exciting new encryption features so watch this space for forthcoming announcements.

Julio Seijo

By Julio Seijo, Vice President, CDN Software Engineering