Introduction

Public Key Infrastructure (PKI) can be distilled into two critical parts: a public
and a private key. Keys use asymmetric encryption algorithms to ensure that the
encryption only works ‘one way’ (Hirsch). Each key in a public/private pair can be used
to encrypt (or decrypt) data that only the corresponding key in the pair can decrypt (or
encrypt) (Hirsch). Asymmetric encryption is considered to be slower than symmetric
encryption, but it is more secure (Mircosoft, 2007). The same key cannot be used to
reverse the encryption (Hirsch). By contrast, asymmetrical encryption is often used in the
exchange of symmetrical keys (The SANS Institue, 2013).

The term ‘PKI’ is intended to be an inclusive term…one that includes all of the
major parts required to create assurance or a chain of trust. PKI is designed with the
intention to create, manage, distribute, store, and revoke digital certificates through a set
of hardware, software, user roles, policies, and procedures (Hirsch). The primary uses of
a PKI are to provide a chain of trust that can be used to authenticate a server or user,
construct a secure connection between two end points, validate the integrity of software,
data, or a document, or to encrypt/decrypt/sign email messages (Hirsch).

A certificate differs from a PKI in that a certificate is a digitally signed electronic
document bound to a publically accessible key. It contains information regarding the
origin of issuance (Microsoft, 2005). Information contained within the certificate allows a
user to know the name of the entity that issued the certificate and their contact
information, as well as a being able to validate the signatures of the Certificate
Authorities within the chain of trust (Microsoft, 2005). The certificate provides validation
to the end user that the computer or person with whom they are communicating can be
trusted (Microsoft, 2005).

Certificates are issued to be valid for specific lengths of time (Microsoft, 2005).
The validity period can range from a few days to many years and is dependent on the
certificate template configuration. Once the validity period expires, the certificate is no
longer valid and is revoked by the Issuing Certificate Authority (Microsoft, 2005). A
Certificate Revocation List (CRL) is published by the Certificate Authority to provide an
accessible list of revoked certificates (R. Housley, 2002). CRLs also have a validity
period defined by the Certificate Authority and are a necessary part of the chain of trust
(R. Housley, 2002).

PKIs can be described in terms of hierarchical roles and levels of assurance. The
predominant hierarchical roles of Certificate Authorities are Root Certificate Authority
(Root CA) and Subordinate Certificate Authority (Intermediate or Issuing CA) (Pyle,
Designign and Implementing a PKI: Part I Design and Planning, 2009). Each role has
varying configuration options, dependencies, and requirements to ensure that
confidentiality, integrity, and availability are maintained (Microsoft).

Assurance indicates a specific level of trust and can be described as Level 1 to
Level 4, in terms of consequence to the CA (William E. Burr, 2011). The definitions
applied to assurance levels directly correlate to the sensitivity of environment that is to be
secured. Highly sensitive environments (Level 4; production, externally facing) would
have a high assurance level and correspondingly rigorous practices that maintain a high
level of confidentiality and integrity (William E. Burr, 2011). Low assurance
environments (Level 1; non-production, internal customers only) require less rigor and
assurance as a result of that which they are in place to secure (William E. Burr, 2011).

Root CAs are the first and most important role within a PKI. Root CAs are the
trusted foundation upon which a PKI is built. A Root CA will be trusted by all other
Certificate Authorities within the same PKI instance (Pyle, Designign and Implementing
a PKI: Part I Design and Planning, 2009). This makes the security practices and
procedures used to manage Root CAs critically important to the trustworthiness of
certificates issued by the PKI.

Root CAs are often recommended to be built as standalone and offline (Microsoft,
2014). The best practice is to use a hardware security module (HSM) to store the private
keys, as this results in enhanced security and logging surrounding the private keys of a
CA (Microsoft, 2014). This prevents unauthorized access to the private keys, provides
logging for key access, and allows them to be stored online for easy retrieval (Roginsky,
2011). This is most often seen in a large enterprise installation due to high capital
expenditure. Small to medium organizations might employ an alternative combination of
hardware and physical controls to provide similar assurance provided by an HSM.
Another best practice is to never allow the Root CAs to participate on any network
(Microsoft, 2014). This is to ensure that they are not exposed to any threat or
compromise.

If an HSM is not used, many creative alternatives can be established to prevent
unauthorized access, log key access, and log key retrieval. One such combination of
alternative components to build the Root CA can be an offline laptop with an external
USB drive that contains the Root CA. These are to be stored in a location to which none
of the builders have access. A trusted 3rd party within the organization might possess the
ability to retrieve the components from a safe or secured area. When stored, it is advised
to seal the components in separate tamper-evident envelopes to ensure that they have not
been compromised since their return to storage. Signatures from those who last used the
components along all sealed edges are also advised. Each signature must be validated
prior to breaking the seal in order to retrieve the component to boot the virtualized guest
to make necessary changes.

I recommend that Root CAs are built by 2 or more people, each possessing
insufficient information to make changes by themselves to the Root CA (Microsoft,
2003). For example, one individual may possess an encryption password or key for an
external drive on which the Root CA resides. The other may know the password to login
to the Root CA server itself. This separation of duty provides additional assurance to the
integrity of the PKI.

