
Corporate.Net
Securing Intranet Data With SSL Client Certificates
Of course, the different keying schemes are completely dependent on the capabilities of both the client and the server. In the case of Netscape Navigator, you can specify which algorithms and key sizes you will accept. If you don't want to use short (40-bit keys) sizes, deselect that method in the security options. However, other browsers like MSIE do not let you configure these options and do not warn you when the link is only "marginally secure."
For servers that also support client authentication, the server will ask the client for a certificate. The client must pass an identification certificate (which is usually in X.509 format) to the server. The certificate contains information to identify the client--including the client's public key--and is signed by a recognized certificate authority. Thi
s certificate can be used for many types of identification and authentication. For intranets, a programmer could extract the user name and pass that to
a database server to access sensitive data.
What Can I Do With Client Certificates?
Client certificates have been seen as a method of authenticating users in an Internet commerce scenario. To this end, we worked with VeriSign for certificates for our servers. For internal intranet certificates, we used Xcert Software's public certificate server.
During testing, we worked with client and server certificates from both VeriSign and Xcert. Netscape and Microsoft now offer servers that can issue certificates for intranet use. In our testing, we saw flawless interoperability among the certificates issued by different parties. On the browser side, we found that Netscape Navigator worked well with certificate-issuing systems, but MSIE was not able to obtain a client certificate from the Xcert system.
Client certificates offer a more secure method o
f authenticating the user than traditional user name and password solutions. In an environment with very sensitive data, client certificates ensure that data is not delivered to the wrong party. Corporate intranet solutions with human resources information are a perfect example of sensitive data that must be read only by authorized parties.
Not only can certificates verify that the user is allowed to access that server, but specific data within the certificate can be used to determine user rights. Within the certificate, the user's common name is distinct and can be used to authenticate against many other data sources. In our testing, we configured Enterprise Server and Stronghold to accept client certificates in lieu of basic authentication. Basic authentication is the user name or password authentication that is built into almost every Web server. So, instead of using insecure, clear text authentication, we authenticated with client certificates.
Netscape Navigator 3.x (and beta versions of 4.0) and M
icrosoft Internet Explorer 3.02 can both make use of client-side certificates. Through proprietary protocols, Netscape Navigator and Microsoft IE can download
and install a client certificate over the Internet. We installed client certificates from VeriSign using this method. With an intranet certificate server, users can install their own certificates after properly authenticating themselves. MSIE worked well with any VeriSign certificate and would talk to a server that presented an Xcert certificate. But methods for installing client certificates issued by Xcert's server are still in development.
Management Comes Up Short
However, because client certificates are fairly new, there is little support for uses other than basic authentication. Server vendors should start to support tools that manage the certificates and their respective properties--doing things like listing all of the certificates the server had seen. With that list, the administrator could delegate and revoke rights for the users r
epresented by the certificates.
There is very little flexibility in managing certificates. Enterprise Server and IIS can be configured to require certificates on a directory-by-directory basis; Apache can only be configured to require client certificates for the server as a whole. However, since Apache, like Enterprise Server, lets certificates be mapped to basic authentication, directories and files can be secured based on the content of the certificate. IIS can't restrict access based on certificate information; if you have a valid certificate, then you can see any data on the server.
To configure authentication based on client certificates, Enterprise Server offers a simpler approach. First, we configured our server to restrict access to directories based on basic authentication. Then, we required that a client certificate be presented for those directories. The first time we accessed one of those directories, we were prompted for both a certificate and basic authentication. Enterprise Server automat
ically linked those pieces of information. Successive accesses required only a certificate.
|