2. How SSL Works
Both
SSL (Secure Sockets Layer) and TLS (Transport Layer Security), which is
replacing SSL, are cryptographic protocols providing security and data
integrity for communications over TCP/IP (Transmission Control
Protocol/Internet Protocol). SSL encrypts the segments of the Transport
layer protocol, which is Layer 4 of the Open Systems Interconnection
(OSI) model. An SSL client and server negotiate a stateful connection
by using a handshaking procedure. During this handshake, the client and
server agree on various parameters used to establish the connection’s
security:
The initiation of the secure session begins when a client connects to an SSL-enabled server requesting a secure connection.
The server then picks the strongest cipher and hash function that it supports, and notifies the client of the decision.
The
server sends back its identification in the form of a digital
certificate, which contains the server name, the trusted Certificate
Authority, and the server’s public encryption key.
The
client may contact the server that issued the certificate (the trusted
CA, as before) and confirm the certificate is authentic before
proceeding:
In order to generate
the session keys used for the secure connection, the client encrypts a
random number with the server’s public key, and sends the result to the
server. Only the server can decrypt it (with its private key). This is
the one fact that makes the keys hidden from third parties, because
only the server and the client have access to this data.
From the random number, both parties generate key material for encryption and decryption.
This
concludes the handshake and begins the secured connection, which is
encrypted and decrypted with the key material until the connection
closes. If any one of the preceding processes fails, the SSL handshake
fails and the connection is not created.
TLS and SSL have a variety of security measures:
The
client may use the Certificate Authority’s public key to validate the
CA’s digital signature on the server certificate. If the digital
signature can be verified, the client accepts the server certificate as
a valid certificate issued by a trusted CA.
The client verifies that the issuing CA is on its list of trusted CAs.
The
client checks the server’s certificate validity period. The
authentication process stops if the current date and time fall outside
of the validity period.
Protection is provided against a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite.
All
the application records are numbered with a sequence number. Using this
sequence number in the message authentication codes (MACs) provides
additional security.
The message digest is enhanced with a key, so only a key holder can check the MAC, as specified in RFC 2104. (TLS only.)
The message that ends the handshake (Finished) sends a hash of all the exchanged handshake messages seen by both parties.
The
pseudorandom function splits the input data in half and processes each
one with a different hashing algorithm (MD5 and SHA1). It then XORs
them together to create the MAC. This provides protection even if one
of these algorithms is found vulnerable. (TLS only.)
SSL
v3 improved upon SSL v2 by adding SHA1-based ciphers and support for
certificate authentication. Additional improvements in SSL v3 include
better handshake protocol flow and increased resistance to
man-in-the-middle attacks.
3. Establishing a PKI
Microsoft
provides native support for PKI in Windows Server 2003 and 2008 Active
Directory. If you are running Windows 2000 Active Directory, special
considerations are necessary because you must upgrade the schema to the
Windows Server 2003 schema. This requires Windows 2000 domain
controllers to be on SP 3 at a minimum.
With
Microsoft Windows 2003 or 2008 Active Directory, the only configuration
required for an Enterprise CA is if you have an Active Directory forest
with multiple domains. In this scenario, you must add the CA’s computer
account to each domain’s built-in Cert Publishers local group.
Configuration Manager Certificate Requirements
There
are multiple certificate requirements for ConfigMgr to leverage PKI. If
you already have a PKI in place in the organization, you must verify it
meets the ConfigMgr requirements:
The PKI Root CA is running on the Enterprise or Datacenter edition of Windows Server 2003 or 2008.
Systems in any domain in the forest can recognize the Root CA as being trusted.
The site servers, site systems, computers, and devices must all have a certificate from the CA.
Certificates
for the site servers, site systems, computers, and devices must reside
in the personal store in the computer certificate store.
Clients must have a copy before they can accept the policies from the management point that is signed with this certificate.
Primary site servers cannot support key lengths greater than 8,096 bits.
Site systems do not have a published maximum key length.
Both computers and mobile device clients cannot support key lengths greater than 2,048 bits.
Caution: Encryption Key Length
Older
network components used to have issues handling 2,048-bit (and higher)
encrypted traffic. Although this is no longer an issue with today’s
hardware, issues may still arise with some technologies. With IBCM
being a focus of certificate usage, unknown home and Internet service
provider (ISP) networks will need to support whatever key length you
choose. Validate the bit length you are using will traverse all network
mediums in your environment before rolling out to all systems.
If
your organization does not have a PKI, it must determine what the
architecture for the CA will look like, how many tiers it will have,
what security measures will be put in place, the types of certificates
it will issue, and whether the CA is published via AD or through a
website. Microsoft provides valuable systematic guides for deploying
certificates in the following environments:
When
establishing a CA, it is best to use Windows Enterprise edition due to
its advanced features not available in other versions of the OS. The
issuance of version 2 certificate templates, private key archival, and
role separation enforcement are only available when Certificate
Services is installed on Windows Enterprise edition or Datacenter
edition, the latter not being cost effective in most cases. You will
need to issue certificates based off modified version 2 templates.
To
install Certificate Services, execute the following steps on Windows
Server 2003. Log on as a member of the Enterprise Admins security group
with local Administrator rights on the server where the install is
being performed. Then follow these steps:
1. | From the Start menu, select Control Panel and then click Add or Remove Programs.
|
2. | In the Add or Remove Programs window, click Add/Remove Windows Components.
|
3. | Scroll down and check the Certificate Services box.
|
4. | You
also want to check the Application Server box, because this will open
the details selection for that component. Verify that IIS (Internet
Information Services) is selected and then click OK.
|
5. | In
the Microsoft Certificate Services dialog box, click Yes to the warning
about not changing domain membership after Certificate Services is
installed.
|
6. | Click the Certificate Services Web Enrollment Support subcomponent.
|
7. | Click OK and then click Next.
|
8. | On
the CA Type page, click Enterprise Root CA, check the Use Custom
Settings to Generate the Key Pair and CA Certificate box, and then
click Next.
|
9. | On the Public and Private Key Pair page, set the following options:
- CSP— Microsoft Strong Cryptographic Service Provider
- Allow the CSP to interact with the desktop— Disabled
- Hash algorithm— SHA-1
- Key length— 2,048
|
10. | On the Public and Private Key Pair page, click Next.
|
11. | On the CA Identifying Information page, enter the following information:
- Common Name for this CA— ServerName
- Distinguished name suffix— DC=mydomain,DC=com
- Validity Period— 5 Years
|
12. | On the CA Identifying Information page, click Next.
|
13. | On the Certificate Database Settings page, accept the default settings and click Next.
|
14. | Click
Yes on the Microsoft Certificate Services dialog box informing you
Active Server Pages must be enabled on IIS if you wish to use the
Certificate Services Web enrollment site.
|
15. | In the Microsoft Certificate Services dialog box, click Yes to create the necessary folders.
|
16. | If prompted, insert the Windows Server 2003 Enterprise Edition CD in the CD-ROM drive and choose the \i386 folder.
If prompted to insert the CD for the i386 folder, ensure you reapply
whatever service pack the OS is running after installing Certificate
Services.
|
17. | If prompted with a dialog box informing you Internet Information Services must be temporarily stopped, click Yes.
|
18. | On the Completing the Windows Components Wizard page, click Finish.
|
To
install Certificate Services, execute the following steps on Windows
Server 2008. You must be logged on as a member of the Enterprise Admins
security group with local Administrator rights on the server where the
install is being performed.
1. | Open Server Manager, click Add Roles, and click Next.
|
2. | Click Active Directory Certificate Services and then click Next two times.
|
3. | On the Select Role Services page, click Certification Authority and then click Next.
|
4. | On the Specify Setup Type page, click Enterprise and then click Next.
|
5. | On the Specify CA Type page, click Subordinate CA and then click Next.
|
6. | On the Set Up Private Key page, click Create a new private key. Click Next.
|
7. | On the Configure Cryptography page, select a cryptographic service provider, key length, and hash algorithm. Click Next.
|
8. | On
the Request Certificate page, browse to locate the root CA (if the root
CA is not connected to the network, save the certificate request to a
file so that it can be processed later). Click Next.
|
9. | On the Configure CA Name page, create a unique name to identify the CA. Click Next.
|
10. | On the Set Validity Period page, specify the number of years or months that the CA certificate will be valid. Click Next.
|
11. | On
the Configure Certificate Database page, accept the default locations
or specify a custom location for the certificate database and
certificate database log. Click Next.
|
12. | On
the Confirm Installation Options page, review all the configuration
settings you have selected. If you want to accept these options, click
Install and wait until the setup process has finished.
|
Deploying PKI for ConfigMgr Native Mode
If you are deploying PKI for native mode, verify the following items:
1. | Confirm your PKI can support the various certificates required by Configuration Manager 2007 .
|
2. | Ensure
the following computers in the Configuration Manager 2007 site have a
trusted root Certificate Authority in common and intermediate
Certificate Authorities as needed:
The site server Management
points (the default management point, proxy management point,
Internet-based management point, and network load balanced management
points) Distribution points Software update points State migration points All client computers and mobile client devices
|
3. | If you will use a Certificate Revocation List (CRL), publish it where all computers can locate it.
|
4. | Deploy the site server signing certificate to the site server, and determine how clients will retrieve it.
|
5. | Deploy the web server certificates to the following site systems and then configure IIS with the certificates:
Management
points (the default management point, proxy management point,
Internet-based management point, and network load balanced management
points) Distribution points Software update points State migration points
|
6. | This
step is optional but recommended. On the site systems with the deployed
web server certificates, create or modify a Certificate Trust List
(CTL) in IIS to contain the root Certificate Authorities used by
clients.
|
7. | Deploy client certificates to clients and management points.
|
8. | If you have mobile client devices, deploy the client device certificates.
|
9. | If you are using the Operating System Deployment feature, perform the following tasks:
Export
root CA certificates that operating system clients will use during the
deployment process so these can be imported into the Configuration
Management console as a site setting. Prepare
and export one or more client certificates into a PKCS #12 file so that
these can be included in the operating system deployment.
|