Issuing or Intermediate Certificate Authorities are the online subordinate to the
Root CA within the chain of trust (Pyle, Designign and Implementing a PKI: Part I
Design and Planning, 2009). The Root CA signs the certificate issued to the Issuing CA
to create the chain of trust (Microsoft). The Issuing CA now has authority to issue
(approve or reject) the majority of the certificate requests for the PKI (compared to the
Root CA).The Issuing CA publishes certificate templates that govern individual template
types to be used in the PKI (Microsoft). It also sets the minimum requirements for key
length, hash algorithm, validity and renewal periods, and publishes a list of revoked
certificates (Microsoft).

As you can see, a PKI is a complex, highly secure, and vital component for an
organization. Ensuring that a well-planned implementation occurs is tantamount to
creating a PKI that meets the assurance demands of the organization. The following
sections outline critical decisions to make prior to implementation as well as installation
guidance.

Prerequisite Decisions

Prior to implementation, there are a number of PKI design decisions that are
HIGHLY advisable to make. Making these decisions on the fly may create an
undesirable position in the future. As an example, Microsoft advises that the CA Server
Name or domain not change after the CA role has been installed (Microsoft, 2013).
Changing this essentially means building a new CA and re-issuing all valid certificates
(Microsoft, 2013). Choosing appropriate names is critical to the PKI environment as they
must be meaningful for the duration of the CA (up to 20 years or longer).

The critical decisions listed below are not intended to be an exhaustive list of
every possible decision to be made. This list was created after multiple Microsoft
Windows Server 2012 Certification Authority PKIs were designed and implemented for
an example organization.

Private Enterprise Number

Although not required for private or internal PKIs (not made externally available), a
Private Enterprise Number (PEN; assigned by the Internet Assigned Numbers Authority
(IANA), American National Standards Institute (ANSI), or British Standards Institute
(BSI)) is the first step to generate a unique Object Identifier (OID) for any object
referenced within the PKI. The OID provides a hierarchical name for almost every object
type within a PKI such as a Certificate Practice Statement or Certificate Policy (OID
Info, 2014). IANA provides an initial referential value (1.3.6.1.4.1) to which the PEN is
appended at the time of issuance. An example of a PEN referenced by IANA is:
1.3.6.1.4.1.5518 (TDS Telecom, Inc.). IANA provides additional guidance regarding the
data structure used to define network management parameters for use with SNMP and
TCP/IP (Internet Assigned Numbers Authority, 2014).

A PEN can be requested from IANA by going to this registration page. The
contents of the required form fields will be made available publically with the assigned
PEN (Internet Assigned Numbers Authority). A single PEN is normally granted to an
organization. An organization can search the PEN registry to determine if a PEN has
been issued to them already (Internet Assigned Numbers Authority). This process can
also take up to 30 days to complete (Internet Assigned Numbers Authority). The OID
Repository also offers a location where information about many OIDs can be found;
however it does not (and cannot) contain all OIDs (OID Info, 2014).

Once the PEN is obtained, the organization can append any series of numbers to
the end of the OID to identify any object within the PKI (Alvestrand, 1997). Suggestions
such as the following have been used to represent additional aspects of an organization
via the OID:

An example OID for a production PKI implementation for the corporate office
using the suggestions would be: 1.3.6.1.4.1.5518.1.1.1.5.1. The numbers 1.1.1.5.1 were
appended to the PEN to create the complete OID that refers to the General Purpose
Issuance Policy.

One final decision left to make regarding the PEN/OID is: on which Certificate
Authority to add the OID? The OID will be added to the ‘CAPolicy.inf’ file used in the
configuration of the Certificate Authority during the installation of the Server 2012 role.
This is done to reference the location of the Certificate Practice Statement and Certificate
Policy, in the previous example, that govern the CA. Adding the OID to the Root CA
means that subsequent CAs in the PKI will be bound to that OID; perhaps better stated
that subordinate CAs cannot have a completely unique OID. There may be cases where
this may be desirable or undesirable. Root CAs can be built without an OID (remember:
they are offline and are not to be added to any network). A single Root CA without a
defined OID can sign certificates for many Issuing CAs easily; managing multiple Root
CAs can be cumbersome.

Certificate Validity Periods

One of a CA’s primary responsibilities is to issue certificates (Microsoft, 2012).
Certificates issued for and by a CA have a limited life span. The life cycle of a certificate
issued by or for a CA should be relative to an organization’s requirements and necessary
assurance level (Microsoft, 2009). A Certificate Policy (CP) and a Certificate Practice
Statement (CPS) are generally used to define the PKI’s parameters which notify the
consumers what level of assurance to expect (Microsoft, 2009). Create a Certificate
Policy and a Certificate Practice Statement prior to implementation (S. Chokhani, 2003).
Microsoft offers recommendations regarding the validity period for various CA types
(Microsoft, 2009). This guidance includes key length and a maximum number of years
for the life of the certificate (Microsoft, 2009). The actual validity used by an
organization could be dictated by contractual obligations.

