JasonSamuel.com

You can use OpenSSL and run this command:

openssl.exe s_client -connect www.mysite.com:443

which will use a generic SSL/TLS client to connect to your site and give you a ton of diagnostic info.  You can see your entire SSL cert chain, the SSL handshake, SSL session info, etc.  Here’s a full list of switches you can use with it:  http://www.openssl.org/docs/apps/s_client.html

And here’s a great online tool to graphically verify your SSL chain is intact:  http://www.sslshopper.com/ssl-checker.html

Not to mention the .NET runtime, dllhost.exe also hosts COM+ processes.  So how can you tell what each dllhost.exe is running?  Download tlist.exe (part of the Debugging Tools for Windows).  You can read more about the util here:  http://msdn.microsoft.com/en-us/library/cc267860.aspx

It’s just a simple task list viewer that displays info about the process.  There are tons of utils out there than can do the same thing but tlist.exe is a mere 50 KB command line util which is why I like to keep it around for quickly gathering info. 

The command I use to check the dllhost.exe is:

tlist -k | find /i "dllhost.exe"

and it outputs the processes, process IDs, and the related COM+ process.

Have you ever had a giant log file or CSV that you needed to go through and pull results from quickly?  Sure you can try dumping it into Excel and trying different filters and sort orders but that’s a waste of time.  It’s much faster to pull your data via a query like in a database.  Microsoft has a tool called Log Parser that does just that.  You can use queries to parse any kind of text based file.

You can download Log Parser 2.2 from Microsoft here:  http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en

Just install it and try it out by opening up a command prompt, navigating to your install path, and running the logparser executable.  It will display a list of commands to get you familiar with it.   I first started using it to parse huge IIS logs.  It’s pretty easy to use, here’s an example of pulling the top 10 pages hit on your site:

logparser "SELECT TOP 10 cs-uri-stem as Url, COUNT(cs-uri-stem) AS Hits FROM c:\logs\ex*.log GROUP BY cs-uri-stem ORDER BY Hits DESC"

or all the Error 500s for a particular site:

logparser "SELECT [cs-uri-stem], [cs-uri-query], Count(*) AS [Hits] FROM c:\logs\ex*.log WHERE sc-status = 500 GROUP BY [cs-uri-stem], [cs-uri-query] order by [hits], [cs-uri-stem] DESC" -rtp:-1 -i:iisw3c

You can even throw the above in a batch file that schedule to run every hour and do something like:

All5005Errors.bat > All500Errors.txt

to log it all to disk.  Or even easier, use INTO in your SQL syntax to dump to a file like a .csv so it reads like:

logparser "SELECT [cs-uri-stem], [cs-uri-query], Count(*) AS [Hits] INTO All500Errors.csv FROM c:\logs\ex*.log WHERE sc-status = 500 GROUP BY [cs-uri-stem], [cs-uri-query] order by [hits], [cs-uri-stem] DESC" -rtp:-1 -i:iisw3c

There’s tons and tons of nice little queries people have written, for example I’ve personally used some from Jeff Atwood’s site here:  http://www.codinghorror.com/blog/archives/000369.html

Or you can got to the IIS.NET forums where there is an entire forum and many sub-forums dedicated to Log Parser here:  http://forums.iis.net/default.aspx?GroupID=51

Another cool tool over at CodePlex…Visual Log Parser:  http://www.codeplex.com/visuallogparser

I actually haven’t used this yet but it is out there if you get bored of using command line.  LMK if you guys decide to try it out.

Often times you might have to add an SSL cert to a Cisco or Citrix appliance (like a Netscaler) but it only accepts the SSL cert and private key in a certain format.  Your CA (certificate authority) will issue the SSL cert to you as a .crt.  From there, you need to package the cert with the private key and in the format your appliance requires.  There are different ways to do this and one easy way I like is using IIS and OpenSSL which is a free open source tool and can be downloaded here:  http://www.openssl.org

1. Create a temporary site in IIS and generate a CSR.  Make sure the CN (common name) you enter matches whatever appliance you are trying to generate it for exmp:  wireless.mycompany.com

