MuchTall.com

...in just three not-so-simple steps.

A couple quick notes before we begin: I threw this article together over a period of weeks, so the layout is a bit... odd. At some point I'll come back to this article and clean it up, however for now, I think it does the job of conveying the process to a new StartSSL user. Also, I use the names "StartCom" and "StartSSL" interchangeably, so don't look any deeper into the name usage than that.

A few weeks ago, I started the process of renewing several StartCom certs for my employer, and started to become familiar with the processes and pitfalls of identity and organization validation with StartCom. After delving into the process head-first, it became evident that this might not be as straight-forward as one might expect. However, I think that once you know what to expect, the process should go much more smoothly.

Also, please note that this how-to merely documents what I did to get a cert, and what pitfalls I ran into along the way. Therefore, your requirements and path may (and probably will) vary from mine. For instance, the tax document I submitted was a "State of Delaware Annual Franchise Tax Report". This document lists all of the items shown on StartCom's requirements. Your document(s) may not.

First, let's understand the steps required in obtaining Class 2 Org validation. Basically, you keep escalating your level of validation, providing increasingly trusted levels of personal and organization documentation as you go. Here's a rough outline:

• Get Email Address validation with StartSSL (free)
  • Sign up
  • Validate email
  • Get personal client cert (for browser) via website
    • Back it up!!!
• Get Personal Class 2 validation (~$60)
  • Submit 2 forms of ID
    • 1 Photo ID (i.e.: Driver's license)
    • 1 other form of ID. May be photo (i.e.: Passport), OR non-photo (i.e.: birth certificate)
  • AND submit either:
    • Phone bill showing your name, current address, AND (most importantly) phone number.
      • May be land line or cell

      OR

    • Request for certified mail validation
      • Delivery will take ~2.5 to 5 weeks (from Israel)
        • If expedited service is required, you may additionally request express mail (~4-5 bus. days) for approx $30.
  • Wait for call or letter, and verify provided code on StartSSL website control panel.
• Get Organization Class 2 validation (~$60)
  • Submit tax document which contains:
    • Name of CEO
    • Names of Directors
    • Co. Address (not sure if this is an actual requirement)
    • Co. Phone number (not sure if this is an actual requirement)
  • AND submit StartSSL's "Delegate Authorization Letter" (https://www.startssl.com/authorization-letter-class2-organizational-validation.pdf) with:
    • Your name, title as delegate
    • Name and signature of CEO, President, or Director (CFO also appears to work. Other C?? titles may suffice)
  • Have your signatory receive a phone call from StartCom to verify your authorization.
• Validate your domain(s)
  • Perform the "Domain Name Validation" validation wizard for each new or expiring domain
  • Confirm validation using code sent to email
• Generate Certs
  • Perform the "Web Server SSL / TLS Certificate" certificate wizard
    • Only new/expired certs or certs expiring within 2 weeks may be renewed (when the existing cert is with StartCom)
  • Generate password-protected key / cert pairs
    • Keep that password safe and backed up!
  • Save key to .key file, cert to .crt file (ie, wildcard.mydomain.com.key, wildcard.mydomain.com.crt)
• Install Certs
  • Decrypt (strip password protection from) key file
  • Place decrypted key and crt files on webserver
  • Configure Apache SSL
  • Reload Apache
  • Verify correct cert in web browser
• ???
• PROFIT!!!

And now for the more elaborate explanation:

1) Get your email address set up, and obtain a website authentication certificate. This is free. Go to the Control Panel and click Sign Up. Fill out the forms and submit. Soon you should receive an authentication code via email. You will submit this to the StartCom site, and then wait for another email that has a verification link, which you'll click. Once that's done, you'll get a personal client certificate for your browser. Follow the instructions in the email/website on how to backup this certificate. Don't skip this! Think of this as cert the key to your account. If you lose it, you're likely going to have to a hard time regaining access. Back it up to an external storage medium (perhaps even encrypted as well - TrueCrypt is good for this).