A common length of time for a Root CA to be valid is 20 years. Issuing CAs are
generally configured for one-half of the life of its parent/Root CA (in this example, 10
years). This value can be configured to any desired time period; however, it is worth
considering a length of time that is shorter than the time expected to break the hash
algorithm used within the PKI.

Renewal Validity

A Renewal Validity period is the length of time during which a certificate
can be renewed (Microsoft, 2005). Once this time period expires, the certificate will
be revoked (unless it is renewed prior to expiring). Validity periods for individual
certificates can vary, by template type, from a few days (development, testing) to
multiple years, depending, on the use case.

CRL Renewal Periods

The second responsibility of a certificate authority is to publish a list of
certificates that are no longer valid (Delay, 2012). This is done by publishing a Certificate
Revocation List (CRL). Clients that want to check the revocation status of a given
certificate will connect to a published CRL distribution point (CDP) to find a copy of the
CRL. The Client then parses the CRL for the certificate in question as well as its
revocation status (Microsoft, 2005).

The CRL renewal period defines how long the CRL is valid. Shorter validation
periods lessen the time to recover in the event of a disaster (Delay, 2012). Also, many
clients cache a CRL and won’t check back until the validation period expires (Delay,
2012). If a certificate is revoked during this period, a client may be unaware until their
cached copy expires and forces them to download a new CRL (Delay, 2012).

CRL renewal periods for Root and Issuing CAs are different as their roles are
different. A Root CA is offline (Microsoft, 2014) and not even powered on save for a few
times a year (Microsoft, 2012). A Root CA will issue (and by nature revoke) a relatively
low number of certificates (Microsoft, 2012). Updating CRLs will be less of a necessity
for Root CAs. Thus, a Root CA’s CRL Period can easily be configured to be at least 30
days (Microsoft, 2012) or even a length of time up to its renewal validity to avoid
powering up the CA unnecessarily.

An Issuing CA, on the other hand, will be issuing and revoking an exponentially
higher number of certificates. Thus, publishing a CRL more often is necessary. An
example CRL Period for an Issuing CA could be 7 days. This will ensure that revoked
certificates are made known publically in a timely fashion as well as forcing clients to
check back somewhat frequently (Delay, 2012). This can easily be configured to be
shorter or longer depending on the volume and type of certificates issued (higher
numbers of issued certificates may likely result in a higher number of revocations).

Delta CRLs

Given that offline Root CAs will not be issuing or revoking many
certificates, Delta CRLs are not a necessity root CAs (Microsoft, 2012). For Issuing
CAs, the Delta CRL contains a list of revoked certificates and defines the ‘delta
overlap’ period, which is the acceptable length of time that a CRL Period is valid
when the publication of a new CRL is delayed or fails to publish timely (Delay,
2012). This extends the life of the existing Delta CRL to allow for the next CRL to
be published. The recommended best practice by Microsoft is 10% of the CRL
Period (Microsoft, 2012). The default setting, if not configured, is 12 hours
(Microsoft, 2012). This setting also cannot exceed the CRL publishing period
(Microsoft, 2012).

CRL Distribution Points

CRL Distribution Points (CDPs) can and will take many different forms
within the PKI environment. The primary CDP locations are described below, but
the description is not intended to be exhaustive or inclusive. It contains the most
common types of CDPs.

Given that Windows Server 2012 is being discussed, you are undoubtedly
aware that Certification Authorization roles are tightly integrated within Active
Directory. Thus, LDAP can be a location where CRLs and Delta CRLs will be
published and made available to domain members (Microsoft, 2009). It is
recommended but technically not a requirement.

Windows Server 2012 Certificate Services leverages a network share (SMB,
if not already running on a Windows server) as another target for publishing CRLs
(Microsoft, 2009). In most cases, only the Issuing CA’s machine or system account
needs access to the share. Two (2) servers minimally are advised to function as
CDPs for a given PKI to provide a highly available CDP share. The server names
and share name (often CRL$) are used later in the configuration of the Issuing CA
(Microsoft, 2009).

Windows Server 2012 Certificate Services also requires a URL (embedded
in all issued certificates) that provides access for CRL checking by internal AND
external clients (Microsoft, 2009). You will want 2 sets of servers with
corresponding shares (Microsoft, 2011): one pair services external or DMZ clients,
and one pair services internal clients; both load-balanced. This is generally
accomplished by installing Internet Information Services (IIS). Double-escaping is
required to be enabled in ‘Request Filtering’ as the delta CRL contains a plus sign
‘+’ in the file name. Microsoft also offers a PowerShell command (appcmd set
config /section:requestfiltering /allowdoubleescaping:true) to enable double
escaping (Micrososft, 2012). Also configure the CRL$ share as a virtual directory
on the default web site (Microsoft, 2009).

