Odd day at work today. I ended up doing a lot of things that were not my job, a little that was. Spent the morning trying to explain to a program manager what I was and wasn't experienced in (namely, the next version of the software and the last version of the software.) Of course, as I'm responsible for post-release improvements to our software, whatever is currently the next version of the software will hit my plate eventually, so I wasn't pushing back so much as establishing expectations. I want to learn it, I just don't want him to think I don't know what he thinks I'm supposed to know.

You know?

Midday was better. I was doing what I was hired to do - test software, especially the fixes to make sure they don't break anything else. That took some time to get 'into' -- I needed first to learn the product, to know what parts were connected to what other parts beneath the surface. I needed to have some idea of what could break so I could go looking for possibilities.

The afternoon started getting weird quickly. One of my fellow testers needed to learn to parse multi-part email messages (MIME, RFC 2045-2049), specifically how to extract the .ics (internet calendering, RFC 2445) portion of an embedded appointment and test it. Not in my job description, not in my job requirements, not even in my resume. I just know a little about it.

My manager gave me high marks for 'technical excellence,' which to his eyes was general geekiness. Well, not really. It was more the pursuit of knowledge, the commitment to expanding my experiences with technology, and trying to apply different factoids together as needed. Or general geekiness.

After that, the lab network guy commented to me about our certificate authority (CA). You know the 'padlock' icon when you're browsing a secure site, such as an ecommerce site? That means there's a certificate at work. Encryption only means that no one inbetween can see (or, by inference, modify) your traffic between you and the site. However, how do you know you're talking to who the site says you're talking to?

X.509 certificates have a 'chain of authority' that extends back to some handful of trusted certificate authorities in the real world. They 'sign' (generate and/or hash sum) certificates for a fee, after verifying they're signing for who they think they're signing for, etc. These signed certificates can be used in turn to sign other certificates under them.

My work has a certificate authority that is able to sign certificates for our internal use. The certificate it generates points at another internal certificate, and so on and so on until something points to some CA that all browsers are configured to trust, such as Verisign. I can't use it in the Real World because the internal CA it claims as pedigree is behind the firewall. It's only good behind the firewall.

Unfortunately, the certificate server was barfing on an "rpc timeout" or somesuch. I know RPC is the abbreviation for "remote procedure call," but I don't know much else about it beyond that. I do know that if we don't have a good certificate, our software won't be happy.

Some of my test code I've specifically coded to ignore bad certificates; the theory is that the developer has just tossed together a testbed system and hasn't had time to get the certificates right, or can't contact the CA for some reason. Either way, I want my test code to be able to run against the testbed so I can verify the functionality.

Fortunately, we don't (normally) have to remember what chain of programs to call with what parameters to get it to spit out a signed certificate. A few scripts (not programs, scripts. get it right.) do that for us. Or did. The one that actually generated the certificate was timing out on rpc.

I had to parse the scripts. I couldn't (easily) do that with a compiled program. I'd have to ask someone who owned it, and then that someone where the source was. In this case, I was looking at BATch files, which are scripts. Of course, they were scripts of an arcane and obtuse syntaxt, but I'll get better the more I go into it.

Still, I was able to follow and recreate the steps of the script until I, too, was stymied by the rpc timeout. I then looked for the help on that last step, toyed around with some options, and ... it worked.

I'm not a security guru. I'm not a network guy. I certainly don't know the Big Math that makes encryption work. All I did was poke at it, prod it and try something else. (Specifically, there was an '-rpc' switch to the program. I figured if it was timing out on an rpc request, perhaps the request wasn't being made in rpc-ese?)

Then someone asked my officemate how he could be sure that the system updater installed the new version of the software, if the version numbers were the same. I had already tested that by changing the timestamp on the bundled file, then seeing if our system updater caught it. It did, and it installed the same version with a newer timestamp.

But, this other tester (who is much more experienced than me and is someone I want to stay on his good side so I can learn from him) wanted to be sure.

Me: Blow the directory away, then.

Him: No, what if it failed to install? How do I recover?

Me: Then rename the directory. To the system updater, it'll be the same as if it never existed.

He stalked away and grumbled that there should be one place to look to see why it was reinstalled. Turns out, there is. Way deep in the logs is a 'snapshot' directory about the installtion, giving the date, version and path to the original file.

After running a test run on my machine cluster, I pointed my file browser at his machine cluster and found to cases where it re-installed the same version. I plowed through the logs and discovered in one instance, the network path to the sour bits had changed, triggering a resintall. The other was when someone changed the timestamp on the file to be installed.

All it all, it was a feel-good day, if not productive in the formal sense of the word.