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.