Because Microsoft Exchange Server 2010 resides on
Microsoft Windows Server 2003 or Windows Server 2008, administrators can
rely heavily on the technology of the underlying operating system in
their effort to implement a secure messaging environment.
Microsoft Windows
Server 2003 and Windows Server 2008 allow for the use of PKI, which
enables an administrator to exchange information with strong security
and easy administration across both internal and external networks. PKI
is an extensible infrastructure used to provide certificate-based
services by combining digital certificates, registration authorities,
and certificate authorities that can be used to provide authentication,
authorization, nonrepudiation, confidentiality, and verification. A
certificate authority (CA) is a digital signature of the certificate
issuer.
PKI implementations
are widespread and are becoming a critical component of modern networks.
Windows Server 2003 and Windows Server 2008 fully support the
deployment of various PKI configurations, ranging from very simplistic
to extremely complex. Entire books have been written on the subject of
implementing PKI, but this article endeavors to give administrators a
basic understanding of the subject and show how PKI can be used to help
secure your Exchange Server environment.
Certificate
Services in Windows Server 2003 or 2008
Windows Server 2003 and
Windows Server 2008 include a built-in CA known as Certificate Services.
Certificate Services can be used to create certificates and
subsequently manage them and is responsible for ensuring their validity.
Certificate Services can also be used to trust external PKIs, such as a
third-party PKI, to expand services and secure communication with other
organizations.
The type of CA that you
install and configure depends on the purpose or purposes of the Windows
Server PKI. Certificate Services for Windows Server 2003 or the Active
Directory Certificate Services (AD CS) role in Windows Server 2008 can
be installed as one of the following CA types:
Enterprise
root CA— The enterprise root CA is the most
trusted CA in an organization and, if utilized, should be installed
before any other CA. All other CAs are subordinate to an enterprise root
CA. Enterprise root CAs store certificates in Active Directory (AD) by
default.
Enterprise
subordinate CA— An enterprise subordinate CA
must get a CA certificate from an enterprise root CA and can then issue
certificates to all users and computers in the enterprise. These types
of CAs are often used for load balancing of an enterprise root CA. More
important, using subordinates provides stronger security for the PKI.
Stand-alone root CA— A stand-alone root CA is the root of a hierarchy
that is not related to the enterprise domain information, and,
therefore, certificates are not stored in AD. Multiple stand-alone CAs
can be established for particular purposes.
Stand-alone subordinate CA—
A stand-alone
subordinate CA receives its certificate from a stand-alone root CA and
can then be used to distribute certificates to users and computers
associated with that stand-alone CA.
A Windows Server PKI
can also be either online or offline based on the level of security
that is required in the organization.
Tip
An enterprise root
CA is the most versatile CA in Windows Server 2003 and Windows Server
2008 because it integrates tightly with AD and offers more certificate
services. All domain members trust the enterprise CA, and the enterprise
CA can be used for autoenrollment of certificates to domain member. If
you’re unsure as to what CA to use, choose an enterprise root or
subordinate CA for use with messaging. Most important, however, is that
with any PKI there must be careful planning and design.
PKI Planning
Considerations
Any PKI
implementation requires thorough planning and design, as noted earlier.
Possible planning and design considerations include the following:
Multinational
legal considerations, including creation and standardization of a
formal Certificate Practice Statement (CPS)
Policies and procedures for
issuing, revoking, and suspending certificates
PKI hardware
identification and standardization, including employee badge integration
Determination of CA hierarchy administration model
Creation of a
redundant CA infrastructure based on geographical location
Policies and procedures for
creation of CAs as subordinates and policy enforcers within a greater
hierarchy, including qualified subordination and cross-certification
Policies and procedures for
creation of registration authorities (RAs) and their placement within
the CA hierarchy
CA trust strategies
Policies and procedures
for maintaining the CA as a 24x7x365 operation (24 hours a day, 7 days a
week, 365 days a year)
Policies
and procedures for key and certificate management, including, but not
limited to, key length, cryptographic algorithms, certificate lifetime,
certificate renewal, storage requirements, and more
Policies and procedures for
securing the PKI
Published
plans for providing high availability and recoverability
Policies and procedures
for integrating the CA with Lightweight Directory Access Protocol (LDAP)
and/or Active Directory
Policies and
procedures for integrating with existing applications
Policies and procedures for
security-related incidents (for example, bulk revocation of
certificates)
Policies and procedures for
delegation of administrative tasks
Standards
for PKI auditing and reporting
Policies
and procedures for change control
Standards
for key length and expiration of certificates
Policies and procedures for handling lost certificates
(that is, smart card)
Policies
and procedures for safe distribution of the CA public key to end users
Policies and procedures for
enrollment (for example, autoenrollment, stations, and so forth)
Policies and procedures
for incorporating external users and companies
Procedures for using certificate templates
As you can see from this
list, implementing PKI is not to be taken lightly. Even if the
organization is implementing PKI just for enhanced Exchange Server 2010
messaging functionality, the considerations should be planned and
designed.
Fundamentals of
Private and Public Keys
Encryption
techniques can primarily be classified as either symmetrical or
asymmetrical. Symmetrical encryption requires that each party in an
encryption scheme hold a copy of a private key that is used to encrypt
and decrypt information sent between the two parties. One shortcoming of
the private key encryption method is that the private key must somehow
be transmitted from one party to the other, without it being intercepted
and used to decrypt the information.
Asymmetrical
encryption uses a combination of two keys that are mathematically
related to each other. The first key, known as the private key, is kept
closely guarded and is used to encrypt the information. The second key,
known as the public key, can be used to decrypt the information. The
integrity of the public key is ensured through certificates. The
asymmetric approach to encryption ensures that the private key does not
fall into the wrong hands and only the intended recipient is able to
decrypt the data.
Understanding
Certificates
A certificate is
essentially a digital document issued by a trusted central authority
that is used by the authority to validate a user’s identity. Central,
trusted authorities such as VeriSign are widely used on the Internet to
ensure that software that is being downloaded from Microsoft, for
example, is actually originating from Microsoft, and is not in fact a
virus in disguise.
Certificates
can be used for multiple functions including, but not limited to, the
following:
Certificates are
signed using information from the subject’s public key and the CA. Items
such as the originator’s name, email address, and others can be used.
Certificate
Templates
Certificates have
multiple functions, and, therefore, multiple types of certificates are
available to meet the need. One certificate might be used to sign code,
whereas another is used to provide support for secure email. In this
one-to-one relationship, a certificate is used for a single purpose.
Certificates can also have a one-to-many relationship in which one
certificate is used for multiple purposes.
Tip
One of the best
examples of a certificate that uses a one-to-many relationship is the
user certificate. By default, a user certificate provides support for
user authentication, secure email, and the Encrypting File System (EFS).
Windows Server 2003 and
Windows Server 2008 contain a large number of certificates, each with an
assigned set of settings and purposes. In essence, certificates can be
categorized into six different functional areas:
Server
authentication— These certificates are used
to authenticate servers to clients and servers to other servers. These
are the type used by Exchange Server 2010 servers.
Client authentication— These certificates are used to provide client
authentication to servers or server-side services.
Secure email— Utilizing these certificates, users can
digitally sign and encrypt email messages. These are the type used by
Outlook clients.
Encrypting File
System— These certificates are used to
encrypt and decrypt files using EFS.
File recovery—
These certificates are used for recovering encrypted EFS files.
Code signing— These certificates can sign content and
applications. Code signing certificates help users and services verify
the validity of code.
