CHAPTER
10
PLANNING A PUBLIC KEY INFRASTRUCTURE
A Public Key Infrastructure (PKI) is a combination of technologies, protocols, standards, and
services that allows an organization to provide strong authentication and encryption services on
the network.
Chapter Scenario:
Blue Yonder Airlines is a discount airline that serves the
West Coast of the
Internet.
upgraded to Silver. If they reach 60,000 miles, they are elevated to Gold.
computers connect by using L2TP/IPSec tunnels.
======================================================================
winsec10.html PAGE
2 2002/04/30
Lesson 1:
Planning a Certification Authority Hierarchy
The deployment of your PKI must include the following steps:
Determine whether a public CA or private CA meets your PKI needs.
Design a CA hierarchy that allows all clients to recognize and verify all issued certificates.
Whether or not to deploy
Plan security for the root CA of your CA hierarchy.
Plan a disaster recovery for the potential failure of a CA.
Reviewing PKI Components
Certificates. They can represent a user, computer or a network device.
Certificate templates. Single usage is (EFS Recovery) or multiple purpose (User or Computer).
Certificate Revocation List (CRL). Revoked before their revocation date.
Certification Authority (CA). A trusted entity or service that issues and manages digital
certificates.
Certificate management tools. MMC to allow management of the issued Certificates.
Certificate distribution point. A location where certificates or CRLs can be retrieved by
clients that participate in a PKI.
Public key-enabled applications and services. Examples of PKI-aware system services
include EFS, Smart Card Logon, and IPSec.
Determining Whether
to Use a Private or Public CA
In general, you must decide between a public CA (also known as a third-party CA) and a private
CA.
Choosing a Public CA
Public CAs are managed by third-party companies such as Entrust or Verisign. If you use a public
CA, the CA hierarchy is simplified because certificates are acquired from a common CA structure.
======================================================================
winsec10.html PAGE
3 2002/04/30
Choosing a Private CA
For many internal applications a private CA may be beneficial. Rather than waiting for a third-party
organization to revoke certificates, you’re immediately able to implement the revocation process
when you need to.
Should I Mix and Match Public and Private CAs?
The primary advantage of using a private CA is that your organization has much more control
over the management of issued certificates. It can revoke a compromised certificate quickly if
necessary.
Choosing between Public CAs and
Private CAs
======================================================================
Use a When
======================================================================
Public CA Your application requires verification from a trusted third party.
You don’t have and don’t want to allocate the resources to deploy
an internal PKI.
Time is limited. Public CAs already have the necessary infrastruc-
ture in place.
A project requires certificate interoperability between organizations.
Your application requires liability protection in case security is
breached for your certificate-based application.
Private CA Your organization wants to maintain management control of all
client-associated certificates.
The certificates will be used for internal projects, applications and
Services.
You want to minimize the costs associated with issuing certificates.
Your organization has PKI expertise that can manage and maintain
Certificate Services.
======================================================================
winsec10.html PAGE
4 2002/04/30
Determining the Certification Authority Structure
Rooted hierarchies are the most common CA structures. A rooted hierarchy has an initial CA,
known as a root CA.
The root CA is unique in that it issues itself a certificate. This certificate is also known as a
self-signed certificate.
Below the root CA are one or more subordinate CAs. The root CA issues certificates to the
subordinate CAs with the subject matching the name of the subordinate CA.
Additional levels of CAs might exist below a subordinate CA. These CAs are often referred to
an issuing CAs.
WARNING: There are far-reaching implications if a CA is compromised and the CAs certificate
must be revoked. Not only is the CAs certificate revoked, but all certificates issued by the CA –
including those issued by subordinate CAs that received their certificates from the compromised
CA are considered compromised and are invalidated. By removing the root CA from your network,
you can ensure that all certificates are protected from key compromise of the root CA.
Deploying a Cross-Certification Hierarchy
In a cross-certification hierarchy, a CA acts as both a root CA and a subordinate CA.
In this hierarchy the Corp CA is the root CA for the corporation. In addition to the self-signed
certificate signifying that the Corp CA is a root CA, the Corp CA also has a subordinate CA
certificate issued by the Partner CA. You may want to trust only certificates issued by a specific
CA located within a partner’s CA hierarchy.
A CTL is a group of CA certificates deemed trustworthy by a CA administrator.
======================================================================
winsec10.html PAGE
5 2002/04/30
Designing Certificate Hierarchies
======================================================================
To Do
the Following
======================================================================
Provide Maximum Deploy a rooted CA hierarchy. Only a rooted CA
Security for the root hierarchy allows the root CA to be removed from the
CA network.
Limit trusted CAs to your Deploy a rooted CA and remove all other CAs from
organization’s CAs the trusted root store.
Provide interoperability Deploy a cross-certification hierarchy where the root
between organizations CA from each organization is configured as a sub-
ordinate CA of the other organization.
Limit which CAs will Deploy a cross-certification hierarchy and
Be trusted from a partner configure a CTL that contains only the trusted
Organization CAs from the partner organization.
=======================================================================
*** Must be in the
root CA before installing a CA ****
Planning the Scope of a CA
You can install two scopes of CAs:
Deploying an
An enterprise CA must be a member of a Windows 2000
domain. Only members of the
Admins universal group can install
an
Some of the reasons to consider deploying an
Certificate templates. Enterprise CAs use certificate templates to restrict certificate usage.
NOTE: Only Enterprise CAs support the use of certificate. Standalone CAs don’t implement
certificate templates to define certificate usage restrictions.
Integration with Windows 2000 security.
======================================================================
winsec10.html PAGE
6 2002/04/30
Storage of data in Active Directory. Enterprise CAs use Active Directory to store the
Certificate Services database, thus enabling that the data is protected by Active Directory’s
multimaster replication model.
Some applications and services that require
Reduction in management for certificate issuance. Because the default issuance policy
for Enterprise CAs is to automatically issue certificates, a certificate administrator doesn’t
need to approve certificates requests.
Deploying a Standalone CA
Standalone CAs can be members of a domain or stand-alone servers in a workgroup. By default, the
certificate request is then reviewed by a certificate administrator who accepts or rejects the certificate
request in the Certification Authority console.
NOTE: The default behavior for a Standalone CA is to require the certificate administrator to issue
or deny certificate requests. You an configure the issuance policy to automatically issue certificates
for valid certificate requests to match the default behavior
of an
Consider deploying a Standalone CA when
You’re establishing an offline root CA. Offline root CAs, by default aren’t attached to the network.
You want to integrate Windows 2000 Certificate Services with an Exchange 5.5 Key Management
(KMS).
NOTE: X.509 is a standard for digital certificates defined by the International Telecommunications
Union-Telecommunications Standardization Sector.
You require a CA to run in the DMZ (Demilitarized Zone) where it can’t contact Active Directory.
You can mix and match CAs.
Planning Offline CAs
An important step in protecting your CA hierarchy is to remove the root CA, and potentially, a
second level of CAs from the network.
The design of an offline CA also must include the following considerations:
======================================================================
winsec10.html PAGE
7 2002/04/30
Storage location of the offline CA. For example in a vault that’s accessible only to authorized
personnel.
Use of a strong Cryptographic Service Provider (CSP). CSP are software module that actually
define how cryptography algorithms are used for authentication, encoding and encryption.
Publication of the
CRL.
Publication of the
Authority Information Access (AIA).
Definition of certificate renewal period. Give them a long life so you do not need to renew
continuously.
Configuring an Offline Root CA
You perform the primary configuration of an offline root CA in a text configuration file known as
Capolicy.inf. It must be placed in the system root folder.
Do you use Capolicy.inf only for Root CAs.
The only time you use a Capolicy.inf configuration file for a nonroot CA is to define a CPS for
issuing CA.
CRL publication interval. The CRL publication interval should be increased from the
default of one week. Increase from 2-3 months.
CRL and AIA distribution points. Disable the default CRL and AIA distribution
points because the root CA won’t be available on the network.
The Default lifetime for issued certificates. Set this greater to 1 year.
Designing the Certification Authority Hierarchy
Once you’ve determined your CA structure’s security by implementing an offline root CA, you
must design a CA hierarchy below the root.
Structure by usage. In this structure, the issuing CAs will be configured to issue only
specific certificate templates. The individual CAs are assigned to specific projects such
as smart card logon, IPSec deployment, or secure e-mail.
Structure by administration. An administrative structure attempts to distribute CAs
to match the administration of the network.
Structure by location. Geographically laid out. Regardless of structure, for maximum
security you must configure the root CA as an offline CA.
======================================================================
winsec10.html PAGE
8 2002/04/30
How Many Levels Do I Require?
The general goal is to create a CA hierarchy that’s three to four levels deep. Likewise, having
a CA structure that’s more than four levels deep introduces unnecessary complexity and might
result in extra time being needed to verify the revocation status for each CA in the certificate chain.
Planning Disaster Recovery of CAs
The final step is deploying CAs is planning for the recovery of the CAs in the event of disaster.
Disaster can result from disk failure or accidental removal of Certificate Services.
A RAID-5 volume protects data by writing the data in a stripe across multiple physical disks.
For each strip, one disk contains parity information that allows recovery of the data stored in
that stripe if a single disk fails in the RAID-5 disk set.
Ensure that the Certificate Services data stored are backed up regularly. You can accomplish
this in one of two ways:
WARNING: You must include IIS in the backup set because the Web Enrollment Support
Pages included with Certificate Services update the IIS metabase.
Applying the Decision
Blue Yonder Airlines must include and restore strategy for all CAs in their organization. The
company should purchase a common computer system that implements RAID-5 and RAID-1
disk sets for the Certificate Services database and log files.
Finally, you should create an image of the root CA for the hierarchy on a CD. This CD allows
you to restore the root CA quickly in the event of failure. You must update this image whenever
additional certificates are issued or renewed at the root CA.
======================================================================
winsec10.html PAGE
9 2002/04/30
Lesson Summary:
CAs for specific scenarios.
without reissuing certificates.
Lesson 2:
Managing Certification Authorities
When designing your CA hierarchy structure, consider designing the individual tasks that are
performed at the CA.
Planning Certificate Issuance
Issuing certificates involves either configuration permissions to establish which security principals
have Enroll permissions for specific templates (in the case of Enterprise CAs) or appointing a
certificate administrator who will review each certificate request and issue or deny the request
based on the information provided.
The computers must have Read and Enroll permissions for each certificate template they require.
You can’t automatically assign user certificates.
Applying the Decision
Blue Yonder Airlines must develop an issuance policy for all internal certificates required on the
network.
To provide these certificates to all computers in the domain, configure the Default Domain Policy
to issue both IPSec and Computer certificates by defining the Automatic Certificate Request
Settings policy. There is no way to issue certificates to internal users automatically.
Planning Certificate Revocation
Sometimes you have to revoke a certificate before its expiration date. Some reasons may be
termination of an employee, a compromise of the issuing CA, or dissolution of a partnership
between organizations.
======================================================================
winsec10.html PAGE
10 2002/04/30
When an application needs to verify a certificate, the application downloads the CRL referenced
in the certificate to the client’s local cache.
If you forsee frequent certificate revocations, you should shorten the publication period to
minimize the time in which clients may have outdated CRLs in their cache.
Another issue you may include in your CRL design is the CRL’s availability. When designing
offline CAs, configure CRL distribution points that are always available on the network.
Making the Decision
and the CDP configuration for subordinate CAs to change the publication point of an area of
the network that’s always available.
Ensure availability of the CRL. The CRL should be available from any DC within the forest.
network. Consider using either HTTP or FTP publication points for the CRL to ensure
external availability.
the certificate be available, but the CRL for each CA in the chain back to the root CA must
be available to ensure that none of the CAs certificates are revoked.
Applying the Decision
The publication schedule for the Customers CA doesn’t have to be updated frequently, every
two to three months would be sufficient.
The Smart Card CA requires more frequent publication. In the scenario you must update the
CRL every 4 hours for the Web access.
======================================================================
winsec10.html PAGE
11 2002/04/30
Planning Certificate Renewal
All certificates have a finite lifetime defined by the issuing CA. Two registry values define the
lifetime for all issued certificates:
HKLM\System\Current ControlSet\Services\CertSvc\Configuration\CAName
ValidityPeriod: REG_SZ (values include Years, Days, Hours)
Validity PeriodUnits: REG_DWORD (numeric value)
When you renew the certificate, you can either reuse the same private and public key or generate
a new private and public keys. For the highest security, you should always generate new private
and public keys. Reuse the existing private and public key only if you’re rebuilding a CA and
don’t wish to invalidate all issued certificates by changing the private key used to sign each issued
certificate.
IMPORTANT You should set the lifetime for CA and SUBSA certificates significantly longer
than the lifetime of other certificate templates.
Making the Decision
Define certificate lifetimes based on renewal requirements.
Define a process that users can computers will use to renew their certificates.
Ensure that the CA certificate’s remaining lifetime is never shorter than the lifetime for issued
certificates.
Plan for renewal dates far in the future.
Lesson Summary:
must carefully define the management functions associated with a CA.
continue to be use
Lesson 3:
Using Certificates for Authentication
One of the primary functions of certificates in a PKI is the mutual authentication of a client and a
server. The two most
common types of authentication are: Smart card logon and Web-based
authentication.
======================================================================
winsec10.html PAGE
12 2002/04/30
Smart Card Logon:
Smart card logon provides stronger security than the default authentication process in Windows
2000 because password information isn’t transmitted across the network.
act as that user on the network.
requires this certificate.
card and to send encrypted e-mail.
used for other purposes such as E-mails etc.
WARNING: Don’t delete any of the certificate templates in Active Directory Sites and Services.
This will remove them from the forest and makes it unavailable for all users in the forest. The
only way to reinstall the templates is to uninstall and
reinstall an
Configuring CAs to Issue the
Required Certificates
After defining permissions for the required certificate templates, you must configure one or
more CAs to issue the certificate templates. By default, CAs don’t issue any of the required
certificate templates for smart card logon. Only Enterprise CAs can issue the certificate
templates.
Acquiring the Required Certificates
The enrollment agent must acquire an Enrollment Agent certificate. This certificate gives the
user the ability to request certificates on behalf of other users of the network.
Defining the Enrollment Process
You can build security into the smart card certificate distribution process. The enrollment
process should include safeguards that ensure that only the smart card’s user knows the
associated PIN.
======================================================================
winsec10.html PAGE
13 2002/04/30
Planning Certificate-Based Web Authentication
Certificates also can provide authentication through Web services. When a user is connecting
to a Web site protected by a SSL Secure Sockets Layer protocol, you also can configure the
Web site to require certificates for user authentication.
Certificate mapping allows either a single certificate or multiple certificates with similar properties
to be mapped to a single user account. These mappings are known as either one-to-one or
many-to-one mappings.
Configuring authentication in this manner prevents IIS from presenting the user with an
Authentication dialog box.
TIP You can improve the process of performing one-to-one mappings by creating a custom
Web enrollment page that automates the mapping process.