The CDPs also contain a copy of the Root and Issuing CAs public
certificates and CRLs, as this is necessary during CRL checking to establish a trust
chain (Microsoft, 2012). For the Root CA, this is manually exported and copied into
the share, as the Root CA is offline. It is also manually published into Active
Directory (Pyle, Designing and Implementing a PKI: Part II Implemntation Phases
and Certificate Authority Installation, 2009). During the configuration of Issuing
CA, the certificate will be published to Active Directory and copied to the CDP
(either via a script or manually) (Pyle, Designing and Implementing a PKI: Part II
Implemntation Phases and Certificate Authority Installation, 2009).

A few words of advice about external CDPs: depending how your Active
Directory is configured (extended into the DMZ, or the DMZ has a separate
Windows domain), the process by which CRLs and Root/Issuing CA public
certificates are published could vary. If separate domains for internal and DMZ
environments exist, a file copy job (robocopy works well) running daily to move the
files is recommended (read: a rule for a single firewall port is needed). If your
internal domain is extended into your DMZ, a plethora of Windows ports on your
firewall will be required (Microsoft, 2010). This is not advised as there are many,
many open ports required (Microsoft, 2010). A file copy job is always preferred
over an extremely permissive firewall rule.

Online Certificate Status Protocol

Online Certificate Status Protocol, or OCSP, is an IP protocol used to obtain
the revocation status of an individual digital certificate (M. Myers, 1999). It was
created as an alternative to certificate revocation list checking to determine the
validity of an individual certificate. Communications with OCSP occur over HTTP
(M. Myers, 1999). A URL is required for OCSP (Patel, 2012). Thus, it is dependent
on the installation of IIS. HTTPS is not mandated (M. Myers, 1999), and thus a 3rd
party could intercept unencrypted traffic (M. Myers, 1999).

OCSP uses far fewer resources as the communications contain only
information about a single certificate (M. Myers, 1999). Clients do not need to parse
the CRL themselves. Instead, OCSP contains a cached copy of the CRL and
responds to requests about individual certificates (M. Myers, 1999). A common
URL and name that is hosted by a load balancer or DNS is preferred over a serverspecific
name for the URL.

Cryptographic Service Provider and Key Length

Microsoft offers a number of Cryptographic Service Providers within the
Windows Server 2012 Certification Authorization role. A full list can be found online
(Microsoft). Choose the one that best suits your needs. The default in the role installation
is Microsoft RSA Signature Cryptographic Provider and is likely adequate for many
organizations implementing this specific PKI.

When choosing a Key Length, there are a number of factors to consider.
Generally longer key lengths are considered more secure as they require more time to
brute force the hash algorithm (The SANS Institue, 2013). Choosing a short key length
could create a situation where the validity period of the CA is longer than the time
required breaking the hash algorithm. Another thing to consider is the age of the
operating systems for which certificates will be issued. Older operating system may have
limitations regarding supported key lengths. Understand your environment prior to
choosing a key length.

Certificate Templates

Certificate Templates are used to define the properties of certificate issued by a
CA and have many attributes that control certificate behavior (Stephens, 2010). A
template can limit the number of users who have access to request a certificate, or allow
anyone to request a certificate from that template. Templates also contain the validity and
renewal periods, backward compatibility settings, enrollees, and minimum key length
(among many other things).

Choosing which templates to use for specific applications can be tricky. It is up to
each organization to define the types of templates to use for specific applications in their
individual environments. Typical applications are server (HTTP, URL), user
(workstation, Wifi networks), and email signing. Microsoft provides guidance regarding
how to plan for and choose specific templates to use (Stephens, 2010). It is highly
advisable to perform this research and make decisions prior to the start of implementation
about which templates best meet specific needs. It is also advisable to duplicate a
template rather than edit the default templates provided (Microsoft, 2013). This allows
for full customization without losing the original settings.

Windows Active Directory

If you have an older Active Directory environment, you may have both a forest
root and a domain root. You may or may not recall, but the forest root will function as the
default certificate store (Baker, 2013). I unfortunately remembered this after I
implemented and had some problems with things not working like I expected. However,
do not despair! This is a configuration change that can be accomplished without starting
over from scratch.

It is highly advisable to ensure that you have a deep understanding of the Active
Directory environment in which you are installing a PKI. Does the domain in which you
are installing the PKI have an existing PKI? If it does, that is not technical a problem. A
given Windows domain can support multiple Issuing CAs (Microsoft). It is good to
remember that the trust chain from the new PKI will be inherited by any machine in the
domain (Microsoft). It is advisable to avoid a lower assurance PKI in the same domain as
a medium or high assurance PKI (William E. Burr, 2011).

Does the domain in which the PKI will be installed have both development and
production servers within it? This is not necessarily a problem, if the intention is to issue
certificates from the same PKI instance to servers in all environments (prod and nonprod).
This could become a problem if the intention is to issue certificates from a nonproduction
PKI to only non-production servers that are managed by a single production
domain. Again, any domain member machine will receive the trust chain from any PKI
installed in the domain (Microsoft). This could expose production servers to a nonproduction
trust chain, which is undesirable in many cases (William E. Burr, 2011).

Again, it is advisable to avoid a lower assurance PKI in the same domain as a medium or
high assurance PKI (William E. Burr, 2011).

Permissions

