SecurityWeek Shows How Not To Set Up SSL/TLS on Your CDN

This is a little different than our usual IoT Security topics, but SecurityWeek magazine is currently demonstrating how NOT to set up SSL/TLS your CDN (content distribution network).

If you go to SecurityWeek now, you will see that they switched much of their content over to an https-based server that requires the use of SSL/TLS (as the White House CIO has mandated for all federal sites). Normally, this is a good thing, but not when it prevents readers from seeing your site at all.

securityweek_SSL_error_connection_is_not_private
Google Chrome 43 refusing to browse to https://www.securityweek.com because of a certificate name mismatch.

The reason Chrome (and other browsers) are banning access to https://www.securityweek.com is that the CN  (common name) on the server’s X.509 certificate is “incapsula.com” not “securityweek.com.”  This is a mismatch browsers  look for to prevent hackers from hijacking legitimate https-based sites with any old certificate.

securityweek_servers_certificate_does_not_match_the_url

The errors provided by the browser (“Your connection is not private…”, “Server’s certificate does not match the URL” and “NET:ERR_CERT_ COMMON_NAME_ INVALID”)  provide all the clues we need to diagnose the problem.

If we click the “Certificate information” link in the error message, we can see that the “CN” (found in the “Subject” attribute) of the X.509 certificate is indeed “incapsula.com.”

securityweek_x509_certificate_cn_is_incapsula

We can also look at the often-supported “Subject Alternative Name” field to see if “DNS Name= *.securityweek.com” or a reasonable typo exists in that field.  Unfortunately, it does not.

securityweek_not_listed_in_subject_alternative_name

So what is “incapsula.com” and why is it on securityweek.com’s https site?  A quick web search shows that incapsula.com  is a CDN, or “content delivery network,” that essentially pre-distributes and serves up the images, script files and other static content from large sites like securityweek.com so that loads hit the CDN’s network of distributed servers instead of the original securityweek.com servers.

securityweek_what_is_incapsula

So what should computerweek.com have done instead of this?  As with many web configuration items, there are many options.  Three of them might have been to:

  1. Use a CDN-branded https:// address like “https://computerweek.incapsula.com”.  This would work because incapsula.com’s “wildcard” cert would cover any domain name that ended in “incapsula.com.”  This is what many smaller sites do when they use HTTPS services on a CDN, but bigger “brand name” sites usually do #2 or #3 instead.
  2. Add their domain name to the list of “Subject Alternative Names” on incapsula’s wildcard cert.  As you can see above, many other companies have already done this.  (In fact, inspecting this field on X.509 server certificates is often a fun way to harvest a list of major customers from many cloud providers.)
  3. Buy their own “cdn.securityweek.com” or similar X.509 certificate and have the CDN provider install it.  This is most secure way to go, but it also carries the most cost.