PKI Infrastructure – Two Tiered Setup with Offline Root CA

19 Sep

I have been having to setup a lot of PKI infrastructures lately, sometimes related to the fact that customers want to use Internet Based Client Management in SCCM but dont have the PKI infrastructure to support it. There is a lot of good writeups on the web about setting these up but I made up my own doc that I use to set these things up in under an hour.

Install Root CA

  1. Build a new stand-alone root CA, not attached to domain, this server can have Server 2008 Standard Edition.
  2. Log on to the server as the administrator and install Certificate Services to create a stand-alone root certification authority.
  3. Install Certificate Authority service only, IIS is not needed.
  4. Create a new private key
  5. Ensure the common name for the CA is unique.
  6. Change the validity period for the CA’s certificate to 10 years.

Install Sub CA
Build new enterprise subordinate CA and add to domain. The OS on this server must be Server 2008 R2 Enterprise or Datacenter Edition.

Add the following role services
Certification Authority
Certification Authority Web Enrollment
Online Responder

Setup type is Enterprise, Subordinate CA, create a new key, Cryptographic service provider (CSP): RSA#Microsoft software Key Storage Provider
Key length: 2048, Hash algorithm SHA1. Certificate Request: Save a certificate to file and manually send it later. Server Authentication Certificate: Choose and assign a certificate for SSL later.

Save the certificate request to a file and manually copy it to the parent CA.
Save this file to the C drive, and copy to the C drive of the root CA.

We need to setup a CRL for the new offline Root CA and change the URL location of the certificate revocation list (CRL) distribution point to a location that is accessible to all users the network while the Root CA is offline. This is needed because the offline root CA’s default CRL Distribution Points (CDPs) are not accessible to users on the network and, if they are left unchanged, certificate revocation checking will fail.

On the Root CA, Open Certification Authority

Right click on the RootCA server name -> Properties -> -> Extensions tab -> extension type: CRL Distribution Point (CDP):

Mark the line begins with “LDAP”, and click ‘Include in the CDP extension of issued certificates’.

Make sure only the following boxes are checked:
1. Include in all CRLs. Specifies where to publish in Active Directory when publishing manually.
2. Include in the CDP extension of issues certificates.

Mark the line begins with “HTTP”, and click remove.

Mark the line begins with “file”, and click remove.

Click on Add -> on the location, put:

http://subcaservername/CertEnroll/<caname&gt; (continued on next line)

<crlnamesuffix><DeltaCRLAllowed>.crl

Tick the following:
1. Include in CRLs. Clients use this to find Delta CRL locations.
2. Include in the CDP extensions of issued certificates

Click on the line begins with “C:\Windows”, and make sure the only options checked are:
1. Publish CRLs to this location
2. Publish Delta CRLs to this location

Setup AIA information for the Offline Root CA, On the Extensions tab -> extension type: Authority Information Access (AIA):
Mark the line begins with “LDAP”, and tick the following box:
1. Include in the AIA extension of issues certificates

Mark the line begins with “HTTP”, and click remove.

Mark the line begins with “file”, and click remove.

Click on Add -> on the location, put:

http://subcaservername/ CertEnroll/<ServerDNSName>_<CAName><CertificateName>.crt .

Tick the following boxes:
1. Include in the AIA extension of issues certificates

Click OK and allow the CA server to restart its service

From the “Certification Authority” left pane, right click on “Revoked certificates”-> Properties:

CRL publication interval: 6 months

Make sure “Publish Delta CRLs” is not checked
Click OK

Setup the root CA to issue certificates with an expiry date of 10 years (will issue to the Sub CA for 10 years)
Run from the command prompt – certutil -setreg CA\ValidityPeriodUnits 10 & certutil -setreg CA\ValidityPeriod “Years”
Configure the offline root CA to support certificate revocation listing with Active Directory

On the Root CA, Log on to the system as a Certification Authority Administrator.

Open Command Prompt.

Type the following, and then press ENTER. – certutil -setreg ca\DSConfigDN “CN=Configuration,DC=contoso,DC=com” (replace with your own domain info)

Type the following, and then press ENTER. – certutil -setreg ca\DSDomainDN “DC=contoso,DC=com” ” (replace with your own domain info)

At the command prompt type net stop certsvc

At the command prompt type net start certsvc

From the “Certification Authority” left pane, right click on “Revoked certificates”-> All tasks -> Publish -> click OK

Manual steps to publish the Root CA CRL & AIA

Copy the CRL & CRT file to the Sub CA

On the Root CA, copy the files from C:\Windows\System32\CertSrv\CertEnroll to the same location on the Sub CA

Publish the CRL & Root CA certificate to Active Directory
For this to work, you need to be a member of the Enterprise Admins group. Information is published to CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com ” (except its your own domain info)

