CHAPTER 13
IMPLEMENTING CERTIFICATE SERVICES
Lesson 1:
Introducing Certificates
Overview:
Certificates enable users to use smart card logon, send encrypted e-mail, and sign electronic
documents. Certificates are issued, managed, renewed, and revoked by certificate authorities.
A certificate (digital certificate, public key certificate) is a digital document that attests to
the binding of a public key to an entity). The main purpose of a certificate is to generate
confidence that the public key contained in the certificate actually belongs to the entity
named in the certificate. It is a type of third-part verification.
A certificate may consist of a public key signed by a trusted entity.
An X.509 certificate contains information that identifies the user, as well as information
about the organization that issued the certificate, including the serial number, validity
period, issuer name, issuer signature, and subject (or user) name.
How Certificates are Created
Certificates are issued by a CA, which can be any trusted service or entity willing to verify
and validate the identifies of those to whom it issues certificates, and their association with
specific keys. The following six steps describe the process of requesting and issuing a
certificate.
Generating a key pair. The applicant generates a public and private key pair or is
assigned a key pair by some authority to his or her organization.
Collecting required information. Applicants e-mail address, birth data, fingerprints,
notarized documents, whatever the CA need to be certain that the applicant is who he or
she claims to be.
Requesting the certificate. The applicant sends a certificate request, consisting of
his or her public key and the additional required information, to the CA.
=====================================================================
wininf13.html PAGE 2 2002/04/06
Verifying the information. The CA applies whatever policy rules it requires to verify
that the applicant should receive a certificate.
Creating the certificate. The CA creates and signs a digital document containing the
applicant’s public key and other appropriate information.
Sending or posting the certificate. The CA sends the certificate to the applicant or
posts the certificate in a directory as appropriate.
How Certificates are Used
Certificates are used to generate confidence in the legitimacy of specific public keys. If an
entity trusts the issuer, then the entity can also have confidence that the public key contained in
the certificate belongs to the subject named in the certificate.
In an enterprise, the enterprise root CA is the most trusted CA. There can be more than one
enterprise root CA in a Windows 2000 domain, but there can be only one enterprise root CA
in any given hierarchy.
An organization should install an enterprise CA if it will be issuing certificates to users or
computers within the organization. It is not necessary to install a CA in every domain in the
organization. For example, users in a child domain can use a CA in a parent domain.
NOTE: An Active Directory and a DNS server must be running prior to installing an
Stand-alone CAs
An organization that will be issuing certificates to users or computers outside the organization
should install a stand-alone CA. There can be many stand-alone CAs, but there can be only
one stand-alone CA per hierarchy.
A stand-alone CA has a relatively simple default policy module and does not store any
information remotely. Therefore, a stand-alone CA does not need to have Microsoft
windows 2000 Active Directory available.
=====================================================================
wininf13.html PAGE 3 2002/04/06
Types of CAs
The setup requirements for the four types of CAs available from Certificate Services are
described in the following sections.
An enterprise root CA is the root of an organization’s CA hierarchy. An organization should
set up an enterprise root CA if the CA will be issuing certificates to users and computers
within the organization.
The enterprise root CA requires the following:
An enterprise subordinate CA is a CA that issues certificates within an organization but is
not the most trusted CA in that organization; it is subordinate in another CA in the hierarchy.
It must be associated with the CA that will process the subordinate CAs certificate requests.
Windows 2000 DNS service.
Windows 2000 Directory Service.
Administrative privileges on all servers.
Stand-Alone
A stand-alone root CA is the root of the CA trust hierarchy. The stand-alone root CA
requires administrative privileges on the local server. An organization should use this is they
are installing outside of the organization’s enterprise network, and the CA needs to be the
root CA.
=====================================================================
wininf13.html PAGE 4 2002/04/06
Stand-Alone Subordinate CA
A stand-alone subordinate CA is a CA that operates as a solitary certificate server or exists
in a CA trust hierarchy. An organization should set up a stand-alone subordinate CA when
it will be issuing certificates to entities outside the organization.
The stand-alone subordinate CA has the following requirements:
It must be associated with a CA that will process the subordinate CAs certificate requests.
This could be an external commercial CA.
Administrative privileges on the local server.
Certificate enrollment is the process of obtaining a digital certificate.
Lesson Summary:
Certificates enable users to use smart card logon, send encrypted e-mail, sign electronic
documents, and so on.
Certificates are issued, managed, renewed and revoked by CAs.
Lesson 2:
Installing and Configuring Certificate Authority
Deploying a CA
CAs will be installed during the following practice. The Certificate Services Installation
Wizard walks the administrator through the installation process.
Establishing a Windows 2000 domain. If an enterprise CA is to be deployed, establish a
domain before installing Certificate Services.
Active Directory integration. Information about CAs are written into an object in the
Active Directory during installation.
Selecting the host server. The root CA can run on any Windows 2000 Server platform,
including a domain controller.
Naming. CA names are bound into their certificates and hence cannot change.
Key generation. The CAs public-private key pair will be generated during the
installation process and is unique to this CA.
CA certificate. For a root CA, the installation process will automatically generate a
self-signed CA certificate using the CA’s public-private key pair.
Issuing Policy. The enterprise CA setup will automatically install and configure the
default enterprise policy module for the CA.
=====================================================================
wininf13.html PAGE 5 2002/04/06
After a root CA has been established, it is possible to install intermediate or issuing
CAs subordinate to this root CA.
Protecting a CA
CAs are high-value resources, and it is often desirable to provide them with a high
degree of protection.
Physical protection. Because CAs represent highly trusted entities within an enterprise,
they should be protected from tampering.
Key management. The CA’s private key provides the basis for trust in the certification
process and should be secured from tampering.
Restoration. Loss of a CA due to hardware failure, for example, can create a number
of administrative and operational problems and prevent revocation of existing certificates.
Certificate
Enrollment
The Windows 2000 PKI supports certificate enrollment to the Microsoft enterprise CA,
stand-alone CA, or third-party CAs.
Multiple Enrollment Methods
The PKI supports multiple enrollment methods, including Web-based enrollment, and
enrollment wizard, and policy-driven autoenrollment that occurs as part of a user’s
logon processing.
Web-based Enrollment
The Web-based enrollment process begins with a client submitting a certificate request
and ends with the installation of the certificate in the client applications.
Client Certificate Enrollment
Certificate Services supports client certificate enrollment using Internet Explorer version
3.0 or later.
=====================================================================
wininf13.html PAGE 6 2002/04/06
Automated Enrollment
The automated enrollment process is controlled by two key elements: certificate types
and autoenrollment objects. These are integrated with the Group Policy object and may
be defined on a site, domain, organizational unit (OU), computer, or user basis.
Cryptographic Key Storage
Within the Microsoft PKI, cryptographic keys and associated certificates are stored
and managed by the CrypotoAPI subsystem. There are 5 different PKI Certificate
Stores: MY, CA, TRUST, ROOT, and UserDS.
These are logical stores that can present a consistent, systemwide view of the available
certificates that may reside on multiple physical stores (hard disk, smart cards and so).
Certificate Renewal
Similar to enrollment, but takes advantage of the trust relationship inherent in an existing
certificate.
Renewal is of advantage primarily to the CA. A renewal request can presumably be
processed more efficiently because the existing certificate attributes do not need to be
verified again.
Certificate and Key Recovery
Public key pairs and certificates tend to have high value. If they are lost due to system
failure, their replacement may be time-consuming and result in monetary loss.
Roaming
Roaming in the context of this discussion means the ability to use the same public
key-based applications on different computers within the enterprise’s Windows
2000 environment.
=====================================================================
wininf13.html PAGE 7 2002/04/06
Hardware token devices, such as smart cards, support roaming, provided they
incorporate a physical certificate store.
Revocation
Certificates tend to be long-lived credentials. There are a number of reasons
these credentials may become untrustworthy prior to their expiration.
Trust
Certificate verification is of primary concern to clients using PK-clients applications.
If a given end-entity certificate can be shown in “chain” to a known trusted root CA,
and if the intended certificate usage is consistent with the application context, then it is
considered valid.
Trusted CA Roots
Trust in root CAs may be set by policy to establish trust relationships used by domain
clients in verifying PK certificates.
In addition to establishing a root CA as trusted, the administrator can set usage
properties associated with the CA. If specified, these restrict the purposes for
which the CA-issued certificates are valid. Currently, these provide a means of
restricting usage to any combination of the following:
Lesson Summary:
CAs are high-value resources and it is important to protect them.
To obtain a client certificate, the user opens the client authentication page and submits
identification information.
=====================================================================
wininf13.html PAGE 8 2002/04/06
Lesson 3:
Managing Certificates
Once you start issuing certificates, or clients request that you issue certificates,
management of them becomes an important issue.
Revoked Certificates
When a certificate is marked as revoked, it is moved to the Revoked Certificates folder.
The revoked certificate will appear on the CRL the next time it is published.
Issued Certificates. In the details pane, examine the certificate request by noting the
values for requester name, requester e-mail address, and other fields.
Pending Requests. Same type of information.
Failed Requests. Failed certificate requests should only occur when a member of the
Cert Publishers or Administrators groups denies a certificate request.
How a Certificate is Issued
When a certificate is presented to an entity as a means of identifying the certificate holder
(the subject to the certificate), it is useful only if the entity receiving the certificate trusts
the issuing.
Key generation. The individual or applicant requesting certification generates key pairs
of public and private key.
Matching or policy information. The CA determines what this information will be for
example, E-mail address tax ID number etc.
Sending of public keys and information. The applicant sends the public keys and
information to the CA. Often encrypted using the CAs public key.
Verification of information. The CA applies whatever policy rules it might require to
verify.
Certificate creation. The CA creates a digital document with the appropriate information.
Sending or posting of certificate. The CA may send the certificate to the applicant or
post it publicly.
=====================================================================
wininf13.html PAGE 9 2002/04/06
Certificate Revocation
Certificate authorities publish CRLs containing certificates that have been revoked by the
CA. CRLs provide a way of withdrawing a certificate after it has been issued. CRLs
are made available for downloading or online viewing by client applications.
To verify a certificate, all that is necessary is the public key of the CA and a check
against the revocation list published by that CA.
EFS Recovery Policy
Data recovery is available for the EFS as part of the overall security policy for the system.
EFS recovery policy specifies the data recovery agent accounts that are used within the
cope of the policy. EFS requires an encrypted data recovery agent policy before it can
be used, and uses a default recovery agent (the Administrator) if non has been chosen.
A recovery agent account is used to restore data for all computers covered by the policy.
If a user’s private key is lost, a file protected by that key can be backed up, and the
backup sent by means of secure e-mail to a recovery agent administrator. The
administrator restores the backup copy, opens it to read the file, copies the file in
laintext, and returns the plaintext file to the user using secure e-mail again.
Lesson Summary:
Certification Authority is a snap-in for the Microsoft Management Console.
Certificates revoked with the reason code Certificate Hold can be unrevoked. They
can also be left on Certificate Hold until they expires or have revocation reason code
changed.
Data recovery agent is available, and it is usually the Administrator.
CLASSROOM EXERCISES:
MCSE Exam—If you cannot communicate check the protocol TCP/UDP ports are
correct and the NAT editor, is it using the proper editor.
=====================================================================
wininf13.html PAGE 10 2002/04/06
NOTE: L2TP does not require a NAT editor. However, L2TP with IPSec cannot be
translated by the NAT. There cannot be a NAT editor for IPSec.
Refresh interval for WINS is 1/8th not ½ like the boot says.
Anyone can be a CA providing they have the proper permissions.
Review page 329 How Certificates are created, Mr. E. spent a lot of time on this
subject in class. The file created is the certreq.txt file.
Certificates are used to generate confidence in the legitimacy of specific public keys.
A certificate must be signed with the issuer’s private key; otherwise, it is not a certificate.
A stand-alone CA has a relatively simple default policy module and does not store any
information remotely. Think of them as a Profile.
The enterprise
translated by the NAT. There cannot be a NAT editor for IPSec.
domain trust model. A direct mapping between CA trust relationships and domain
trust relationships is not required.
Physical protection. Protect against tampering.
Key management. CSP cryptographic service provider.
Restoration. Loss of CA due to hardware failure. Ensure you have a current
backup.
Smart card is loaded with the CA information and is usually assigned for 1 year
before you need to renew it. Default expiry is 2 years.
Installing a stand-alone root CA, specify Certsrv.*
Cryptographic Key Storage: MY,CA,TRUST, ROOT, UserDS. These are logical
stores that can present a consistent, systemwide view of the available certificates that
may reside on multiple physical stores (hard disk, smart cards, and so on). By using
these services, applications can share certificates and are assured of consistent
operation under administrative policy.
=====================================================================
wininf13.html PAGE 11 2002/04/06
To simplify application development, the MY store maintains certificate properties
that indicate the CSP and key-set name for the associated private key. Once an
application has selected a certificate to use, it can use this information to obtain a CSP
context for the correct private key.
Recovery agent. A recovery agent account is used to restore data for all computers
covered by the policy. EFS requires an encrypted data recovery agent policy before it
can be used, and uses a default recovery agent account (the Administrator) if none has
been chosen. In a domain, only members of the Domain Admins group can designate
another account as the recovery agent account. A recovery agent account is used to
restore data for all computers covered by the policy.