Part II Implementation Phases and Certificate Authority Installation
Chris here again. In Part I of this series we covered design considerations for implementing a PKI. In this part of the series I will cover the steps required to implement a PKI. We will cover the steps and build the configuration files we will use for implementing the PKI.
Here is a breakdown of the steps for implementing a PKI. The steps can vary somewhat, but below are my recommendations to help ensure that the actual implementation is painless.
Planning Phase
During the planning phase you document the requirements of your PKI.
You then take the requirements and translate them into a physical design.
Pre-Implementation Phase
During this phase you will build the configuration files. There are essentially two configuration files. One is the CAPolicy.inf file. The CAPolicy.inf file is used during the installation of Active Directory Certification Services (ADCS) and during the renewal of the CA certificate. In the CAPolicy.inf you will configure some basic settings for the CA.
The second configuration file is the Post-Installation script. Although not required, using a Post-Installation script will allow you to quickly configure the new CA. Also, since you can review the script before implementation, it helps alleviate any misconfiguration due to typos.
Testing Phase
This is the phase that is most often avoided and to be honest I am not quite sure why. I would recommend walking through the installation process of the CA hierarchy at least once if not multiple times in a test environment. With the rise of virtualization software (Hyper-V, VMWare) it is fairly easy to do testing, even with limited access to hardware. Testing the implementation not only will get you familiar with the installation process, but will also help you identify any potential issues with your installation steps. Also, during testing you can thoroughly document the steps that you will take during the installation in the production environment.
Implementation Phase
During this phase you will implement the actual CA hierarchy. The implementation phase would also include any configuration that needs to be done after ADCS is installed.
Walkthrough
I am going to walk through these phases with you, so you feel more comfortable with the process. In my walk through, we are going to be installing a PKI for a fictional company called Fabrikam.
Pre-Implementation Planning with Fabrikam
We met with Fabrikam and Fabrikam is interested in deploying a Public Key Infrastructure to be leveraged by a number of current and future projects. Fabrikam currently has its corporate offices located at one site, although the company is rapidly expanding and may add additional sites in the future. Fabrikam currently either uses certificates from Commercial Certification Authorities or has put on hold projects that require certificates until the internal PKI is put in place. We discussed the importance of having a secure PKI deployment.
We discussed with Fabrikam the fact that a Hardware Security Module (HSM) would provide stronger key protection then the protection offered by DPAPI. However, Fabrikam has decided at this point to forgo the use of an HSM, as they felt the use of an HSM was not a requirement for them. After some discussion it was determined that Fabrikam would deploy a two tier hierarchy which would provide key protection for the Root CA. If security requirements change Fabrikam will consider implementing Common Criteria Role Separation in the future to further increase the security of the CA and the Private Key.
To additionally increase the level of private key protection the root CA will be kept offline. The hard drive of the offline Root CA will be stored in a safe that only certain members of the security team have access to. Access to the safe is logged and monitored. This protects the private key of the Root CA. This also limits the ability of an attacker or malicious employee to create additional CAs from the key pair of the Root CA.
Fabrikam is also interested in having the ability to add additional Issuing CAs in the future. They want the flexibility to add more issuing CAs based on load or geography. To increase the level of manageability they would like all current and future issuing certificate authorities to chain up to the same Root CA (Trust Anchor).
In terms of certificates Fabrikam has a list of requirements that must be met. They have some third party applications and devices that can use Secure LDAP, and they would like to issue certificates to Domain Controllers to support those apps. Also, Fabrikam is looking to deploy Outlook Web Access and has several intranet sites that currently have SSL configured. Right now, Fabrikam purchases certificates for these web sites from a third-party and would like to move this process in house to save money. In the future, Fabrikam is also looking at other technologies that could benefit from the internal PKI such for protecting wireless networks, and enabling remote access for user through VPN. However, these are future initiatives and Fabrikam just needs the flexibility to issue certificates in the future to support these technologies.
Fabrikam has also decided that it would like the issuing CA to be valid for 5 years to limit the lifetime of the public/private key pair. They plan to renew with a new key pair at the 3 year mark. They have also decided with some consultation that they would like to limit the root CA certificate to being valid for 10 years and plan to renew with a new key pair at the 5 year mark.
We looked into the applications and network devices that Fabrikam currently uses and they all support key lengths of 4096 bits or less. Fabrikam is going to make it a requirement that all future applications and network devices support key lengths as large as 4096 bits.
For the Root CA, Fabrikam was looking for a compromise between security and manageability in terms of renewing the Root CRL. The security team wanted to renew the CRL for the Root CA every month and the operations team wanted to have the Root CA renewed once a year, to limit the number of times they needed to bring the Root CA online. Eventually a compromise was reach of publishing a new CRL for the root CA after every 6 months. Similar discussions were held for determining the CRL validity period for the Issuing CA. It was eventually determined that a base CRL would be valid for a week and delta CRLs would be valid for 2 hours. Microsoft warned Fabrikam that if there was a hardware failure on the CA, there would be certificate validation issues after 2 hours due to the Delta CRLs expiring. Fabrikam plan to have a process in place to perform offline CRL signing in case of a CA failure.
We also discussed placement of AIA and CDP paths. Most of Fabrikam’s systems are Windows domain joined clients. However, they would like to have the flexibility for third party Operating Systems to access the CDP and AIA locations. Based on this discussion we decided to publish CRLs and CA certificates to both Active Directory and to a web server.
After having the discussions with Fabrikam, we are ready to look at the business requirements and translate those requirements into the implementation steps.
Planning Phase walkthrough
After reviewing the business requirements, Fabrikam documented the following design and configuration.
PKI Configuration
Number of Tiers: 2
Number of CAs in each Tier: 1
Operating System Version: Windows 2008
Operating System Edition: Standalone Edition for the Offline Root CA and Enterprise Edition for the Enterprise CA
CA Type: Root CA will be Standalone. Issuing CA will be Enterprise.
CA Issuance: Domain Controller Authentication and Web Server
Private Key Protection: Root will be offline. No additional private key protection for Issuing CA.
Policy: No constraints will be defined.
Root CA Configuration
Validity Period for Root CA Certificate: 10 years
Key Length for CA Certificate: 4096 bits
Certificate Validity Period for issued Certificates: 5 years
AIA Locations: LDAP and HTTP
CDP Locations: LDAP and HTTP
CRL Validity: 26 Weeks
Delta CRLs: Delta CRLs will not be used
CA Name: Fabrikam Root CA
Issuing CA Configuration
Validity Period for Issuing CA Certificate: 5 years (determined by certificate validity period of root CA.)
Key Length for CA Certificate: 2048 bits
Certificate Validity Period for issued Certificates: 2 years
AIA Locations: LDAP and HTTP
CDP Locations: LDAP and HTTP
CRL Validity: 1 week
Delta CRLs Validity: 2 hours
CA Name: Fabrikam Issuing CA 1
Pre-installation Phase
In this phase we will be building our configuration files. Since we are building a two tier hierarchy with one CA in each tier, we will need the following configuration files.
Root CA
CAPolicy.inf
Post-Installation Configuration Script
Issuing CA
CAPolicy.inf
Post-Installation Configuration Script
Root CA CAPolicy.inf
The CAPolicy.inf file is fairly straightforward. It is simply an .INF file consisting of named sections containing keys associated with some data. The only required section is [Version]. Then we have the [Certsrv_Server] section which specifies certain CA settings, most of which only apply when renewing the CA certificate. The initial CA configuration will be defined when the ADCS role is installed, but in the future the settings specified in the CAPolicy.inf file will be used. We also specify an empty CDP and AIA location by listing the [CRLDistributionPoint] and [AuthorityInformationAccess] sections with no values. These empty CDP and AIA values are not required in Windows Server 2008 since the installation of a Root CA will omit these extensions by default. However, in Windows Server 2003 you would have to specify these sections in order to omit these extensions from your Root CA Certificate.
[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
[CRLDistributionPoint]
[AuthorityInformationAccess]
Root CA Post-Installation Configuration Script
The Post-Installation script I am using is based on the one provided in the Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure. If you are looking to deploy a PKI this is a must read, and goes in to greater depth then this blog series. Below is the Post-Installation configurations script that I will be using:
You will have to modify line 1 of the script to reflect your forest root domain name. For our environment the line is modified to:
SET myADnamingcontext=DC=fabrikam,DC=com
In line 2 we set the DSConfigDN setting, which is used by the CA to build the LDAP paths for the AIA and CDP location.
In lines 3-6 we configure the CRL publication options.
Before we look at this section of the script, we first need to understand the options, variables, and structure of this command. So, clearly the command certutil –setreg CA\CRLPublicationURLs is going to set locations for publishing CRLs.
The format is
:
. Multiple publication locations are separated by \n.
The Publication Option includes a number that maps to the options that are configured in the GUI. For CDP there are the following options as outlined in the table below. Each option is represented by a number, and the list of all options selected is represented by the combined total of their option numbers. This total value is what is placed in the CRLPublicationURLs publication options value.
Option Number
|
Option
|
0
|
No Options Defined
|
1
|
Publish CRLs to this location
|
2
|
Include in the CDP extensions of issued certificates
|
4
|
Include in CRLS. Clients use this to find Delta CRL Locations
|
8
|
Include in all CRLs. Specifies where to publish in the Active Directory when publishing manually.
|
64
|
Publish Delta CRLs to this location
|
128
|
Include in the IDP extension of issued CRLs
|
There are also variables that can be included in the publication location. Variables are preferred over hard coded values, due to some issues that can arise with hard coded values. For example, customers that hardcode these URLs frequently leave off the variable that represents the index value of the CA certificate’s private key (%4). As a result, and after a CA certificate is renewed, publishing the CRL signed by the second private key overwrites the CRL signed by the first private key because the index that would differentiate the filename has been omitted.
Below is a table that explains these variables:
Variable
|
Variable Display Name in the CertSrv MMC
|
Description
|
%1
|
|
The DNS name of the certification authority server
|
%2
|
|
The NetBIOS name of the certification authority server
|
%3
|
|
The name of the Certificate Authority
|
%4
|
|
The renewal extension of the certification authority
|
%6
|
|
The location of the Configuration container in Active Directory
|
%7
|
|
The "sanitized" name of the certification authority, truncated to 32 characters with a hash on the end
|
%8
|
|
Inserts a name suffix at the end of the file name when publishing a CRL to a file or URL location
|
%9
|
|
When a delta CRL is published, this replaces the CRLNameSuffix with a separate suffix to distinguish the delta CRL
|
%10
|
|
The object class identifier for CRL distribution points, used when publishing to an LDAP URL
|
%11
|
|
The object class identifier for a certification authority, used when publishing to an LDAP URL
|
*Descriptions were taken from the following online document: Specify certificate revocation list distribution points in issued certificates, which is located at http://technet.microsoft.com/en-us/library/cc773036(WS.10).aspx
So for example from line 4 of the configuration script we have the following:
1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\
This translates to the following:
1. Publish CRLs to %WINDIR%\System32\CertSrv\CertEnroll\ directory.
2. The filename of the CRL will be the name of the CA + a CRL name suffix + a “+” character if the file represents a CRL.
3. Note that the only publication option set by this string instructs the CA to write the CRL to the specified location. This location will not appear in the actual certificates issued by the CA because that option was not specified.
Understanding the variables and options not only allows you to understand what the script does, but also how to modify the script. It also allows you to understand the configuration when reviewing the Certificate Authorities configuration in the registry.
In my example, I am happy with the default settings, so I am going to leave them in the default.
On lines 7 through 9 of the script we define publication options for the CA certificate, commonly referred to as Authority Information Access.
In interpreting the variables in the script you can use the Variable Table we used previously to decode the script or to encode your desired setting. However, since we will not be using any of the CRL related variables, only a subset of the options are available when working with AIA, they are outlined in the table below:
Variable
|
Variable Display Name in the CertSrv MMC
|
Description
|
%1
|
|
The DNS name of the certification authority server
|
%2
|
|
The NetBIOS name of the certification authority server
|
%3
|
|
The name of the Certificate Authority
|
%4
|
|
The renewal extension of the certification authority
|
%6
|
|
The location of the Configuration container in Active Directory
|
%7
|
|
The "sanitized" name of the certification authority, truncated to 32 characters with a hash on the end
|
%11
|
|
The object class identifier for a certification authority, used when publishing to an LDAP URL
|
When setting AIA publication, a different, smaller set of Options is available":
Option Number
|
|
0
|
Not Defined
|
1
|
Automatically Publish CA Certificate to this location
|
2
|
Include in the AIA extension of issued certificates
|
32
|
Include in the online certificate status protocol (OCSP) extension
|
As an example on line 8 we have the following:
1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt
This translates to:
1. Publish the CA Certificate to %WINDIR%\system32\CertSrv\CertEnroll
2. The file name of the CA certificate will be _ with the renewal extension of the Certificate Authority.
3. As with the CRL, the option specified indicates only that the CA should write the CA certificate to this location. This location will not be included in the AIA extension of certificates issued by this CA since that option was not specified.
Next, on lines 10 and 11 we have the following:
certutil -setreg CA\CRLPeriodUnits 180
certutil -setreg CA\CRLPeriod "Days"
These set the CRL Validity and Publishing period 180 days or roughly six months.
Then on line 12 we have the following:
certutil -setreg CA\CRLDeltaPeriodUnits 0
This means that Delta CRLs will not be published because the publication period is zero.
Next, on lines 13 and 14 we have the following:
certutil -setreg ca\ValidityPeriodUnits 10
certutil -setreg ca\ValidityPeriod "Years"
These settings define the maximum validity period for certificates issued by the CA. Since this is a Root CA and only Subordinate CA certificates are going to be issued, this would be the validity period for the Subordinate CA certificate. In my case I only want my Subordinate CA to be valid for 5 years so I am going to change the entry in line 13 to reflect that, with the following change:
certutil -setreg ca\ValidityPeriodUnits 5
Then on line 15 we stop and start certificate services. We do that so that the new configuration can be read by the certificate authority:
net stop certsvc & net start certsvc
On line 16 we ensure that the CertEnroll share is created, and if IIS is installed, that the CertSrv virtual directory is installed.
certutil –vroot
Finally, on line 17 we publish a new CRL:
certutil -CRL
So now we are done with the post-installation configuration script. The reason for understanding this script is so that you validate the values in the sample script are the ones you want implemented on your CA. If not, you can of course modify the sample script or create your own. The reason for using the sample script on the Root CA is that you validate all of the settings prior to implementing them. Also, if you are going to test your installation in a test environment, you can run this script and verify you get the results you are expecting. This will help eliminate any surprises you may have when implementing the Root CA in production.
Issuing CA CAPolicy.inf
The CAPolicy.inf file for my Issuing CA is fairly straight forward. You can actually configure quite a bit with these configuration files. Jonathan Stephens will be posting a blog on all of the settings that can be configured with the CAPolicy.inf file, so stay tuned. However, the PKI I am setting up is pretty straightforward, so I am only going to specify the Renewal Key Length, Renewal Validity, and direct the CA to not load the default certificate templates. The reason for not deploying the default certificate templates is that machines and users will be able to begin enrolling for the default templates if they have access once the installation of the CA is complete. In my case I want to make sure that I setup my templates to meet my business requirements before users and machines can enroll for certificates. The LoadDefaultTemplates setting works on Windows 2003 Root Enterprise CAs, Windows 2008 Root CAs, and Windows 2008 Subordinate CAs.
[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
LoadDefaultTemplates=0
Issuing CA Post-Installation Configuration Script
The post-installation script I am using is based on the one in Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure. I am not going to go in as much detail for this script, since I covered all of the settings for the Root CA. Below is the script I will be using:
certutil -setreg CA\CRLPublicationURLs "65:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n6:http://FCCA01.FOURTHCOFFEE.COM/certenroll/%%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10"
certutil -setreg CA\CACertPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://FCCA01.FOURTHCOFFEE.COM/certenroll/%%1_%%3%%4.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11"
certutil -setreg CA\CRLPeriodUnits 7
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\DeltaCRLPeriodUnits 2
certutil -setreg CA\DelatCRLPeriod "Hours"
net stop certsvc & net start certsvc
certutil.exe -vroot
certutil -CRL
Lines 1-8 of the script will Configure CRL and AIA publication. You can use the tables in the previous section to determine if these are configured to meet your requirements. After examining the CDP and AIA publishing, the settings in the script happen to match the requirements of my environment.
In lines 9 and 10 we configure the validity period and publication interval for the Base CRL. In my environment, my requirement is publication once a week. So, I will change line 10 to reflect this (Since this setting is used in combination with the certutil -setreg CA\CRLPeriod "Days" the resulting period will be seven days):
certutil -setreg CA\CRLPeriodUnits 7
After line 10 I am going to add two additional lines to configure my delta CRL publication so that a new delta CRL is published every two hours:
Certutil –setreg CA\DeltaCRLPeriodUnits 2
Certutil –setreg CA\DeltaCRLPeriod “Hours”
PKI Installation Walkthrough
Root CA Install
1. Copy CAPolicy.inf to the c:\Windows directory.
2. Start Server Manager and select Roles. In the Roles section click on Add Roles.
3. This will start the Add Roles Wizard, click Next.
4. On the Select Server Roles page of the wizard, select Active Directory Certificate Services and click Next.
5. On the Introduction to Active Directory Certificate Services page, click Next.
6. On the Select Role Services page, select Certification Authority, and click Next.
7. On the Specify Setup Type page, make sure Standalone is selected, and click Next.
8. On the Specify CA Type, select Root CA, and click Next.
9. On the Set Up Private Key page of the wizard, and make sure Create a new private key is selected and click Next.
10. On the Configure Cryptography for CA, you can select the CSP or KSP you wish to use, the Key Length for the Root Certification Authorities key, and the hash algorithm. Due to the business requirements of Fabrikam, I will be using the RSA Microsoft Software Key Storage Provider KSP, a key length of 4096 bits, and the SHA1 algorithm. (Check to determine supportability of stronger hash algorithms.) When finished click Next.
11. On the Configure CA Name page enter the Common Name for the CA and the name suffix.
12. When setting up the PKI for Fabrikam we are going to use Fabrikam Root Certification Authority for the Common Name and O=Fabrikam,C=US for the name suffix.
13. When complete, click Next.
14. On the Set Validity Period of the wizard, select the validity for the Root CA Certificate. As specified at the beginning of this post, Fabrikam is using a validity period of 10 years for the Root CA. Once complete, click Next to continue the wizard.
15. On the Configure Certificate Database page, select the locations for the Certificate Services Database and logs. Fabrikam will be using the default file paths. Select Next, when complete.
16. The Confirm Installation Selection page will summarize your selections. Review this information and then click Install.
17. Once setup is complete, run the post-installation configuration script. Review the settings to determine they are set to your specifications.
18. Copy the CRL and CRT files from c:\windows\system32\certsrv\certenroll to a Floppy or other removable media.
19. Logon to the machine that will become the Enterprise CA. Attach the removable media. Run the following command to publish the Root CA Certificate to Active Directory: certutil –f –dspublish RootCA.
20. Then publish the CRL from the Root CA to Active Directory with the following command: certutil –f –dspublish .
21. Wait sufficient time for replication to complete within your site.
22. Run certutil –pulse. Running this command will trigger autoenrollment and the Root CAs Certificate and CRL will be downloaded automatically to the Trusted Root Certification Authority store on the local machine.
Issuing CA Installation
1. Copy the CAPolicy.inf file to the c:\Windows directory.
2. Start Server Manager and select Roles. In the Roles section click on Add Roles.
3. This will start the Add Roles Wizard, click Next.
4. On the Select Server Roles page of the wizard select Active Directory Certificate Services and click Next.
5. On the Introduction to Active Directory Certificate Services page, click Next.
6. Part of the business requirements of Fabrikam is to have Web Enrollment available. As part of the plan we decided to install Web Enrollment on the Issuing CA, and in this way we could use it as the HTTP repository for CRLs and CA Certificates as well. If you wish to use the same approach, on the Select Role Services page, select Certification Authority and Certification Authority Web Enrollment, and click Next.
7. You will then be prompted to add the additional IIS role services required to run Web Enrollment. Click on Add Required Role Services.
8. On the Specify Setup Type page, select Enterprise, and click Next. Note: If you see the Enterprise option grayed out, that is an indication that the computer is not joined to the domain or you are not logged in with Enterprise Admin credentials.
9. On the Specify CA Type page, select Subordinate CA, and click Next.
10. On the Setup Private Key page, select Create a new private key, and click Next.
11. On the Configure Cryptography for CA, you can select the CSP or KSP you wish to use, the Key Length for the Issuing Certification Authorities key, and the hash algorithm. Due to the business requirements of Fabrikam, I will be using the RSA Microsoft Software Key Storage Provider KSP, a key length of 2048 bits, and the SHA1 algorithm. (Check to determine supportability of stronger hash algorithms.) When finished click Next.
12. On the Configure CA Name, enter the Common Name for the Issuing CA. The distinguished name should already be poplulated with the DN of the domain in which you are installing the CA. Fabrikam has the Common name set as “Fabrikam Issuing Certification Authority”, and the DN of course is set to DC=Fabrikam,DC=com. When finished click Next.
13. On the Request Certificate from a Parent CA, select Save a certificate request to file and manually send it later to a parent CA. Then click the Browse button, navigate to Removable Media, enter a file name for the request, and click Save. Then click Next.
14. On the Configure Certificate Database page, select the locations for the Certificate Services Database and logs. Fabrikam will be using the default file paths. Select Next, when complete.
15. On the Web Server (IIS) page, click Next.
16. On the Select Role Services page of the wizard, click Next.
17. On the Confirm Installation Selections, select Install.
18. You will then be prompted with the Installation Results. The results will indicate that installation is not complete because you still need to submit the request to the Root CA and then install the resulting certificate. Click Close to acknowledge the results.
19. Take the removable media that you saved the request to and connect it to the Root CA. In the Certificate Services MMC (certsrv.msc) on the Root CA, select the root node (CA Name), right click, then select All Tasks, then Submit new request…, from the context menus.
20. Browse to the request file and then select Open.
21. The request will now be pending. Navigate to the Pending Request Folder and locate the request. Right click on the request, select All Tasks, and then Issue.
22. Navigate to the Issued Certificates folder. Locate the certificate for the Issuing CA, Right click on the certificate and select Open. This will open the Certificate Properties. Select the Details tab, then click on the Copy to File… button.
23. This will open the Certificate Export Wizard, click Next.
24. Select DER encoded binary X.509 (.CER) and click Next.
25. Click Browse…
26. Navigate to Removable Media, enter a name for the certificate and then click Save.
27. Then click Next.
28. Then click Finish.
29. You will be prompted that The export was successful. Click OK to acknowledge.
30. Open the Certification Authority MMC on the Issuing CA. Right click on the Root Node (CA Name), select All Tasks, and Start Service.
31. You will then be asked if you would like to install the CA Certificate, click Yes.
32. Insert the removable media that contains the CA Certificate for the issuing CA. Browse to the certificate, and select Open.
33. Next run the Post Installation Configuration Script and review the configuration to ensure that it meets your requirements.
Conclusion
In this installment we covered the requirements for a sample PKI deployment. We covered configuring the CAPolicy.inf and Post Configuration script. In Part III of this series I will cover a sample configuration and setup of Certificate Templates.
- Chris “Duuuuude” Delay
SET myADnamingcontext=DC=fourthcoffee,DC=com
certutil.exe -setreg ca\DSConfigDN "CN=Configuration,%myADnamingcontext%"
certutil -setreg CA\CRLPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n2:http://FCCA01.fourthcoffee.com/certenroll/%%3%%8%%9.crl\n10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10"
certutil -setreg CA\CACertPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://FCCA01.fourthcoffee.com/certenroll/%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11"
certutil -setreg CA\CRLPeriodUnits 180
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg ca\ValidityPeriodUnits 5
certutil -setreg ca\ValidityPeriod "Years"
net stop certsvc & net start certsvc
certutil -vroot
certutil -CRL
| 