Those disgusting things you did at the farm...

Not all was bad during the last satanic shitfest that was last week. Many things were learned. One being one of the nastiest tricks I had yet to pull off but is now added to my arsenal of information systems knowledge. If you're anything like me, then you know how awesome it feels to be me. Besides that you also realize that sometimes you're the only competent bio-organism to accomplish the task required or the only one with the gargantuan turgid balls to actually try. So when surrounded by unwilling and unmotivated sysadmins and paper pushers sometimes you have to go out of your way to do what needs to be done and prevent further agony and turmoil down the line.

The Problem:

I have a java written web service on my modest tomcat web server that third parties need to access. Currently that service was accessed in a very unsecured manner as it was not using SSL over HTTP. The client has a certificate but it's installed on only one of their Microsoft Windows IIS servers. In their infinite ignorance of not understanding how SSL and certificates work, they insisted that I had to use the same certificate installed on their IIS server on the Tomcat server. Clearly this wouldn't work as a certificate made for a specific address was not going to work with a different address. After explaining why they were being so stupid, a rare moment of reason and common sense swept them of their feet and sugested to buy a --> *. <--- (star-dot) cert for their domain. They needed this for a long time now and of course I encouraged this. But my celebration was short lived as a wild bureaucracy paper pusher appeared and told me it could be up to six months before they're able to get the certificate.

The solution:

As I stared in to the abyss of incompetence, the abyss stared back at me mocking me for my numerous fruitless efforts of competence. Then in an unscheduled brainstorming session meeting of the minds, one of the more competent sysadmin suggest that I used IIS to "redirect" the requests geared to a particular address to the Tomcat server. The term redirect is a misnomer as what what he really was trying to suggest was that we somehow configured IIS, which has an SSL certificate, to recieve the connections meant for the Tomcat server in a secure manner and then fetch those responses back to the clients that would consume the web service in a transparent manner. He didn't know what to call it but what he suggested was a transparent proxy.  A transparent proxy is an intermediary that connects on your behalf to a server and fetches whatever it is that you want and forwards it to you. As far as you're concerned, you were connecting to the intended server all the while. But, the correct technical term of what were really trying to do is a Reverse Proxy.

The arsenal:


These 2 IIS extensions basically enable exactly what were trying to do with some clever configuration hackery. I was skeptical at first at the ability for IIS to do this but it turned out better than expected. This is the suggested reading for understanding more about this: http://learn.iis.net/page.aspx/659/reverse-proxy-with-url-rewrite-v2-and-application-request-routing/

Finally after a night of clever regular expression matching and  compulsive testing I was able to configure IIS in the server farm to serve requests meant for another server on its behalf securely with SSL. As usual I emerged the hero of a thankless job well done.

I note that this functionality is also available in Apache as well. The geniuses writing all these tools have certainly graced us with such flexibility.

Comments