DIY Certificates

Take a look at the Security Settings tab (or Content tab in Internet Explorer 4) in your browser and you'll find sections for site and personal certificates. These refer to digital certificates, which allow you and a remote Web server to positively identify each other.

Let's take site certificates first. Your browser doesn't actually have any site certificates installed, but it contains a list of certifying authorities (in other words, digital certificate issuers) that you currently trust. You'll find that Netscape, Microsoft or whoever will have already installed a few of these for you by default, which will probably include GTE, VeriSign, ATT and RSA.

These site certificates come into play whenever you access a secure server - typically Web sites with addresses that start https:// rather than the usual http://. These sites connect to their server software via port 443 instead of the usual 80, and cause everything transmitted between browser and server (and vice versa) to be encrypted. This encryption will generally be 40-bit for users outside the US, due to US export restrictions.

So you arrive at the on-line version of your favourite supermarket and decide to do the week's shopping. You've got it all stacked up in your virtual trolley and proceed to join the virtual queue at the virtual checkout. At some point you'll be asked for a credit card number, and most people will see a little padlock or key icon appear in their browser status bar and assume that everything is secure. It's secure inasmuch as your communication with this server is being encrypted, but can you be absolutely certain that it really is Sainscos or Tescburys that you're talking to at the other end of the connection? Remember those stories in the press about fake hole-in-the-wall cash machines? Well, it's far easier to build a fake Web site than it is to make a fake ATM, and so this is where those site certificates come into play.

Sainscos will have gone to one of the major certifying bodies such as VeriSign (www.verisign.com) and obtained a site certificate for its site, and VeriSign will have made Sainscos prove its identity before issuing that certificate. Now, because you have VeriSign listed as a trusted certifying body, your browser will allow you to connect to the site with a minimum of warning dialogs.

Things to watch out for are:

1. messages warning that the site certificate doesn't match the site name; and
2. warnings that the site certificate was issued by an unknown authority.

In either of these cases you should proceed with extreme caution. If you're ever suspicious about the identity of a secure site you can (and should) always view its certificate information from within your browser.

So what about personal certificates? Just as site certificates are used to positively identify Web sites to visitors, personal certificates are used to identify visitors to servers, which might be important in scenarios such as on-line banking or intranets.

While personal certificates can be obtained from the same certification bodies (for example, VeriSign) that issue site certificates, for intranets and other closed user groups it may be more secure and cost-effective to run your own in-house certification authority; that is, to issue your own certificates. You might assign the task of issuing (and revoking) these certificates to the human resources department, as it probably already issues other forms of security passes.

However, until such time as your company is ready to start issuing certificates internally, there's still a lot you can do with those issued by external authorities. For example, for $10 per annum VeriSign will issue your users with a 'Type 1' Browser ID. This works as follows:

• Each user goes to VeriSign's site and types in their details, including their email address
• VeriSign sends an email to each user, giving them a special URL and a code word
• The user goes to that URL, copies the code word into it, and a certificate is then installed into their browser.

You can now interrogate that certificate with code from within your intranet. Part of the information stored within it is the email address that was used for the above transaction, which means your security code can easily check that any user of your intranet has a digital certificate, issued by a certain body, which was delivered to one of your corporate email addresses. You might also check to see that the email address used matches the logon name to access the site.

Once you're ready to become a certificate authority (CA) and start issuing certificates in-house, you'll need to find some appropriate software. If you're a NT/IIS user, you'll probably want to use Microsoft's Certificate Server which comes as part of the NT 4 Option Pack. There are a number of alternative products, though; many produced by the certifying authorities themselves (see www.verisign.com/products/corporate/ index.html, for one example).

We'll concentrate on Certificate Server (CS) here. Note that CS is useful for other things besides Web sites. It can, for example, be used to secure Exchange Mail and RPC, but such things are beyond our remit here.

For Web sites and intranets, you can use CS to create both the personal certificates used by the site's visitors and the server certificate used by the site itself. This keeps everything in-house and gives you total control over security (so, if anyone breaks in it will be your fault). First, though, before your browsers will recognise the site's certificate as authentic you'll have to register your organisation as a recognised CA, and CS provides a nice user-friendly mechanism for doing this - just point your browser at http://yourserver/CertSrv. With a few clicks you'll soon have your company registered as an authorised CA for the Web browser you use.

The next step is to get CS to issue a signed certificate for your server. First you'll need to inform the server that it can trust certificates from your new CA. With IIS 3 this is simply a matter of installing the CA certificate into IE, because IE and IIS 3 share the same certificate information. With IIS 4 you'll need to go through the extra step of opening a command prompt, and typing:

CD \winnt\system32\InetSrv
(or wherever it is on your machine)
IISCA

which will then map the IE certificate roots into IIS 4.

Once you've done this you'll need to generate, sign and install a certificate for the Web server, which you accomplish by using the IIS Key Manager to generate a certificate request for you. Send this request to your internal CA to be authenticated, and the CA will send you back a certificate. Then you use the Key Manager to bind that into your IIS setup. If you're using IIS 4 and running CS on the same server, life gets a bit easier because the Key Manager can talk directly to CS and will automate the process completely.

CS does have some annoying features. It won't install onto a BDC (backup domain controller), but works fine on a Primary DC and on a Workstation. Also, if you install CS onto a machine which is running IIS you must shut down IIS during the installation. Forget to do this and CS will make a dog's dinner out of your ODBC drivers.