2) Get yourself a Class 2 validation. This will cost you ~$60 (with one potential caveat, described below). This is where things start to get more complex. You'll need two scanned or photographed forms of documentation that prove that you exist, AND a means of verifying that the person submitting the documentation is actually you. For the two forms of identification, one must be a photo ID (afaik), and another can be another photo ID (such as a passport) OR something that simply proves you exist, such as a birth certificate (this is what I used). Submitted photos/scans must be of "high" quality, but less than 1400x1400 resolution. The second half of this, and this is where I got hung up, is the verification that the person submitting the information is YOU. StartCom apparently trusts phone companies, because you "just" need to submit an invoice/bill showing your name, address, and phone number. This can be either a scan/photo or a PDF. This is where I got hung up. My current cell service is not in my name, and I have Ooma VOIP for home phone service, which doesn't do traditional paper or PDF invoicing. Attempts to submit website screenshots, or PDFs of a webpage will likely be rejected. StartCom needs to be able to verify that you own the number you say you do, and then call you at that number to verify that you submitted the request (presumably with a code conveyed by voice, then submitted to the StartCom website). In lieu of a verified phone number, your next/only option is a registered mail letter from StartCom (in Israel). They claim this takes 3-5 business days. That may be true if you lived in Israel. I live in the US. Internet rumor has it that this letter takes ~5 weeks to get to the US destinations. I'll see if one of my letters end up taking this long (see update below... took ~2 weeks). The alternative is to request express mail delivery, which costs ~$30. This will take approximately 4-5 business days. I opted for this to expedite the process. Once you receive the letter, it will contain a code which you submit via the StartCom website control panel. Shortly after, StartCom should send you confirmation that you have been personally Class 2 verified.

3) Get your Organization Class 2 verified (another ~$60). This part is still in progress for me. I will be updating as I go along. First step appears (at least for now) that I have to obtain a yet-to-be-identified tax document from our finance/accounting department that proves that our company is recognized to exist by either the State or the US. Also, it's not clear if I, as an employee of the company, can submit the tax documentation and as a result get access to create these certs, OR do I also need to submit an authorization form that delegates me to make cert changes on behalf of the company. Sure would be nice if StartCom would clear some of this up on their website, or at least on their forums.

More on this as the mystery unfolds...

Update 5/28: A few updates

• Today I received my initially-requested snail-mail letter from StartCom. The letter was requested late on the 10th, so that means it takes 14-16 postal days (Mon-Sat) to get to Minneapolis, MN. But of course, YMMV.
• In the case of my company, the tax document used was a Delaware Annual Franchise Tax Report (as the company is incorporated in Delaware). Your document will almost surely be different. My recommendation is to ask your accountant or executive for a copy of the Articles of Incorporation applicable to your state.
• Unless you are the CEO, President, or a Director of the company/org you are applying for, you'll need to fill out the  StartSSL Delegate Authorization Letter, printed on company letterhead, and have one of the aforementioned individuals sign it. Currently I'm attempting to use our CFO's signature to see if that is sufficient. If not, I'll be going to CEO to get the required signature.

Update 6/4: Eventually I got a signature from our CFO. I submitted the document to StartCom, and within a few hours I got an email back they they were unable to reach anyone at the listed office number. Presumably they tried to contact our CFO. I asked them to try again, and soon after got an email stating that the Class 2 Org Validation is complete! Once that was done, I was able to log into the StartCom control panel and perform Domain Name Validation(s) for each of our domains. It appears they offer a number of hostmaster/postmaster addresses as options to send a validation email to your domain. In addition to our other TLD's, they offered hostmaster@our_main_domain.com. Not sure how they linked them to our main corporate domain (possibly public WHOIS data), but they did. Up next, cert generation!...

Update 6/7: This ended up being the most straightforward process of the entire adventure. In my case, the web service in use was Apache. This process will likely vary for an MS-based/IIS server. Once your domain(s) is/are validated, you can go back into the StartSSL control panel, go the the certificates wizard, and select "Web Server SSL/TLS Certificate". Set a password for you keyfile and generate the key. Keep good tabs on this password as it's what decrypts your private key for use on your webserver. Save the resulting key text out to a file named something like "wildcard.mydomain.com.key". Continue on and select your domain, and enter/add your subdomain(s) or subdomain wildcards as needed (see notes below regarding restrictions). Once the cert is generated, save the text into a file named something like "wildcard.mydomain.com.crt". Keep these files safe and backed up!

A few other notes related to this: Note that a subdomain wildcard only applies to the level of that wildcard. So for instance, *.mydomain.com would cover test.mydomain.com, byt not test1.test2.mydomain.com. For that, you need to specify wildcards for each recursive level, ie *.test2.mydomain.com. Also note that domains that still have active StartSSL certs (or are not expiring within 2 weeks) are not able to be renewed. If you must renew them, you must revoke the existing cert, which costs approx $25. Be aware that you could still generate certs for individual specific (sub)domains instead to avoid going through the revocation process.

You can now proceed to install the cert on your webserver, however note that hte .key file is password protected/encrypted. You must strip the password in order to allow your web service to start up unattended. Here's a quick command to do that:

openssl rsa -in wildcard.mydomain.com.key > wildcard.mydomain.com.decrypted.key

You can then take the decrypted key and use it in your Apache config. Please note however that you must take care to restrict access to your server so that your private key is not copied by unauthorized persons. They alternative to this is to leave password protection on, but intervene manually by entering in the password each time Apache is (re)started.
So there you have it! At some point I'll probably come back to this article and clean it up. For now, I just wanted to get the information out there to help my fellow interweb users. Good luck!

This is an obscure tip, but it thought it was cool enough to post as it comes in handy when scanning in inventory with a barcode scanner. This works on Polycom 8400's (8440/8450) and 8000's (8020/8002)., and probably any other Polycom SIP device.

This formula will take the serial number in the column to the left and convert it to a MAC address.

="00907A"&REPT(0,6-LEN(DEC2HEX(VALUE(RIGHT(INDIRECT("RC[-1]",0),LEN(INDIRECT("RC[-1]",0))-3)))))&DEC2HEX(VALUE(RIGHT(INDIRECT("RC[-1]",0),LEN(INDIRECT("RC[-1]",0))-3)))

I recently started using Grindstone to track my daily workload, and I've been using a number of calendars on Google to not only share classifications of appointments, but to track historical data (Android call logs, etc). I kind of expected that Grindstone would have iCal/ICS export capability, but sadly it does not appear so. You can, however, export to XML. So I thought I'd write up a Perl script to convert the XML data into an ICS file ready for import into Google Calendars. Feel free to download it and use to to convert your Grindstone XML files into iCal data.

Here's the Perl script: grindstone2ics.txt (Save as .pl, not .txt)

If you are on Windows with ActivePerl installed, here's a batch file that you can drag-and-drop your XML file onto. Place it in the same folder as "grindstone2ics.pl": grindstone2ics.bat

Let me know if this helped you!

