Archive

Posts Tagged ‘IIS’

Changing the host header for an already existing Sharepoint site/application

August 11th, 2009 Jason No comments

So let’s say you have http://originalurl and you want to change it to http://newurl.  Don’t do it through IIS!!!  Pretty much everything you will ever need to manage a Sharepoint farm will always be found in CA.  Here’s how you accomplish this simple task:

1. Login to CA
2. Click the Operations tab
3. Click on “Alternate Access Mappings” under Global Configuration
4.  In the top right, the default view is “Show All”.  Just choose the web application you want to change.
5.  Click Edit Public URLs and change the URL to whatever you want it to.

Done!  Test it out and verify it works.

How to tell which w3wp.exe worker process belongs to what IIS application pool

June 10th, 2009 Jason No comments

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.

Categories: IIS Tags: ,

SSL certificate chains explained

March 12th, 2009 Jason No comments

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

sslcertpath
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. :)