Corporate.Net Securing Intranet Data With SSL Client Certificates Apache was not quite as easy, requiring us to manually edit a Unix-style text file. Basic authentication information resides in that text file, and the user name and password are replaced by certificate information. For each user you must configure, you will need to collect a fair amount of information from their certificate, including common name and certificate authority. You will have to manually enter the information into the text file. In IIS 3.0, Microsoft has not included any tools for managing client certificates. But with its Active Server Pages scripting architecture, it has exposed the conte nts of the client certificates. So if you are adventurous, you can write scripts to manipulate the certificate data. If you are doing a lot of custom development, such as including database access, this may work out well for you. With some better certificate management tools, the doors would be open t o very easy access control lists. In addition, users would not have to enter a password. Browsers, such as Netscape Navigator, can be configured to automatically present a default certificate, thereby authenticating to your intranet server. Robert J. Kohlhepp can be reached at rkohlhepp@nwc.com.
	Where Do I Get These Certificates? Client (as well as server) certificates are generated by a certificate issuing server (called certificate server by both Microsoft and Netscape). For Internet commerce, you should get a certificate from a certificate authority, such as V eriSign. But for intranet purposes, you can purchase a certificate-issuing system for your network from vendors such as Xcert, Netscape and Microsoft. Certificate issuing systems encapsulate a variety of information, such as name and e-mail address, into a certificate and sign it with the certificate server's private key. You must distribute your certificate server's public key to all of your Web servers for the new client certificates to work. Web servers can use the certificate server's public key to ensure that the client certificates presented are authentic. Most Web servers ship, by default, with public keys for commercial certificate issuers, such as VeriSign and AT&T. So, besides the certificate server's signature, how do you know if a certificate is still valid? Certificates are issued with an expiration date and must be renewed. What if an employee leaves your company and you need to revoke privileges for his or her certificate? On Novell IntranetWare, if you disable a user's Novell Di rectory Services (NDS) account, he or she loses access to all NDS resources. Currently, there are only proprietary means to actually check for revoked certificates. If you are meticulous, you will know every server that accepts your users' certificates and will disable that particular user on all servers. All certificate ser vers have a method for revoking certificates. But Web servers don't have the means to check every certificate for currency. The industry needs to work on a suitable application programming interface (API) for querying certificate servers about the status of certificates.

Internet RX by Chris Lewis Updated June 27, 1997