Today’s New Word
Cercurity (n): security provided by a certificate.
The Background
Recently I have been working on migrating a customer away from using a custom client / server communications model in their Enterprise Windows Mobile solution to a more modern model of Web Services, and to support SSL connections in the process.
As should be expected, this migration was somewhat non-trivial in that not only did I have to utilize SSL and Web Services, but I also had to honor some existing binary data modeling as well as some complex server-side business processes that linked their legacy back-end systems to their mobile field force.
The Approach
My implementation path was to utilize asynchronous WinINET via Win32 on the client side and craft a custom ISAPI extension via C/C++ on the server side. The end result would be a mobile solution that could act like a web browser and talk both http and https and a scalable server that looked like a “binary” Web Service and could output HTML when hit by a normal web browser and proprietary binary data when hit by the mobile solution.
All went well for the most part. The client communications component took some bashing when the VS2005 debugger was involved (gotta love debugging over the intranet, but man, can’t MS sort out their timeout issues and memory loads?), and the ISAPI extension was initially a bear to debug through VS2005 and IIS, but I’m happy to report that I was ultimately able to migrate both sides to use the new technologies while maintaining much of their existing business logic.
The Trouble
Fast forward to a couple weeks ago – we’ve finally moved to testing. The customer decides that they want two environments for the system: one for testing and one for production. Seems fair enough so we set up two servers with IIS, install the new ISAPI extension on both with its provisions, and request that two new external domains be secured with certificates to match.
At the time the domains names were decided, no one knew what we were about to walk into but it appears that some browsers, both mobile and desktop-based, are plagued with the same parsing-related error when host names containing a “dash” are embedded in an SSL certificate Take for example, the following two URLs, which are similar to those of the customers and who’s certificates were generated by the same group. Again, the only things different were the host names (the “dash” + test).
subdomain-test.domain.com and subdomain.domain.com
Well, it seems that Pocket Internet Explorer on both Windows Mobile 5 and 6 as well as desktop Opera dislike the “dash”. Yes. Believe it or not, they flag the certificate with “being signed by an unknown authority”. What the!? Oddly, Both Microsoft IE7 and IE8 and Mozilla Firefox do not flag the certificate as a problem, which of course, adds to the mystery.
The Rant
Why oh why does a certificate containing valid host name characters fail on certain browsers? Why has no one encountered this issue in the past? Perhaps Microsoft and Mozilla have, but it seems they’re currently OK with the “dash” now. And I could not find any Knowledge Base articles on it either. Sigh.
What’s worse is that Microsoft’s Pocket Internet Explorer can be tricked into accepting the “flawed” certificate by first visiting the good certificate generated from the same authority and then refreshing the previous URL. Perhaps caching is blame but still, this has to be a red flag for somebody.
The End
Has anyone else encountered this issue? Have you learned of the reason? Has it been reported? Please share.
Bah, all because of a ”dash”.