What's worse than a brick wall?

Trying to build a brick wall without a firm grasp on the concept and practical use of a brick.

I ran into quite the dilemma this evening trying to better understand NetScaler's URL Rewrite/Transform engine.

Really, my dilemma had several facets.

1. While I have a general idea of how HTTP request and response headers work, this is the first role in which I've been expected to manipulate them.
2. Learning from the Citrix eDocs site how the specific machinations of a particular product feature works is easily done.  Learning the context in which such machinations are or should be used - not so much.
3. I didn't actually know what to call - and so, how to search for - the information I needed, so I breadcrumbed all over the goddamned Internet only to end up back on Citrix's eDocs site a few URLs away from where I started.

I slammed headlong into these problems because I wanted to know how to accomplish some URL rewriting wizardry on the NetScaler 7500 appliance(s) we have at work. 

I know now that the NetScaler's system for rewriting URL's is evidently proprietary (though its core web services are built on Apache), and that understanding how to achieve what I want demands I understand (and type into a Google box for) "NetScaler http rewrite expressions" for versions 9.3 and 10.1. 

Obvious in hindsight.  Shut your whore mouth.

What I have:

• Several IIS 7.5 servers will host the production instance of our much-ado new public web portal.  I will call these servers WEB01, WEB02, and WEB03, and all three servers run the same two web applications:
• The "main" portal web application, accessed via a client's browser
• The mobile application, developed and boxed by the vendor to handle connections from iOS and Android applications.
• Sitting in front of my servers is, as mentioned, a NetScaler 7500.  On this appliance are the server and service objects, as well as the single LB VS object that internally represent my three web servers.
• There are two domain names that will represent both applications across my three servers to the world: one for external use, one for internal use.  They, with their mobile URL in tow, look something like this:
• https://site.publicdomain.com
• https://site.publicdomain.com/mobile
• https://site.internaldomain.com
• https://site.internaldomain.com/mobile
• I have two SSL certificates in play here, one for each namespace.  The certificate for my publicdomain.com namespace comes from a publicly trusted CA, while the internaldomain.com cert comes from the enterprise CA (which I think is just an ADCS server).

Regardless of this monster's final (back-end) form, the basic flow of things will go something like this:

1. A client types https://site.publicdomain.com into their favorite browser.
2. Because the public DNS is bound to a publicly accessible VIP on the NetScaler, our beloved NetScaler 7500 receives the request.
3. Because this is a secure site, a secure connection is negotiated using the public SSL cert that's sitting in the NetScaler's internal certificate store.
4. The NetScaler makes a load balancing decision based on the status of the three web servers its virtual server is configured to monitor and picks WEB02.
5. The NetScaler negotiates a secure connection with WEB02 using the enterprise-issued SSL certificate sitting in its internal certificate stores.
6. Client requests and server responses are moved back and forth, and all's well in my world.

Firstly, I'm going to take a moment to justify #5.  Much of the web traffic I'm administering is sensitive.  Highly so.  Like, medical record kinda' shit.  While there are a dozen good arguments for terminating SSL completely at the NetScaler and connecting unencrypted to the (presumably trusted) back-end, our back-end is not particularly trustworthy.

<pause for gratuitous innuendo>

Secondly, it is in steps 4-6 that one of my major points of indecision comes to haunt me.  If I simply pass the REQ headers to WEB02 as-is, then WEB02 must be configured to answer for any potentially requested host.  That is, it must have site bindings for both the public and internal namespaces, OR it must have a single site binding configured to use a SAN-enabled SSL certificate.

That "OR" part just hit me.  Going into that thought I believed there existed the need for two separate bindings - one for each namespace.  That would require two server certificates, and two IP's, since only one cert can be bound to an IP (without some of Server 2012's new hotness).  I could instead simply have one SSL certificate issued with a Subject and Subject Alternate Name to represent both namespaces and bound to a single site.

The alternative to passing the request's HOST header through is to rewrite it from the public namespace to the internal one, and only have to configure the web servers to answer for the one hostname.  Of course even this alternative belies an apparent obsession with locking down a site to answer only for a specific host.  I'm not 100% sure from whence this obsession stems, but ... there it is.

I should stop now.  Plenty more tomorrow.  This will all make sense by my third cup of coffee and after my second axe murder.

(J/K on the axe murder, Friendly NSA Analyst)

~Fin~

The idea came in the most surprising of packages

 I don't typically "just run."

I'm not a runner.  I engage in physical activities, sure, but this morning's decision to run around the neighborhood park was atypical.  This past week saw my attendance at my local Crossfit gym (or, as we say in the Legion, the "box") lacking, and I suppose some primal part of me determined it needed the satisfaction brought only by physical discomfort, sweat, and mediocre breathing technique.

Leading up to my first footsteps on the (literally) broken path to the park, my thought process went something like this:

1. I feel like a fatty.  I should go running.
2. Why the hell do I have so many more workout shirts than shorts?  Where did all my shorts go?
3. I should wear a hoodie.  Nothing is worse than cold-air-runner's-lungs.
4. It's 58F out.  I should not wear a hoodie.
5. I don't believe the manufacturer of these "no show" athletic socks anticipated how low cut crossfit shoes actually are.

Dressed, stretched, and now walking - making what must appear to be ridiculous windmill motions with my arms as I go - I decide to focus my mind on work.  It is partly a distraction, to keep from dwelling upon the physical discomfort I'm soon to experience, but also a hope that the "experience" of the run will allay fears of the coming week and sharpen any lingering ideas I have about any manner of web-administer-y topics.

Somewhere around 150bpm, only a few minutes into the run, one idea revealed itself above and before all others.

I should blog about this shit.

Why?

I have never been a server administrator before.  Sure, I've studied and certified on topics of server administration, and I have through those studies and personal experiences with other administrators formulated a host of ideas of how such a thing is or isn't, should work or shouldn't.  However, until my current job, it was all armchair quarterbacking.  It was my puerile attempt to sit at the adult's table and talk about something more than just how slow Internet Explorer was, or how someone's "Internet is broken."

Now I'm at the adult's table.

I have metric crap-tons of new material to learn, new ideas to explore, new swords on which to hurl myself unknowingly and otherwise, and a whole host of mistakes to make.  I decided I needed a vessel to receive my thoughts on these things, a medium on which I could present what I learn, what I accidentally set fire and leave alone to crash into the sea.

I am an IIS Administrator.  This is my story.

~Fin~