2.  Submit the CSR to your CA such as Verisign, GoDaddy, Network Solutions, etc. and wait for them to validate and issue your cert.

3. Get the .crt from the CA once they issue it and convert it to .cer.  Just open the .crt by double clicking on it and and save it as .cer using the export wizard.  This is necessary since IIS does not accept .crt.

4. Install the .cer in IIS using the Web Server Certificate Wizard where you originally generated the CSR.  Just process the pending request to install it.

5. View the cert in IIS and export it with the private key in pkcs12 (.pfx) format.  Just set the password as “password” since you will be deleting it after conversion is complete later.

6. Go to the directory where OpenSSL.exe is and type in the following to convert the .pfx to a .pem

openssl pkcs12 -in nameofcert.pfx -out nameofcert.pem

7. Type the “password” when prompted for the pass phrase.

8. Install the .pem on the appliance and it should work

IMPORTANT NOTE:

If you are doing it for some appliances like a Cisco IronPort, you need to add the nodes switch when creating the .pem:

openssl pkcs12 -in nameofcert.pfx -out nameofcert.pem –nodes

The –nodes switch ensures that the key inside the .pem is left unencrypted.  If you attempt to install a .pem created without the -nodes switch, the appliance will take the cert but will not accept the private key since it cannot read it in an encrypted state.

A simple way to test if your MTA (mail transfer agent such as Exchange) is accepting email is to build the message by hand and watch the response codes from the server.  You can run this from the server console from a command prompt or remotely if you have the SMTP port to the server open.  Remember, once you are in the telnet session, don’t use backspace if you misspell something!  You’ll get an unrecognized command error if you do.  Just press enter and retype your command correctly if you do misspell something.

telnet localhost 25

This will open a telnet window to the server on SMTP port 25 and the server in return will send a 220 response code, the FQDN (Fully Qualified Domain Name), mail server version, and typically a time stamp as well.  Next you type:

helo

The mail server will respond with 250 response and it’s FQDN and say “Hello”.  You can also use:

ehlo

There is no difference using the commands except that EHLO returns info about the mail server’s capabilities along with the 250 response code such as the maximum SIZE of a messsage for example.  It’s useful to see exactly what your mail server is going to accept from a client.  EHLO is the more recent command by the way.  Pretty much all MTAs out there are going to accept either command nowadays.

This means the mail server is ready to accept more commands.  Now it’s time to begin composing your email:

mail from: joeblow@gmail.com

You should get a 250 response code and say the Send is OK.  Now type who you are sending it to:

rcpt to: joeblowsfriend@gmail.com

You will get a 250 response for the email address.  You can add more recipients by just typing additional lines like above.  Next it’s time to build the body of the message.  Type:

data

and you will get a 354 response code saying you can begin input.  First type a subject line for your message:

subject: Test email

Remember, type this on the very first line and then press <Enter> twice.  Now you can start typing your message body.  Once you are done with your message body, press <Enter> to start a new line and type nothing on this line except for a period.  Then press <Enter> again and you will exit out of the message body and immediately submit the email to the MTA’s queue for delivery.  You should get the test email within seconds if your mail server is working properly!  Make sure to check your Junk E-mail folder just in case your mail server marks your test email as spam.  To exit your telnet session, just type:

quit

and press <Enter> and you’re done.  Simple, right?

If you’ve ever used Urchin 6 for web analytics (Google’s pay for version of Google Analytics aimed at enterprises), you have probably seen profiles stuck in a “Running” state.  If you hit Run Now, you get this error message:

12008 – Action: Failed to cancel urchin process.

If you try to reschedule the profile, you get this error message:

12007 – Action: Failed to add profile to the scheduler queue. The profile is already in the queue.

This happens because Urchin’s scheduler is very sensitive to server reboots.  If you have jobs scheduled to run at night and let’s say you push patches to the server and reboot in the middle of the night, it can cause this error to appear on some of your profiles.  You get these errors because the log processing engine and scheduler never received the proper exit signals which means there will be database entries in the MySQL database that will be in an inconsistent state.  When the server boots back up, the log processing engine cannot pick back up where it stopped and the web GUI will show the profile is “Running” even though it is not.