Given this process includes Active Directory and Microsoft Windows Server,
there are numerous ways to grant the necessary permissions for administration purposes.
The permissions described below are intended to cover installation only (Patel, 2012).
The section on Administrative Roles makes recommendations regarding separation of
duties and appropriate permissions for individual roles.

• Certificate Services role installation: local administrator for Root CA;
enterprise administrator for Issuing CA. The permissions to administer the
Issuing CA long term can be reduce to be less than enterprise administrator.
• Web Enrollment server role installation: enterprise administrator
• Internal CDP share
o NTFS permissions: enterprise administrator with full control
during installation; AD group named Certificate Publishers with
modify access during and after the installation
o Share permissions: enterprise administrators with full control
during the installation and AD group named Certificate Publishers
with modify access during and after the installation
• External CDP share
o NTFS /Share Permissions: must allow the Internal CDP
servers to publish the contents of the Internal CDP shares
here. These permissions could vary depending on the type of
method uses to populate the share contents.
• Internet Information Services role installation: enterprise
administrator.

Legal Notification

Some organizations are required to populate lengthy legal statements in their
certificates, but doing so creates additional bloat in the size of the certificate. Default
certificate sizes for Server 2012 are around 17KB in the database and 15KB in the log
(Arwine, 2012). Error on the side of caution and use a higher value (64KB) to estimate
how much local storage will be required in the certificate store for your environment (#
of certs * 64KB = X mega/giga bytes).

Some organizations add the majority of their legal-ease to the Certificate Policy
(CP) and Certificate Practice Statement (CPS) documents and use a simple legal
statement such as: "Legal Policy Statement - This PKI is for the environment.
Refer to the associated Certificate PracticeStatement (CPS) for more information.
” It is advised to so something similar to avoidunnecessary bloat in the CAs storage
environment. Guidance to create a Certificate Policy or a Certificate Practice Statement
can be found in RFC3647 (S. Chokhani, 2003), as there are standards regarding what the
documents contain as well as the order in which these items are displayed.

Administrative Roles

Microsoft defines the following roles and aligns them closely to roles defined by
Common Criteria classifications (Microsoft). While additional roles could be defined, it
is advised to determine which individuals and groups within an organization would own
each of these roles prior to implementation.

It is also advised to maintain separation of duties when implementing this security
model: no one group would be both a CA administrator AND a CA manager (Microsoft).
These roles are recommended to be deployed as groups rather than granting permissions
to individual users (Microsoft).

CA Administrators can be added to the local admins group on the Issuing CA
server, as well as granted with Manage CA permissions defined on the CA itself
(Microsoft). CA Managers are granted Issue and Manages Certificates permissions
defined on the CA itself (via Certification Authority (certsrv.mmc) MMC console; right
click on the CA object, and choose Security) but not added to any local administrative
group (Microsoft).

Backup Operator is also a local admin but receives no permissions on the CA
itself (Microsoft).

Auditors can be given Read permissions to the CA itself (again, via the
Certification Authority MMC) in order to audit the CA’s configuration. Auditors also are
provided permissions to review local audit logs (Microsoft).

Enrollees can be given permissions to Request Certificates on the CA itself as
well as to various individual templates with Read and Enroll permissions. A process that
describes how to set permissions on templates is described in a later section. This same
process is used to add Enrollee permissions on templates. Enrollee is not considered to be
a CA role, however (Microsoft).

Installation

The following section summarizes the steps to perform the Root CA installation
and configuration as well as the online Issuing CA installation and configuration. The
Root CA installation was performed on an offline Windows 7 (base install; no hot fixes)
laptop that has all network interfaces disabled. This laptop was installed with VMware
Workstation. The Online Issuing CA was built on Server 2012.

For the Root CA install, these instructions assume that one has a VMware guest
on an encrypted USB drive that can be booted on a laptop that is 100% offline.

Again, please be advised that all environments are unique, and this is intended to
describe the steps used to build a PKI for an example company. No guarantees, either
written or implied, are provided.

CRL Distribution Points (CDP)

Prior to installing the Root or Issuing CA, the CDP URL locations and shares are
recommended to be configured. An existing CDP could be used also. Performing this
step early in the process ensures that there is an appropriate location in which to store
necessary files as they are created by each CA. In order to configure the URLs and
shares, the names and networks of the CDPs and servers running the CDP must be
determined.

The external CDP is an externally accessible location (HTTP; fully qualified
domain name) load-balanced between at least two (2) servers. Thus, its name is not
expected to reference an individual server. This is the location where CRLs are checked
by external entities (Example: certrev.dmzprod.company.com). Select two servers to host
the External CDP and document their names. Each will require a web server (IIS is used
in this example) to host the external-facing URL as well as a network share to which the
contents of the internal CDP will be published.

The internal CDP is accessible to internal clients only (HTTP; fully qualified
domain name) and is also expected to be load-balanced. Thus, its name is not expected to
reference an individual server. This is the location where CRLs are checked be clients on
the private, internal network of the organization (Example: certrev.prod.company.com).
Select two servers to host the Internal CDP and document their names. Each will require
IIS to host the internal-facing URL. The network share is published via IIS and contains
CRLs, Delta CRLs, and public certs for the Root and Issuing CAs.