From the Sub CA, the two files you copied before (.CRT and .CRL need to be used for this)

Publish the Root certificate to AD – certutil -dspublish -f RootCACertificateFile.crt RootCA

Publish the CRL information to Active Directory – certutil –dspublish -f CACRLFile.crl

Issue the Sub CA a certificate from the Root CA server.

Right click on the RootCA server name -> All Tasks -> Submit new request -> locate the subordinate CA request file (.req) -> Open.
Expand the RootCA server name -> right click on “Pending Requests” -> locate the subordinate CA request ID according to the date -> right click on the request -> All Tasks -> Issue.

From the left pane, click on “Issued Certificates” -> locate the subordinate CA request ID –> double click on the request –> Click the details TAB –> Copy to file – Rootca.p7b -> click Save.

As an option only, on the SubCA, run the command below from command line to avoid offline CRL errors: Certutil.exe -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

On the Sub CA, from command prompt, run – gpupdate/force

Right click on the subordinate CA server name -> All Tasks -> “Install CA Certificate” -> locate the file Rootca.p7b -> click Open.

Right click on the subordinate CA server name -> All Tasks -> Start Service.

Start -> Administrative Tools -> Group Policy Management.
From the left pane, expand the forest name -> expand Domains -> expand the relevant domain name -> right click on “Default domain policy” -> Edit.
From the left pane, under “Computer Configuration” -> expand Policies -> expand “Windows Settings” -> expand “Security Settings” -> expand “Public Key Policies” -> right click on “Intermediate Certification Authorities” -> Import -> click Next -> click Browse to locate the CRT file from the subordinate CA server (C:\Windows\System32\certsrv\CertEnroll) -> click Open -> click Next twice -> click Finish -> click OK.

By default, IIS 7.0 request filtering blocks the plus sign (+), which is used in the URL of delta CRLs. To allow delta CRL retrieval, modify the IIS configuration by setting allowDoubleEscaping=true on the requestFiltering element in the system.web section of IIS configuration. For more information about IIS 7.0 request filter configuration, see IIS 7.0: Configure Request Filters in IIS 7.0.

appcmd set config /section:requestfiltering /allowdoubleescaping:true
Appcmd.exe can be found – %windir%\system32\inetsrv

In Certificate Authority, rightclick on the subCA and go to Properties. Go to the Extensions tab, in CDP modify the entry that begins with http and check the boxes as shown:

1. Include in CRLs. Client use this to find Delta CRL locations.
2. Include in the CDP extension of issued certificates

Next go the AIA dropdown, modify the entry that begins with http and check the box:
1. Include in the AIA extension of issues certificates

Start and Stop the Certsvc service.

Setup the Online Responder (This is optional)
Step 1
To advertise that revocation status information for a particular CA can be obtained via OCSP, the CA must include a pointer to the OCSP Responder in the certificate. This is done by adding an OCSP URI to the AIA extension of the certificate. This is a configuration made on the CA and will be applied to certificates issued by the CA.

1. Open the Certification Authority Snap-in on the CA, as an Enterprise Administrator

2. Right click on the CA name, and select Properties

3. Click on the Extension Tab. From the Select Extension drop down Box, select Authority Information Access (AIA). This is shown below. Add an entry for the online responder such as http:// yourwebserver/ocsp

4. Check the Checkbox for Include in the online certificate status protocol (OCSP) extension.

5. Click OK, to close the CA Properties.
Step Two
Configure Enterprise CA with OSCP Signing Template

1. On the Enterprise CA, select Certificate Templates, right click and select Manage. This will open a complete list of the CAs templates in the Certificate Template Console.

2. Locate the OCSP Certificate Template, Right-click, choose Duplicate Template and give it a name specific to your environment.

3. On the Security Tab, add the hostname of the soon to be OCSP Server, and give the server Read and Enroll permissions to the template. Click OK.

4. In the Certification Authority management console, Right-click on the Certificates Templates node, and from the context menu, select New and then “Certificate Template to issue.

5. Select the OCSP Response Signing Template, and select OK.
Step 3
1. Open the Online Responder snapin in Administrative Tools

2. Select Revocation Configuration, right click and select Add Revocation Configuration. A wizard will open.

3. Name the configuration with a friendly name

4. Select a certificate for an existing Enterprise CA

5. Select Browse CA certificate published in Active Directory. Click Browse. You should see your CA certificate so select it and click OK.

6. Next you will need to select a certificate that will be used for signing OCSP responses. For a particular Revocation Configuration, the OCSP Signing certificate must be issued by the CA for which the OCSP Responder will answer revocation status requests. Select Automatically select a signing certificate and select the OCSP template you configured in step two above. Click Next.

7. The OCSP responder will obtain its CRL from the CA so you do not have to add any other provider. Finish the wizard.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: