If you’ve ever played around with setting up multiple web sites on your servers using SSL for enabling HTTPS there’s probably a thing that’s been annoying you once or twice – the fact that you can only use one SSL certificate per IP address. (I am assuming IIS is your web server of choice for the sake of this discussion.)
You can easily have http://www.contoso.com, http://mail.contoso.com, etc. all tied to the same IP, but once you want to have https://www.contoso.com and https://mail.contoso.com things change.
Now of course if you happen to have an ISP which will happily supply you with IP addresses this isn’t a problem (at least in the short term); I have TMG servers with 20 external IPs for this very purpose. But IPv4 addresses are getting harder to come by, and if you try to sign up for 100 public IPs from your DSL-connection at home your ISP will most likely just laugh at you and say “no go”.
But why does it work for HTTP and not HTTPS? Well, the thing is that the host name is included in the HTTP header, and as such the client’s intended host name can be parsed by the web server. With HTTPS an SSL handshake is performed before exchanging headers, and the web server thus cannot base itself on the header information.
Server Name Indication (SNI) is an attempted solution to fix this issue. The domain name is extended to be part of the SSL handshake process, and then you can do for HTTPS what you can do for HTTP.
It’s been a fairly eventful June this year for us geeks. Apple started off with their World Wide Developers Conference (WWDC), then Microsoft held two guerilla-like press events before Google ends the month with their Google I/O conference. I have tried to look into the most interesting things coming from these events as viewed with the Enterprise mindset and the classic "we love Mobile Device Management" on the tip of my tongue 🙂
I mentioned in my last blog about Android Ice Cream Sandwich that it is now possible, (actually from Android 3.x Honeycomb), to enroll certificates directly from the /CertSrv web site onto your mobile device. (If you’re running a Microsoft CA of course.)
This is all nice and dandy, but it’s not like Android devices are the only devices you’re likely to be supporting. With the tablet varieties the split is something like 90/10 iPad vs “the rest”. However if you ever tried loading up /CertSrv on your iOS device or your Windows Phone you’ll have noticed that it’s not working.
I find this slightly annoying, and decided to look into this further. Those pesky ActiveX controls can’t be the only reason right? 🙂
There’s two things to sort out here really; is it anything with the web pages themselves and the server, or something on the browser side. Turns out there’s a bit of both involved actually.