As previously stated, shares are required to contain public certificates, CRLs, and
Delta CRLs for the Certificate Authorities. The creation of two types of shares, external
and internal, is described below. Each has a slightly different configuration as the files
served by the share are published to the share via different methods.

The internal share will contain the public certificate for the Root and Issuing CAs.
Also, the Issuing CA will publish its CRL and Delta CRL to this location. Therefore,
specific share and NTFS permissions are required. This section outlines how to create
and ACL the share and NTFS permissions.

Create the Internal Shares:

Create a directory using the Internal CDP name

a. Example: mkdir d:\websites\certrev.prod.company.com
i. This location is suggested as it will be used in the IIS configuration
later.

Share the CDP folder (d:\websites\certrev.organization.net\CDP) as CRL$
a. The share and NTFS permissions required to facilitate a file copy from the
internal CDP servers are required here. See additional comments below.

Repeat steps 1 – 5 on the 2nd external CDP server

Rather than publish directly from the Issuing CA to the external CDP, it is
advised to copy the contents of the Internal Share to the External Shares. In order to
publish directly to a share, RPC traffic must be allowed to pass between your
internal and external networks (read: Windows file copy). This is seldom advised
due to the high number of ports/protocols required (Microsoft, 2010).

Thus, it is advised to create a script that will copy the contents of the internal
CDP share to the external CDPs. Robocopy.exe or SCP.exe are a perfectly suitable
tools to do this. Then, you can restrict the firewall rules to allow a single port from
an internal CDP server to the external CDP servers. Therefore, the external share
must be configured to allow an internal CDP server to write the contents of the
Internal CDP to it.

Internet Information Services (IIS) Configuration

IIS is required for CRL checking via the CDPs, as this is performed via HTTP
methods for many legacy applications and operating systems. Online Certificate Status
Protocol (OCSP) is used by newer applications and operating systems and will be
installed as well. It is also dependent on IIS.

The following section provides guidance regarding IIS configuration. IIS
installation is not covered in this section as this can be specific to a given organization.
However, advice is provided regarding some of the configuration options. It is
recommended that this be configured identically across all CDP servers.

IIS Installation and Configuration:

Install IIS in accordance to organizational procedures.

Change the Default Web Site settings to point to the first directory you created in
the CDP configuration section (example: d:\websites\certrev.prod.company.com)

a. This ensures that the CDP shared directory becomes part of the hosted
web site necessary for CRL checking.

Move log files to the same location found in #1 (directly above)

Edit the Request Filtering settings to Allow Double Escaping

a. This is required as the Delta CRL file contains a plus sign (‘+’). Without
this setting, the Delta CRL file is not visible.

Repeat on all CDP servers using the network-specific URL information to create
the directory for the default web site.

Root Certificate Authority Installation

Prior to installing the Root CA, a custom CAPolicy.inf file was created and
placed in the c:\windows directory. This file is parsed during installation and makes some
basic configuration settings (rather than after the install has been completed). Please refer
to the example file provided in the Appendix. Items in brackets < > are organizationspecific.
Microsoft has a well-documented procedure (Microsoft; Microsoft) that covers
what is summarized below.

1. Open Server Manager and add a New Role.
2. Select Active Directory Certificate Services
3. Choose the role labeled Certification Authority
4. Select the setup type of Standalone for the offline Root CA
5. Create a New Private Key
6. Configure the minimum Cryptographic Service Provider, Key Length, and
Hash Algorithm that you want the CA to support.
7. Name the Certificate Authority. WARNING: this name will persist for the life of
the CA, and it is not recommended to change this in the future.
8. Set the Validity Period in the number of Years or Months that the Root CA’s
certificate will be valid. See previous guidance regarding an appropriate time
frame.
9. Review all configuration settings. Save/apply all changes.

Root Certificate Authority Configuration

Once the Root CA has been installed, there are items to be configured. This can
be done manually via the Certificate Authority MMC, or via a script. The example script
in the Appendix describes the configuration settings.

Directory Store Configuration Distinguished Name: the location in Active
Directory where the configuration information about your PKI is stored.

a. Example string: CN=Configuration,DC=PROD,DC=Company,DC=Com

CRL Period: defines the life of the CRL and is a measure of time (days, weeks,
months, years) as a numerical value.

a. CRLPeriod: Years
b. CRLPeriodUnits: 19

CRL Overlap Period: the amount of time at the end of a published CRL's lifetime
that a client can use to obtain a new CRL before the old CRL is considered
unusable. This is also a measure of time (days, weeks, months, years) and a
numerical value.

a. CRLOverlapPeriod: Weeks
b. CRLOverlapUnits: 52

Validity Period: defines, in terms of days, weeks, months, or years, how long
certificates issued by the CA are valid (example: for the online Issuing CA to be
built/configured in a later step)
a. ValidityPeriod: Years
b. ValidityPeriodUnits: 10

CA Auditing: defines the audit flags that are enabled on a specific CA

Given that a Windows-based PKI is discussed, there is heavy reliance on Active
Directory. The Root CA’s public certificate is published in Active Directory, as well as in
all CDP locations. Without these, a trust chain cannot be established.

A script was used to programmatically configure all items necessary using the
information determined in the CDP configuration step. An example script is provided in
the appendix, and the locations to edit have been highlighted. Please review the entire
script prior to execution or implementation. The items to add to the script are:

Adding this information to the example script sets the registry settings on the
Root CA to reference these locations. It also copies the *.CR? files (Root CA public cert
and CRL) to c:. These files are to be copied into AD as well as the CDPs (in a later step).

Issuing Certificate Authority Installation

Prior to the installation of an Issuing CA, it is advised to configure a CAPolicy.inf
and copy it into the c:\windows directory on the server that will become the Issuing CA.
This file is read as the CA is installed and makes some basic configuration settings.
Please refer to the example provided in the Appendix. Items in brackets < > are
organization-specific.

Once c:\windows\CAPolicy.inf exists with the correct parameters, the public
certificate for the Root CA must be installed into the local certificate store on the Issuing
CA and published into Active Directory. This was done via a script for the example
organization but could be done manually. This was accomplished by the following
process. This is essential to creating the trust chain between the Root and Issuing CA.

.CRT and .CRL were copied from the Root CA to c:\ on the Issuing CA

a. The highlighted text in the example script reflects that which was changed
for the example organization.

Run the script as PROD\Enterprise Administrator to publish the cert and CRL
locally and in Active Directory. Note any errors and resolve as necessary prior to
moving on.

After publishing the cert and CRL files, the Issuing CA can be installed.
Microsoft has provided a detailed guide to install an Intermediate or Issuing CA
(Microsoft), and this has been summarized below.

1. Open Server Manager and add a New Role.
2. Select Active Directory Certificate Services
3. Select the role labeled Certification Authority
4. Select the setup type of Enterprise for the online Issuing CA
5. Select the CA type labeled Subordinate CA for the Issuing CA
6. Create a new Private Key
7. Select the appropriate Cryptographic Service Provider, Key Length, and Hash
Algorithm
8. Since the Root CA is offline, choose to save the certificate request to a file for
processing later.
9. Enter an appropriate name for the Issuing CA
10. Enter an appropriate Validity Period for the number of Years/Months to define
the length of time a certificate issues by this CA will be valid.
11. Select appropriate locations for the Certificate Databases.
a. For the example organization, the defaults were unchanged.
12. Confirm installation options and configure.

Issuing Certificate Authority Configuration

Now that the Issuing CA has been installed, there are still a number of
outstanding tasks to accomplish prior to certificate issuance. The following tasks, in the
order in which they appear, are recommended:

During the installation of the Issuing CA, a certificate request was saved to c:\ on
the Issuing CA. This file (requestName.req) is to be copied to the Root CA and signed.
After the file is copied to the Root CA, the following example command can be used to
sign the certificate: Certreq –submit \requestName.req

Open the Certificate Authority MMC (certsrv.mmc) console and navigate to
‘Issued’. You can now export the signed certificate in a binary format. This export is to
be copied back to the Issuing CA for installation. Perform the following steps on the
Issuing CA (Patel, 2012):

1. Copy and save the binary export to the Issuing CA (c:\).
2. Open the Certificate Authority MMC (certsrv.mmc) console. Right click on the
CA itself (left-hand window), choose All Tasks, and select Install CA
Certificate.
3. Follow the prompts to locate the Issuing CA’s signed certificate on c:\ and import
it. This will copy the certificate to the correct location in Active Directory.
4. This will require a restart of the Certificate Authority services.
With the Issuing CA’s certificate signed and installed, the Issuing CA is nearly

With the Issuing CA’s certificate signed and installed, the Issuing CA is nearly
complete. Much like the Root CA, the CRL and Certificate validity settings are to be
configured prior to issuing certificates from the newly minted Issuing CA. These were
configured for the example company via a script that edits the registry on the Issuing CA.

CRL Period: defines the life of the CRL and is a measure of time (days, weeks,
months, years) as a numerical value.

a. CRLPeriod: Weeks
b. CRLPeriodUnits: 1

CRL Overlap Period: amount of time at the end of a published CRL's lifetime that
a client can use to obtain a new CRL before the old CRL is considered unusable.
This is also a measure of time (days, weeks, months, years) and a numerical
value.

a. CRLOverlapPeriod: Hours
b. CRLOverlapUnits: 48

CRL Delta Period: defined by a measure of time (days, weeks, months, years) and
a numerical value and measures the life of the Delta CRL.

a. CRLDeltaPeriod: Days
b. CRLDeltaUnits: 1

CRL Delta Overlap Period: amount of time at the end of a published CRL's
lifetime that a client can use to obtain a new CRL before the old CRL is
considered unusable.

a. CRLDeltaOverlapPeriod: Hours
b. CRLDeltaOverlapUnits: 6

Validity Period: defines, in terms of days, weeks, months, or years, how long
certificates issued by the CA are valid

