Technology 'n Me (Sukesh) : IIS & HTTP

How to Check certificate expiry for webserver (IIS) certificates using script

sukeshak — Thu, 13 Sep 2007 08:40:00 GMT

Although the title says webserver certificates the script is not limited to webserver certificates only.

This script is useful for admins to check expiry dates of server certificates and be prepared to renew or change them. In case if you have ideas of using this in your server environment and you need help in tweaking this script do let me know.

Please copy & paste script below into a file called "CertExpiryCheck.vbs" and run the script from command line like

C:\> cscript certexpirycheck.vbs [SubjectName]

C:\> cscript certexpirycheck.vbs sukak

* here "sukak" is subject name which usually would be your domain name (FQDN)
* Issued by also shows "sukak" in my case since the test was done using self issued certificate created using selfSSL.exe

'**************************************************
'* CertExpiryCheck.vbs
'* Enumerate certificates with day left for expiry 
'**************************************************

Option Explicit
Dim SubjectName
If WScript.Arguments.Count > 0 Then
    SubjectName = LCase(WScript.Arguments(0))
Else
    CommandUsage
End If

Dim Store, Certificates, Certificate
Const CAPICOM_LOCAL_MACHINE_STORE = 1
Const CAPICOM_CERTIFICATE_FIND_SUBJECT_NAME = 1        
Const CAPICOM_STORE_OPEN_READ_ONLY = 0

Set Store = CreateObject("CAPICOM.Store")
Store.Open CAPICOM_LOCAL_MACHINE_STORE, "MY" ,CAPICOM_STORE_OPEN_READ_ONLY
Set Certificates = Store.Certificates.Find(CAPICOM_CERTIFICATE_FIND_SUBJECT_NAME, SubjectName, 0)

If Certificates.Count >0 Then
   For Each Certificate in Certificates
    'Certificate.display()    'If you want to see the Cert in UI
    WScript.Echo "*** Subject " & Certificate.SubjectName & " ***"
    WScript.Echo "Issued by " & Certificate.IssuerName 
    WScript.Echo "Valid from " & Certificate.ValidFromDate & " to " & Certificate.ValidToDate 
    WScript.Echo "Days to expiry " & DateDiff("d",now(),Certificate.ValidToDate)
    WScript.Echo 
   Next
 Else
  WScript.Echo "No certificates with SubjectName => '" & SubjectName & "'"
End If

Set Certificates = Nothing
Set Store = Nothing

Sub CommandUsage
  MsgBox "Usage: CertExpiryCheck.vbs  [SubjectName] ", vbInformation,"CertExpiryCheck"
  WScript.Quit(1)
End Sub

Just keep in mind you need capicom.dll to use this script. This comes default on Windows 2003 (I guess) but might need to be downloaded and registered on other platforms like Vista. Use regsvr32 capicom.dll to register it first before using the script.

Evolution of HTTP on Windows Platform

sukeshak — Wed, 17 May 2006 09:43:00 GMT

Before the boom of web and internet, HTTP was not so common is everyday life. When internet became more and more widely used, HTTP also grew in usage.

Basic web server serves static HTML type contents and then was the era in which there came several ways to extend the web server and its features. Because of the popularity of the web, on internet most of the companies connected to the web have port 80 (which is the default HTTP port) open on firewalls. Which simply means that to use HTTP most of the companies didn’t have restrictions and thereby became the default and uninterrupted way of global communication?

HTTP on Windows platform was initially used only by IIS for serving web sites. Gradually because of the simplicity and availability (of open port 80) of HTTP several other applications started using HTTP as a medium of transport. Then came the wave of all HTTP based protocols and having another protocol tunnel through HTTP.

RPC over HTTP (I would call it as “RPC through HTTP” rather) for Exchange and SQL to name a few. SQL started supporting HTTP so that you can expose a database over the web using HTTP and SQL queries can be executed using query string and the results returned as XML. Once, more and more application platforms started using HTTP, it became important that we have a uniform & consistent way on Windows platform to use HTTP protocol. So the kernel mode driver called HTTP.SYS was born. Since it’s a kernel mode driver, it gives us a lot of advantages (mainly on 64bit machines with a huge amount of memory for kernel mode caching and getting higher performance) and creates a layer which gives a consistent way of utilizing HTTP protocol. HTTP.SYS also provides API’s if we need to use HTTP protocol directly and bypass IIS. This route would obviously lack other features provided by IIS like health monitoring, easy management etc… but can be utilized for specific needs.

Next big leap – IIS7

Before we look at some of those upcoming features in IIS7, let us see what we lack till the current version of IIS i.e. IIS6.

· Delegation of administration (very important for website hosting and also for hosting department websites with its own admin)

· Extensibility (A thorough understanding of IIS is required in order to write high performance ISAPI Filters or Extensions)

