Corporate.Net Securing Intranet Data With SSL Client Certificates By Robert J. Kohlhepp   Web servers have become a dime-store commodity. Besides hype and platform support, what sets them apart? Paramount for most vendors is the addition of features like Secure Sockets Layer (SSL) and client-side certificates that improve security and connectivity to data sources. When it comes to security, most of us think of the consumer concerns of passing credit and payment information over the Internet. But there are just as many security issues to tackle on a corporate intranet. The addition o f the SSL protocol and client authentication via certificates can help secure your sensitive corporate information. To evaluate the status of client-side certificates and how intranet developers can implement them as an alternate form of authentication, w e tested Microsoft Corp. Internet Information Server (IIS) 3.0 and Netscape Communications Corp. Enterprise Server 2.0b Web servers, which provide support for SSL 3.0 and client-side certificates. C2Net's Stronghold server, based on Apache, joined the fray with an SSL 2.0-based server that supports client-side certificates. Although SSL 2.0 offers minimal support for client-side certificates, SSL 3.0 adds a thorough definition of client certificate requirements. With the standard completed more than a year ago, the number of servers supporting SSL 3.0 is still quite disappointing. For SSL browsers, we used Microsoft Internet Explorer 3.02 (MSIE) and Netscape Navigator 3.01. Overall, we have mixed feelings about the current implementation of client-side certificates in products. Basic support for certificates in SSL works as expected. However, management of the certificates in both servers and clients needs a lot of work. From our perspective, the only solution for the client is Netscape Navigator, which gives you full control of the certificates on your client. On the server side, all products are lacking in some way, but each gives you control over different aspects of the authentication process. Don't expect a turnkey solution in any environment. How SSL Certificates Work Data encryption using the SSL protocol doesn't happen simply. There is a complex process that occurs between the client and the server to determine the parameters in an encrypted session. In addition, during that handshake, the server and the client authenticate themselves via signed certificates. (The client authentication is optional.) In the simplest case, a client contacts an SSL-enabled server via the server's secure port (usually 443), and the server presents a certificate signed by an authority that is recognized by the client. For Internet commerce servers, a trusted certificate authority (CA), such as VeriSign, usually signs the certificate. With intranets, a locally trusted certificate server is installed on your local network. Once the certificate is received from the server, the client determines whether the certificate is valid. For example, let's say the server's certificate is signed by VeriSign. The "signature" is calculated data, derived from the certificate data and the signer's (VeriSign's) private key. Using a copy of the signer's public key, the client can determine whether the certificate is authentic (see "CAs: How Valuable Are They?," April 1, page 54, or techweb.cmp. com/nc/806/806f1.html). After the client is certain that the server is not spoofing its identity, the server and client exchange the shared keys that will be used to encrypt, decrypt and sign the data during communication. With SSL 3.0, signatures can use different keys than the encryption engine. To comply with export regulations, you can use weak encryption keys, but retain larger, more secure signature keys. SSL 2.0 required one key be used for encrypting and signing.

Where Do I Get These Certificates? Internet RX by Chris Lewis Updated June 27, 1997