Build a scalable Public Key Infrastructure

For authentication within your organization, you may want to set up your own private PKI. Here are some options for doing so.

Authentication of a user's identity is critical to computer security, whether the issue is accessing resources within a LAN or conducting e-commerce transactions over the Internet. There are a number of different authentication methods that can be used, but one of the most secure ways to do it is via digital certificates that are issued by a trusted third party called a certification authority, based on a public/private key pair. The system of certification authorities, certificates, keys and related components is called a public key infrastructure or PKI.

There are several public PKIs, such as those run by Verisign and Thawte, that can be used for Internet transactions. However, for authentication within your organization, you may want to set up your own private PKI. This gives you more control over the issuance of certificates. Some common uses of digital certificates within the LAN include smart card authentication and file encryption.

Options for creating an internal PKI

The simplest PKI is based on a single certification authority (CA). The CA is a server running certificate services software. For example:

  • Microsoft's Windows 2000 server and Windows Server 2003 (except Web edition) can be configured as CAs for your internal PKI. Certificate services is not installed by default, but can be added through the Add/Remove Programs applet in Control Panel as a Windows component. For more information, see Windows 2000 Certificate Services and Public Key Infrastructure for Windows Server 2003.
  • Netscape Certificate Server is part of their SuiteSpot Professional Edition, and can be used to create, sign and manage certificates for your PKI. It works with Lightweight Directory Access Protocol (LDAP) directory services and features Web-based installation and operation. For more information, see Netscape Certificate Server.
  • Novell Certificate Server is a free product that integrates with Novell eDirectory.
  • OpenCA is an open source Certification Authority program that runs on Linux and can be downloaded from SourceForge.

A CA issues certificates that certify that a user or computer is, in fact, whom he/she/it represents him/her/itself to be. The CA also maintains a list of certificates that have been revoked or have expired, and makes this list (called the Certificate Revocation List or CRL) available to those servers and applications that rely on certificates to verify the identity of users and computers.

Planning the PKI with scalability in mind

Larger organizations that use digital certificates for many different purposes, such as logon authentication, e-mail security, digitally signing documents, file encryption, etc. will need more than one CA. In this case, the PKI can be designed in a hierarchical structure, so that there is a top level or root CA that acts as the "master" CA and authenticates other, subordinate CAs. These subordinate CAs actually issue certificates to end users (users and computers).

If you're using Windows certificate services for your CA, you'll have the choice of installing certificate services in either standalone or enterprise mode. The main difference is not, as you might think, the size of the organization. Rather, an enterprise CA integrates with Microsoft's Active Directory, and requires that the users who request certificates have accounts in Active Directory. A standalone CA can be used to issue certificates to users or computers that are outside the Windows domain.

You can have multiple root CAs with multiple hierarchies within an organization, and you can have both enterprise and standalone CAs functioning in a hierarchy.

This makes certificate services particularly scalable. You can start with a single, standalone CA if your organization hasn't implemented Active Directory. You can later create a root enterprise CA and a hierarchy of CAs as the organization grows, while retaining the standalone CAs for issuance of certificates to users and computers that aren't members of the domain.

PKI design considerations

Security is a high priority in almost all organizations today, and the security of your root CA is vital. One strategy is to use the root CA to issue certificates to the subordinates and then take the root CA offline. This means disconnecting it from the network and locking it up in a secure place. This is done because the root CA is the point of trust in the hierarchy; all other CAsderive their authority from the root.

For user convenience, you may want to install Web services and provide the ability for users to request certificates via their Web browsers.

For scalability, you'll need to ensure that the server(s) on which you install certificate services have hardware that's capable of handling the processing load, based on the number and frequency of certificates to be issued, frequency of certificate revocation, etc.

Your PKI should be based on common standards, i.e. X.509 public key certificates. This standard defines a format for digital certificates as well as the process for distribution of public keys by the CAs. A standards-based system is more scalable and easier to integrate with other CAs (for example, public CAs).

As your organization grows, fault tolerance becomes a more and more important consideration. If your CAsare unavailable, functions that require a valid certificate will be disrupted. Part of your scalability plan includes planning for the possibility of a CA server going down. You can use methods such as disk fault tolerance (RAID) and server clustering to ensure continued availability.

Scalability of certificate revocation is also an important consideration. Issuance of a list of revoked certificates that is updated on a regular basis works in an environment where the volume of certificate issuance and revocation is low, but it doesn't scale well when that volume grows because reissuance of the CRLs slows performance and is inefficient. Look for support for Delta CRLs, which are lists that include only the changes made since the last CRL, rather than a republication of the entire CRL each time.

About Deb Shinder

Debra Littlejohn Shinder, MCSE, MVP is a technology consultant, trainer, and writer who has authored a number of books on computer operating systems, networking, and security. Deb is a tech editor, developmental editor, and contributor to over 20 add...

Editor's Picks

Free Newsletters, In your Inbox