Now Shipping SNI: Free Custom SSL with MaxCDN
July 29, 2014 | David HenzelToday, we’re happy to announce that MaxCDN officially rolls in support for SNI SSL certificates. You can easily upload your own SSL cert and use it with any MaxCDN Pull Zone to have Free custom SSL. You might be wondering what’s the difference between SNI and Dedicated SSL? The answer to that can be seen in price, IP, and support: So, what is SNI? SNI, or Server Name Indication, is TLS subsystem that allows server to present multiple endpoints (websites, applications) that require secure connection over SSL, by delivering content via different (separate) certificates while using same IP address. With normal, dedicated SSL, having unique IP address is mandatory to identify and secure specific end points; however, by using SNI, the process for engaging SSL handshake and maintaining SSL connection works on methodology of virtual hosts where unique identifier for the end point is the host name:
BenefitsWhen dedicated SSL is used, environment that needs to satisfy SSL traffic defines single IP per host name that is being accessed to. Also, before the browser establishes the connection with particular host, SSL negotiations needs to be done first, after which requests reaches desired host name - virtual host. With SNI, browsers (clients) are able to reach out to hostname (virtual host) directly by including the hostname in it’s request which allows server to identify which host should be serving traffic through SNI. So, we have great feature to save IP addresses in process of ensuring SSL connections providing identification on the host name basis and a fallback to default certificate in case that browser requesting SNI SSL handshake doesn’t support it. The fact that multiple certificates can be served from a single IP and still, support secure connections with proper handshake and secured transfer, as dedicated SSL provides, is a stress release.
LimitationsSpeaking in general and focusing on what SNI is bringing on a table, only limitation worth mentioning would be browser support. So, what happens when connection is requested from a browser that doesn’t support SNI? Browser initiates a request over SSL and gets a response from server with SNI indication, now, if browser is supporting name indication method, process will proceed into handshake and SSL connection will be established. However, browser missing the SNI support will be identified on server side as no-SNI and will be served with default certificate instead, with security warning where user can accept the connection or decline. So far, first candidates for facing SNI non-supportive browsers are users of Internet Explorer on XP and Android 2.x browsers.
Browsers supporting SNI
- Internet Explorer 7 or higher, on Windows Vista or newer. Does not work on Windows XP and Internet Explorer 8
- Mozilla Firefox 2.0 or higher
- Opera 8.0 or higher (the TLS 1.1 protocol must be implemented)
- Opera Mobile, version must be at least 10.1 beta on Android
- Google Chrome (Windows Vista or newer, Windows XP requires Chrome 6 or higher, OS X 10.5.7 or newer requires Chrome 5.0.342.1 or higher)
- Konqueror/KDE 4.7 or higher
- MobileSafari for Apple iOS 4.0 or newer
- Android standard browser on Honeycomb (v3.x) or higher
- Windows Phone 7
- MicroB on Maemo