Every so often I have to recover a drive to a disk image on Linux, and before I transfer the data back to a physical drive, I like to mount the disk image check on it's status. Mounting a partition from a disk image is slightly more complicated than mounting just an image of a partition, so I thought I'd post a shortcut to doing so. This information was derived from the how-to posted here (http://madduck.net/blog/2006.10.20:loop-mounting-partitions-from-a-disk-image/). You will need to alter three variables: DISKIMAGE, DISKPARTITION, and the mount path at the end of command.

DISKIMAGE=/media/usbdisk/mydiskimage.img ; DISKPARTITON=2 ; mount -o loop,offset=$((`fdisk -lu $DISKIMAGE 2> /dev/null | grep -P "$DISKPARTITON\s+\**\s+[0-9]+\s+[0-9]+\s+[0-9]+\s+[0-9]+" | sed 's/\*//g' | awk '{print $2}'` * `fdisk -lu $DISKIMAGE 2> /dev/null | grep "^Units" | awk -F"= " '{print $3}' | awk '{print $1}'`)) $DISKIMAGE /media/recovereddisk/

Hope this helps someone else save some time!

For some reason, this is a topic that I couldn't seem to find a simple HOWTO online for, so I had to create my own.

I ran into a situation where I have a large number of auto-answering intercom boxes connected to an Asterisk system. The intercoms are programmed to pick up immediately upon ringing, allowing the caller to communicate with the room's occupant without any action taken by the occupant. These intercom lines are assigned a DID number from the outside world in a large metro area. See the problem? The occupants were getting a number of calls from locals whom had dialed the wrong number. Sometimes the caller wouldn't hear a response, so they'd call back repeatedly, to the irritation of the occupant. For our scenario, blacklisting wasn't a good option. In metro areas, misdialed numbers are common, and rarely from the same person. I needed to only allow a handful (~20-50) of callers that we knew would be calling the intercoms legitimately. Furthermore, it would be useful to have a notice played for a blocked caller to that they knew either to not try calling again, or to contact us to whitelist the number.

Here are the rules I used in Asterisk to achieve this goal. First, in extensions.conf, I created a macro for whitelisting:

; Only allows calls from numbers in the whitelist DB
[macro-inbound-whitelist]
exten => s,1,GotoIf(${DB_EXISTS(whitelist/${CALLERID(num)})}?:blacklisted,s,1)
exten => s,2,Dial(${ARG1})


Then, if you don't have a blacklisted context already, create one:

[blacklisted]
exten => s,1,Playback(not-taking-your-call)
exten => s,3,Hangup


Next, change your inbound call config to use the inbound-whitelist macro:

exten => 5551234567,1,Macro(inbound-whitelist,SIP/123)
exten => 5551234567,2,Hangup


Reload the asterisk config and make a test call. You should get a recording saying that it (Asterisk) is not taking your call.

Now add your number to the whitelist:

asterisk -r
database put whitelist 5551230000 1


And do another test call.

One last word of warning. I did once run into a condition where our telco provider abruptly stopped sending caller ID through our PRI. When this happens, ALL calls show up as null/blank calling numbers. In these instances, ALL calls to your whitelist-protected extensions will be blocked (at least from outside). To temporarily disable whitelisting until the problem is resolved, simply comment out the "exten => s,1,GotoIf ..." line and reload asterisk.

Hopefully this saved someone else out there some time.

UPDATE: I found that comparing against two whitelists (a customer whitelist, and our support number whitelist) can be handy. Use this line instead if you want similar logic:

exten => s,1,GotoIf($[ ${DB_EXISTS(whitelist-${ARG2}/${CALLERID(num)})} | ${DB_EXISTS(whitelist-support/${CALLERID(num)})} ]?:blacklisted,s,1)

Also with this option, I can treat the whitelist name as an argument in my macro call:

exten => 5551234567,1,Macro(inbound-whitelist,SIP/123,customername)

In this case, the whitelist DB would be named "whitelist-customername".

Credit for this procedure goes to Major Hayden at Racker Hacker (http://rackerhacker.com/2012/02/11/installing-fedora-16-in-xenserver/). My procedure just uses an alternate, minimal kickstart file that gives you more control over the installation using the Anaconda GUI.

- Start an installation using the RedHat 6.0 64bit template
- In the installation wizard, use these advanced options: console=hvc0 serial ip=dhcp nogpt vnc ks=/"content/f16onxen6.ks
- Connect to the installer GUI using VNC and the IP shown in the console.

Proceed as normal! If you care to see the source of the kickstart: /"content/f16onxen6.ks

I recently ran into an issue on Windows 7 64-bit where ADSM-ISM Launcher failed to connect to my ASAs. Launching the application from a shortcut, and attempting to connect resulted in the launcher halting on "Contacting the device. Please wait...". And waiting didn't help. Opening the java console revealed another error which didn't get me any useful results on Google:

Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: sun.security.ssl.X509TrustManagerImpl cannot be cast to com.sun.net.ssl.internal.ssl.X509ExtendedTrustManager

However, if I "re-installed" ASDM via the "dm-launcher.msi", the first time it was spawned by the installer, everything worked fine. Subsequent launches from the application shortcuts failed. A quick check with Process Explorer revealed the issue. The dm-launcher installer launched the java app using "C:\Windows\SysWOW64\javaw.exe", whereas the shortcut would use "C:\Windows\system32\javaw.exe".

The ultimate fix ended up being updating all my ASDM shortcuts to use "C:\Windows\SysWOW64\javaw.exe". Now everything is working great!

UPDATE 2/25/2013: So the pain continues with Java 7. If you have upgraded your JRE, you probably saw a recurrence of this issue. In that case, I recommend pointing your shortcut(s) directly to the version 1.6/6 JRE instead:
"C:\Program Files\Java\jre6\bin\javaw.exe"

Hope this helps someone else out there.

If you found this helpful, maybe you'd like to send a thank you from my wishlist?

One of the frustrations I have/had with Remote Desktop connections on multi-monitor workstations (with unique display resolutions mind you) is that there's no way within the RDP GUI to save the position of a fullscreen RDP session. So if your RDP session opens up on display 2 each time, good luck getting it to display properly on display 1 or 3 unless you have identical resolutions on each display. Even then, it's a hassle to restore the RDP session to windowed mode and move the the preferred display each time you connect.

Hassle no more: There is a solution. All you need is notepad and a little understanding of how display coordinates work (don't worry, I'll explain).

First off, save your RDP session to an RDP shortcut (ie, Acme.rdp). Open notepad and drag the RDP file into the window. Notpad should open the source of the RDP file for your perusal. You'll see some lines similar to this buried within the file:

screen mode id:i:2
use multimon:i:0
desktopwidth:i:1920
desktopheight:i:1080
winposstr:s:0,1,50,170,250,370

Set "screen mod id" and "use multimonitor" as shown above. The settings "desktopwidth", "desktopheight", and "winposstr" will vary depending upon the resolution and physical position of the display you iwsh to use as the destination.

First, an explanation of the winposstr variables we are concerned with (in order):
s: Not applicable
0: Not applicable
1: Sets the RDP session to start windowed (screen mode id sets it to be fullscreen after launch)
50: Pixel distance from the left-hand edge of display 1 to the left edge of the RDP window
170: Pixel distance from the upper edge of display 1 to the upper edge of the RDP window
250: Pixel distance from the left-hand edge of display 1 to the RIGHT edge of the RDP window. Difference between this and the left edge must be >= 200! (250 - 50 = 200)
370: Pixel distance from the upper edge of display 1 to the LOWER edge of the RDP window. Difference between this and the upper edge must be >= 200! (370 - 70 = 200)

Note again that the window dimensions MUST be greater than or equal to 200x200. If it is less, RDP will completely ignore your windows placement dimensions and go with defaults, defeating the purpose of this process.

Now that you know what the numbers mean, you need to understand where to place the window (by pixel dimension) in order to get it to come up on the proper display each time. You have two options: The complex/geeky way, or the simple way.

The Complex Way
Screen coordinates are all relative to the upper left edge of display 1. This position is 1,1. So if You have a single display system with a resolution of 800x600, the lower right corner of the screen is position 800,600. If you have two displays at 800x600 positioned like this in display properties:

[1][2]

...the lower right corner of display 2 would be 1600x600

If the displays were physically reversed:

[2][1]

..the lower LEFT corner of display 2 would be -800,600

Based upon this information, and using some simple math, you should be able to estimate window position amongst your displays. Now, this will get slightly more complex if your displays are offset on the Y axis, so what you might prefer is the...

Simple Way
Download and install the free AutoHotKey Basic. It comes with a nice utility called "AutoIt3 Window Spy". Run this utility and fire up your RDP session in windowed mode. Then, move the RDP window into your desired destination display. Try to keep the Active Window Info screen visible when you do this.
You should see something similar to this in the Active Window Info window:

>>>>>>>>>>( Active Window Position )<<<<<<<<<<
left: 434 top: 700

Now, lets use those numbers to create the winposstr settings:

winposstr:s:0,1,434,700,634,900

Note that I added 200 to the window position (634,900) creating a window size of 200x200.

Adjust the display width and height settings to match your destination screen.

Go ahead and save the RDP file and try connecting again. The RDP session should now open on the correct screen each time you use this shortcut.

When trying to connect to an MSSQL server on another domain (of which you are not a member), you'll probably run into the issue where selecting the Windows Authentication option in the SQL Server connection dialog grays out the username and password. Here are two workarounds:

Scenario
SQL Server: sqlserver.mydomain.com
Domain: MYDOMAIN
MYDOMAIN Username: joe.user

A) Create Saved Credentials
Go to the Control Panel --> User Accounts --> Manage Your Credentials (in left-hand pane) --> Add a Windows Credential

Address: sqlserver.mydomain.com
User Name: MYDOMAIN\joe.user
Password: (password for joe.user on MYDOMAIN)
Click OK

Now, when you fire up SQL Server Management Studio, enter your server name (sqlserver.mydomain.com) and select Windows Authentication. THE USERNAME WILL BE GRAYED OUT but that's fine. The connection will authenticate properly anyhow. Go ahead and connect.

B) RunAs Command Line (requires user interaction for password)
Open a command line and run this:
runas /netonly /user:MYDOMAIN\joe.user "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe -S sqlserver.mydomain.com -E"
(You will need to alter the SQL Management Studio exe path as is applicable to your PC)
When prompted on the command line, enter the password for joe.user.
SQL Management Studio should load and automatically connect to the SQL server.

If you are unable to connect with either of these scenarios, check the firewall settings on the remote system.

Credit where credit is due (references):
http://stackoverflow.com/questions/849149/connect-different-windows-user-in-sql-server-management-studio-2005-or-later
http://support.microsoft.com/kb/306541
http://social.msdn.microsoft.com/forums/en-US/sqlsecurity/thread/ed11ff0f-b59c-48bc-ba92-277f1c3e3107/

If you found this helpful, maybe you'd like to send a thank you from my wishlist?

If when your try rooting your phone with Unrevoked, you encounter the error "process com.unrevoked.zysploit has stopped unexpectedly" during the initial rooting process, you probably have an application interfering with Zysploit, or a bad install of Zysploit itself. Try removing the following apps (from Manage Applications") in order, and retry between apps:
- Zyploit
- Wireless Tether
- Comcast Xfinity

If someone out there could help confirm what app ultimately fixed this issue, I would appreciate it so I can report the confirmation here. I my case, I started with uninstalling Comcast Xfinity, then with Wireless Tether and Zysploit. Once I did that, Unrevoked worked great.