· You can add features but not replace features

· Managing IIS was not possible when it comes to higher number of websites simply because the MMC style of interface is not efficient.

· Even if you use ASP.NET (handlers or modules) it works at a lower level than ISAPI Filters/Extensions.

· Debugging or tracing (A fair amount of tracing features were introduced in IIS6 and more with SP1 but still we resort to post-mortem dumps for 60% of our cases)

· XCopy deployment of websites.

Now “few” of the highlights from IIS7 features list

· Delegation of administration to granular level (like attribute level) and users can be either from Active Directory / SAM (workgroup) or custom database

· You have managed and unmanaged API's to access IIS or for admin purposes (e.g. showing a list of pages currently running and how much CPU each of them are taking). This is possible in IIS6 with SP1 (Windows 2003 SP1) but with extra tools, but in IIS7 it’s available inside the MMC itself.

· You can search or book mark a website when you have too many sites, for easy administration.

· Now with the new Integrated Pipeline, you can write managed or unmanaged ISAPI

· A lot of tracing functionalities are included e.g. Failed Request Tracing etc... Even specifics like “only requests failed with authentication” etc...

· Since website related details (like default page etc...) are stored inside web.config (not necessarily ASP.NET application) you can deploy sites using XCopy and it simply works.

· You can enable admin service with a different secure port which can be used for administering IIS remotely (http). This is not an admin website like before but a separate service.

· You can replace existing IIS components by replacing the dll name in the application.config file. Example custom logging, custom authentication. This simply means that everything is pluggable and only required features are installed or loaded into the process. For example you don't want "Basic Authentication" you don't even install it. This would reduce attack surface and enables better performance also.

· My favorite feature, you can enable forms authentication with a single page (uses .NET 2.0) for htm / asp / asp.net / php / cgi / images or any application web site.

You can see some managed code snippets of IIS7 Admin API’s from the following link

http://blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx

Make sure you see the piece of code titled “Getting list of executing requests” which is my favorite.

Coming up - Screenshots of IIS7 Administration Interface J

Back to Basics - HTTP/IIS (Part II)

sukeshak — Wed, 17 May 2006 09:33:00 GMT

Let us see how HTTP is extended to do more than serving static content.

When we talk about Windows Platform & HTTP, Microsoft product which comes to the picture is IIS. In the early days (and early versions of IIS) HTTP was primarily used for hosting websites and to enable people to use browsers to request those websites. So in essence IIS (or for that matter any web server) is built to serve “static” HTML pages with resources like images (referring to IIS2). But later versions of IIS provided ways to extend the web server in order to provide dynamically serving websites. In IIS world we call it as ISAPI Extensions. Hmmm... So what is ISAPI Filters then?

Let’s try to understand more about ISAPI Filters, ISAPI Extensions & Wildcard ISAPI Extensions to get more clarity.

ISAPI Filters

From the name itself you know that it’s something to do with filtering. Yea you got it right! So IIS exposes a set of notifications (IIS term for events) so that we can develop an ISAPI Filter (dll with a difference) to register for these notifications. When IIS triggers these notifications your ISAPI Filter DLL gets a chance to handle the data available for that specific notification.

Confused? Huh! Let me try with a hypothetical example then,

Assume that you have an ASP application and you don’t want your web users to know that it’s really ASP. So what can you do? Let them request .ASPX pages and we will change the extension to .ASP before IIS gets it for further processing. Good Idea?

Change all your links in the site to point to .ASPX extension. And when web users request “default.aspx” the ISAPI Filter would change the file requested to “default.asp” without the user’s knowledge and show off that you are running an ASP.NET application but under the hood it’s a legacy ASP application. J

How does this work or how is this implemented?

Like I mentioned before you need to use one of those ISAPI Filter notification called SF_NOTIFY_PREPROC (search on MSDN for more information). So what does that give us? When a request enters IIS and when IIS reads in the HTTP request header our ISAPI Filter gets a chance to access HTTP request header and if required we can modify it. So in our scenario, we would see that URL field in the header contains “default.aspx”. Yes you guessed it, we would change that URL to “default.asp” and let IIS know that it needs further processing. Cool deal hah!

Important piece of code from the ISAPI source provided below to show how easy it is

Char buffer[256];

DWORD buffSize = sizeof(buffer);

BOOL bHeader = pHeaderInfo->GetHeader(pCtxt->m_pFC,"url",buffer,&buffSize);

CString urlString(buffer);

urlString.MakeLower();