The quick solution for this is to navigate to your Urchin bin folder via command prompt.  Here is an example path:

C:\Program Files\Urchin6\bin

then type:

urchinctl stop

which will stop all Urchin processes.  Then open up MySQL Command Line Client and type:

use urchin;
delete from uprofiles_queue;

This switches the database to the urchin database and deletes all running profiles.  Now if you go to to the web GUI under Profile Task Scheduler, you will see everything looks normal.  Now trying running the job again and it should work.  You should get a message saying:

12009 – Action: Profile has been queued to run. Please check the Profile Task History screen for status and runtime output.

Now don’t forget to restart your Master and Slave scheduler services or the job will remain in a queued state until they are back up:

urchinctl start

Now verify the job is actually running properly by clicking the green “Running” link for the job and you should see it processing the logs.

Have you ever had an IIS worker process (w3wp.exe) that was taking up a lot of memory and wanted to know exactly which application pool it was tied to?  Run this script located at C:\WINDOWS\system32 from command prompt:

cscript iisapp.vbs

This will tell you you the process ID of each worker process as well as the application pool ID it is running under.  This can help troubleshoot exactly which website or application is causing the memory spike.

Today I would like to clear up some confusion about SSL Chained Certificates. For this example, I will use Network Solutions as the Certificate Authority (CA) you are buying the cert from. This is information you will have to know when you purchase a new SSL cert or renew an existing SSL cert for your Exchange server, IIS web server, or any other external facing server or appliance.

Network Solutions does not issue you a single cert. They issue you an SSL chained cert. So for example, if you are buying a cert for:

widgets.com

They will validate and issue you the cert, but when you download and open the zip file from their website, you will see the following certificate bundle:

AddTrustExternalCARoot.crt
NetworkSolutions_CA.crt
WIDGETS.COM.crt
UTNAddTrustServer_CA.crt

Let’s analyze these certs in your chain. The first one is AddTrustExternalCARoot.crt which is called the “root certificate”. This is the first cert in your chain. This root cert is installed to the Trusted Root Certification Authorities store on your server or network appliance.

The second cert in your chain is NetworkSolutions_CA.crt and the UTNAddTrustServer_CA.crt which are “intermediate certificates”. An intermediate cert is essentially a certificate issued by the Trusted Root CA specifically designed to issue SSL Certificates to you. The reason for this is because if the CA root cert were to ever be compromised, the entire chain fails. It is good security practice to use an “intermediary” to issue the certs from to prevent your root CAs from being exposed from the signing process. If an intermediate were to ever be compromised, you can always regenerate those unlike the root certs. This intermediate certificate sits between your website cert and the root cert. This intermediate cert is installed to the Intermediate Certification Authorities store on your server or appliance.

The last cert in your chain is WIDGETS.COM.crt which is your actual SSL cert. This is also known as your “domain certificate”. This domain cert is installed to the Personal store on your server or appliance.

So the end result is chain of certs that begins at the trusted root CA, runs through the intermediary, and finally ends with the SSL certificate issued to you for your website or appliance (widgets.com).

In most cases, any sever or appliance out there will already have the trusted root cert for Network Solutions installed. You can just install your SSL cert and not have to worry about anything else in most cases. Depending on where you buy your cert from and what you are trying to install your cert to, you may have to go through the steps of installing the Trusted Root cert and Intermediate cert first before installing your SSL cert. With some web browsers like Internet Explorer 7 for example, you can get away with not having to install any Intermediate Certificate because IE7 will automatically go out automatically download the intermediate cert the first time a user visits your website. This makes things easy for the lazy admin but it’s always best practice to go a head and add the Intermediate cert on your end instead of depending on the client and their browser’s ability to do this. There is no point in risking a certificate error for the end user when the fix is so easy.

To verify the chain, go to any site you know that uses SSL (https://) and then click on the lock in Internet Explorer, it will let you view the SSL cert info. Click the “Certificate Path” tab and you can see the chain we described above:

Trusted Root —> Intermediate —> SSL Certificate

You can then click on each one of these certs and hit the “View Cert” button to view each cert in the chain individually. Good luck and post a comment if you have any questions.