This exercise creates a stand alone root CA invisible to the organization because it is not part of the corporate network. It is the subordinate server acting as a stand alone subordiante CA that will be visible on the network, and to users and customers. The subordinate server manages the certificate process, including issuance and revocation. The strength of this hierarchy lies in the preparation and maintenance of the servers.
The High Encryption Pack must be installed. It will provide the additional cryptographic service provider (CSP) option.
With the High Encryption Pack installed, the additional cryptographic service provider (CSP) option exists.
Key length
box, increase the number from the default of 1024
to 4096.
In this step the identity of the certifying authority and its lifespan are configured.
In configuring the identity of the certifying authority one must plan this in advance because this name cannot be changed. The identity should be considered to be permanent.
Configure the certifying authority accordingly, and ensure that the electronic mail address is not likely to change during the declared service life.
The declared value of the lifespan affects the serviceability of the certificate server. This is because the root CA can only issue certificates that have a lifespan less than the root, which is true for the entire hierarchy, if implemented. Therefore, if the root CA is configured with a ten year lifespan, and the subordinate certifying authorities are configured with a five year lifespan, the users can employ the certificate services for less than five years. If the PKI deployment takes two years to fully deploy, users have even less time to use the service.
Certifying authorities may be renewed and the lifespan subsequently changed, but this requires administration. Keep administration to a minimum to decrease the opportunity of service interruption due to human intervention or accident.
Decisions made by the deployment team are important. Aggregate security requirements must be known, declared, and put in writing before putting the service into live production.
The certifying authority is being created. The root certificate is self signed by the root CA.
Backup and restore of the CA is directed against the folder declared in the Shared folder box.
The wizard will proceed to the Data Storage Location.
Internet Information Services will be halted and restarted as the Windows Components Wizard proceeds.
The certifying authority can now issue certificates to users. Before proceeding, locations of the Certificate Revocation List (CRL) and Authority Information Access (AIA) need to be specified. Strong PKI applications verify these locations first to check the status of certificate revocation and public key download. These should be installed on the root CA computer, which will not be shut down because its uptime is considered a priority.
The green check mark indicates that the service is running.
Because the root CA computer is essentially invisible to the network, the CRL and CRT files are manually copied to the Web server. The name of the Web server is used in this example. However, a DNS name is preferred for production because a change in the Web server computer name would break the PKI.
If the root CA server is also the CRL distribution point,
to have the location of the CRL distribution point in the self-signed
certificate for the root CA, create the root CA by using a Capolicy.inf
file.
This is also necessary for setting a certification practice statement URL in the root CA
certificate. Capolicy.inf
is placed in the \winnt
directory,
and looks similar to the following code:
[Version]
Signature= "$Windows NT$"
[CAPolicy]
Policies = LegalPolicy, LimitedUsePolicy, ExtraPolicy, OIDPolicy
[LegalPolicy]
OID = 1.2.3.4.5.6.7.22.43
Notice = "Legal policy statement text."
[LimitedUsePolicy]
OID = 1.2.3.4.5.6.7.22.47
URL = "http://http.site.com/somewhere/default.asp"
URL = "ftp://ftp.site.com/somewhereelse/default.asp"
Notice = "Limited use policy statement text."
URL = "ldap://ldap.site.com/some where else again/default.asp"
[ExtraPolicy]
OID = 1.2.3.4.5.6.7.22.53
URL = http://extra.site.com/Extra Policy/default.asp
[oidpolicy]
OID = 1.2.3.4.5.6.7.22.55
Publishing the root certificate to Active Directory is now ready. Once this step is complete, the path to the top of the certificate hierarchy msut be set.
System uptime from this point forward is crucial because the trust will be broken if the root CA cannot be accessed.
To publish, run Dsstore.exe
from the Windows 2000 Server Resource Kit.
The following command line is used.
dsstore.exe DC=toys,DC=com –addroot ROOTCA.CRT "Toys ROOT CA"
Note that the variable identifiers are in uppercase.
During full deployment, replication must be complete before the certificate is available across the entire domain. The DSSTORE –pulse switch can accelerate this process.
Root authorities differ from subordinate authorities in that subordinates store CRL and Authority Information Access in Active Directory, which enables a Lightweight Directory Access Protocol (LDAP) query.
The process of installing a subordinate CA is similar to installing the root, and is identical for every subordinate to be created. Online authorities will use the offline root to sign the certificates they make available to the enterprise.
Again, the identification should be planned in advance. The lifespan is determined by the root authority, and is one year by default. The certificates can be renewed. The one year default might be appropriate for a high security requirement. If this is not the case, the default lifespan can be modified by changing the following registry value on the root CA computer.
HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\name of
the root CA\ValidityPeriod
After the registry value has been changed, cycle the certificate service.
The wizard will proceed to the Data Storage Location.
There is an option to store configuration information in a shared folder. If this option is exercised, the specific computer should also have a maximum uptime goal.
There are two options to have the subordinate certificate signed by the root. One is to send the request directly to the root. The other is to create a file for the root to process. For this exercise, create a file for the root to process because the root CA is not available on the network.
The wizard will then state that the installation process is complete and that the service will be available when the certificate is processed and installed.
The Completing the Windows Components Wizard page appears.
To get the subordinate certificate request signed by the root, one can access the root computer directly by using the following procedure:
Select a task
list.
Base 64 files are encoded, not encrypted. Although base 64 files provide a foundation for encryption, base 64 encoders and decoders are readily available.
The following message will appear.
An administrator can issue or deny the pending request. In a live production environment, always run the request against a registration authority to guarantee the authenticity of the request.
Select a task
list.
The certificate is issued, and it can be retrieved from a downloadable certification path and copied to a floppy disk. In a live production setting, the floppy disk can be hand-delivered to remote sites as needed.
From this point forward, one can add subordinate CAs under the subordinate of the root. The installation process is identical to installations covered thus far. The process is simplified because one can sign certificates from the online certifying authority.
It is vitally important to keep the online CA running at all times and serviced only by trusted operations personnel. Although file, print, and Web servers and services are often subject to change, the same should not be true for the certificate server is down the certificate hierarchy is compromised. Advanced preparation tasks will reduce this risk to a minimum.
Congratulations! You have successfully to set up a certificate hierarchy!