if (urlString.Find(".aspx”) != -1) //we want to change this file’s extension

{

urlString.Replace(".aspx",".asp");

char *newUrlString= urlString.GetBuffer(urlString.GetLength());

pHeaderInfo->SetHeader(pCtxt->m_pFC, "url", newUrlString);

//we’re done, now give it to IIS for further processing

return SF_STATUS_REQ_HANDLED_NOTIFICATION;

}

ISAPI Extensions

So like I mentioned before a web server serves static pages, the dynamic features like ASP, ASP.NET, PHP etc happens because of ISAPI extensions. So the obvious is that ISAPI Extensions are a way to extend the Web Server to add more features to it.

So once the requests surpass the ISAPI Filter and if the request is not for static page, IIS searches for an ISAPI extension which is mapped to the request file extension. If found the request is forwarded to that ISAPI Extension for further processing and returning a valid response back to the client.

Wildcard ISAPI Extensions (IIS6 specific)

Here we will talk about why we need this piece and what are we trying to achieve here. Yes you guessed it, Wildcard extensions comes in between ISAPI Filters & ISAPI Extensions, so that it can have the features of both ISAPI Filters & Extensions.

Request

IIS [ ISAPI Filter -> Wildcard Extension -> ISAPI Extension]

Response

Before getting into details lets see the Pros & Cons of ISAPI Filters & ISAPI Extensions.

ISAPI Filters

Pros of ISAPI Filters

Every request can be intercepted regardless of the file extension
Filter notification allows us to enhance or replace some of the IIS features
1. Custom Redirection or request filtering - SF_NOTIFY_PREPROC_HEADERS
2. Custom Authentication – SF_NOTIFY_AUTHENTICATION
3. Modify IIS log values – SF_NOTIFY_LOG
  etc… (notification list documented on MSDN)

Cons of ISAPI Filters

No Asynchronous support
Uses IIS thread pool and cannot implement its own thread pool, so whatever processing of request is being done inside the filter should be completed quickly, otherwise chances are that IIS runs out of worker threads and users starts seeing errors like “Server too busy” or IIS gets into a hung state without responding to requests.
No access to entity body (huh! its another term for HTTP request body)

ISAPI Extensions

Pros of ISAPI Extensions

Gets the entire entity body (HTTP request body)
Can implement custom thread pool
Processing the request can be asynchronous

Cons of ISAPI Extensions

Can handle only requests to specific extensions (because its mapped to specific file extension.
Processing happens only after getting the complete request entity body.

Wildcard ISAPI Extensions

Pros of ISAPI Wildcard Extensions (hybrid of Filter & Extension)

Every request can be intercepted regardless of the file extension

ISAPI Filters: Yes
ISAPI Extensions: No

Implement custom thread pool

ISAPI Filters: No
ISAPI Extensions: Yes

Asynchronous Processing

ISAPI Filters: No
ISAPI Extensions: Yes

Handle entire request processing and return response to the client or hand over to an ISAPI Extension (according to the extension) for further processing.

ISAPI Filters: Yes
ISAPI Extensions: Yes

Can get access to complete request entity body

ISAPI Filters: No
ISAPI Extensions: Yes

So from the above list you can see that Wildcard ISAPI Extension provides a way to get best of both worlds (ISAPI Filter & ISAPI Extension).

Back to Basics - HTTP (Part I)

sukeshak — Sat, 06 May 2006 13:49:00 GMT

Most of my interactions in the past with customers, web developers and some of my prior colleagues, I have found that a larger percentage of them don't have a good understanding of how HTTP protocol works. This could be due to various reasons; some of them could be like

Coming from windows application development background.
Not getting enough time to go through the details due to project deadlines.
Too difficult to get the meat out of HTTP RFC document because it’s too much to read.

This results in lot of confusions and also leads to low performance application development. So I thought I would help the readers of putting those confusions to rest and explain all these in simple and effective way. So, in essence this article is no rocket science, but HTTP basics which most of those HTTP/IIS experts left out thinking that it would not be necessary to be explained (Or maybe its there but I missed noticing it).

Is HTTP a popular protocol, Oh really?

The popularity of HTTP protocol is simply because it's a simple protocol when you try to understand it from grass root level. Because of the simplicity (huh, I think due to recent developments people have made it a little complex) HTTP is used extensively not just for serving HTML pages but in order to empower several applications to make it work on the web.

How does a simple HTTP response look like?

#include <iostream.h>

#include <windows.h>

int main (int argc, char** argv,char **envp)

{

cout << "Content-Type: text/html\r\n\r\n"; //Header

cout << "<h2>Hello World!</h2>" <<endl; //Body

return 1;

}

How does HTTP works with authenticated request?

Browser send GET request to IIS (remember 1^st request is always anonymous)
IIS returns 401 and provides WWW-Authenticate Header with the supported authentication methods
According to authentication method Browser pop-up the dialog to enter credentials and then submits to IIS
Credentials gets validated and if valid, your GET request is served with HTTP Status 200 (200 = success)

Why do we need sessions in HTTP?

Since HTTP is a connection-less protocol we need to provide a way to continue request-response process without having to create a ‘fresh’ newer connection for every request.