Given that a Windows-based PKI is being discussed, there is heavy reliance on
Active Directory. The Issuing CA’s public certificate and CRL are published in Active
Directory, as well as in all CDP locations. Without these, a trust chain cannot be
established. A script was used to configure all items necessary using the information
determined in the CDP configuration step. An example script is provided in the appendix,
and the locations to edit have been highlighted. Please review the entire script prior to
execution or implementation. The items to add to the script are:

Adding this information to the example script will set the registry settings on the
Issuing CA to reference these locations. It will also copy the *.CR? files (Issuing CA
public cert and CRL) to c:. These files are required to be manually copied one time to all
CDP locations.

Web Enrollment Server and Online Responder Installation

For the example organization, the Web Enrollment Server (WES) and Online
Responder (OCSP) were installed on the same server for the example organization. This
was done to consolidate server roles as neither role was expected to be used heavily
enough to necessitate physical separation. The following numbered list is a consolidated
summary of guidance provided by Microsoft regarding WES (Microsoft) and Online
Responder installation (Microsoft).

a. IIS will be installed by default if it is not already installed on the server to
be used for WES/Online Responder

Click ‘Install to complete the installation

In addition to this configuration, HTTPS binding is to be configured on WES.
WES will only request certificates from the Issuing CA if HTTPS bindings are enabled
(Microsoft, 2013). Microsoft provides guidance (Microsoft) how to configure HTTPS
bindings, and this will not be described at length in this paper. It is advised to issue a
certificate to the WES from the Issuing CA previously installed via a template
specifically created for the WES (Microsoft).

Due to the fact that the Issuing CA and WES are installed on separate nodes in the
example, it is required to configure delegation for the WES to submit certificate requests
on behalf of other users. Microsoft provides guidance regarding this process, and it has
been summarized below (Microsoft).

Open Active Directory Users and Computers

Navigate to the server object for the WES, right click, and choose Properties.

Choose the Delegation tab

Choose Trust this computer for delegation to specified services only

a. Also, choose Use any authentication protocol

Add the HOST and RPCSS services for the Issuing CA’s computer object from
Active Directory.

Save/Apply all settings; close all open dialog boxes

OCSP Configuration

To configure OCSP for the example company’s PKI, a Revocation
Configuration is required on the WES server where the Online Responder is installed.
This requires a renewable certificate using the template type OCSP Response Signing
(Patel, 2012). This must be published as an available template type on the Issuing CA as
well as be ACL’d to allow only the WES to request this type of certificate (Patel, 2012).

Prior to configuring the Revocation Configuration, set the permissions on the
template, and add the template to the Issuing CA. The following is a summary of how to
accomplish this (Patel, 2012):

1. Login to the Issuing CA as an Enterprise Administrator
2. Launch the Certification Authority MMC (certsrv.mmc)
3. Add the Snap-In for Certificate Templates
4. Navigate to OCSP Response Signing
5. Choose the Security Tab
6. Add the computer account for the WES with Read, Enroll, and Autoenroll
permissions
7. Save/Apply all settings; close all open dialog boxes

The final step is to create the Revocation Configuration. This will enable OCSP
CRL checking within the example company’s environment. The following is a summary
of guidance provided by Microsoft (Microsoft) to create the Revocation Configuration.

Choose the radio button Browse CA Certificates Published in Active
Directory, and browse to the Issuing CA

Choose the radio button for Automatically Select a Signing Certificate, and
select the checkbox for Auto-Enroll for an OCSP Signing Certificate.

a. The Issuing CA’s name will be populated in the Certification Authority
text box
b. The name of the OCSP Response Signing template will be populated in
the Certificate Template drop-down list

Click the provider button and ensure that the checkbox for Refresh CRLS Based
on Their Validity Periods is selected.

This completes the installation and configuration of the Web Enrollment Server
and Online Responder. The PKI installation is now complete and is ready to issue
certificates.

Diagrams

The following diagrams are provided as examples of the infrastructure, role
location, and network locations for the design described in this paper. Please note that
this is one possible example design and that other configurations are possible and viable,
depending on environment variables, required assurance levels, and budget.

Non-Production

Production

Conclusion

A PKI is both a critical application within the Enterprise as well as a complex
undertaking that requires intense planning prior to implementation. An
understanding of the requirements, dependencies, and use cases helps an
organization focus on critical decisions. Focusing on these decisions will ensure a
timely deployment that is free of shortasightedness common to rushed
implementations.
Each decision is dependent on those that have occurred previously and affects
subsequent and future decisions. A focused, methodical implementation approach
for Microsoft Windows Server 2012 Certificate Services has been described in this
paper. This can be used to create a deployment strategy to rapidly deploy a PKI for
any assurance level required.

This paper has also described how to use the decisions during the
implementation and configuration of Microsoft Windows Server 2012 Certificate
Services. A description and configuration guidance for each component has been
provided. The intention is to practically apply the outcome of each decision to its
corresponding element within the PKI. The resulting methodology helps to develop
strategy than can be promptly and accurately implemented.