Microsoft PKI Planning and Deploying Certificate Services Part 3

KB ID 0001312

Problem

Following on from Part Two, now we have an offline Root CA, and a CRL server, our next step is defined by our PKI design, are we three tier, or two tier? (Look in Part One for a definition).

Solution

As previously mentioned, Microsoft just treats Intermediate CAs and Issuing CA’s as the same thing (SubCAs). So the next step is identical for either. But I would suggest one difference, If I was deploying an Intermediate CA, I would have “LoadDefaultTemplates=0” in the CAPolicy.inf file, and for an Issuing server I would not, (that’s just my personal preference).

I’m going to continue this piece for a two tier PKI deployment. And my next SubCA will be an Issuing CA.

Create your SubCA CAPolicy.inf file and save it to C:\Windows

[box]

[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID= 1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=http://pki.cabench.com/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=15
CRLPeriod=weeks
CRLPeriodUnits=1
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0

[/box]

Launch Server Manager > Manage > Add Roles and Features.

Role Based > Next > Select the Local Server >Next > Active Directory Certificate Services > Add Features > Next.

No additional Features are Needed > Next > Next > Select Certification Authority > Optional*: Select Certificate Authority Web Enrolment > Next.

*Note: This gives you the nice registration website for certificates.

Next > Install > Close.

Configure Active Directory Certificate Services.

Next > Select ‘Certification Authority’ and ‘ Certificate Authority Web Enrolment’, if you selected it above > Next > Enterprise CA > Next.

Subordinate CA > Next > Create New Private Key > Next > Change the Hash algorithm to SHA256 > Next.

Give the CA a sensible Name > Next > Select ‘Save certificate request to a file on the target machine’ > Next.

Next > Next > Install > Close.

Note: The warning is fine, we haven’t installed the certificate yet, that’s our next step

Copy your certificate request file, (ending .req) and put it on your floppy drive. 

Note: I’m aware we are in the 21st century! I’m using virtual floppy drives.

Present the floppy drive to your offline Root CA and execute the following command;

[box]certreq -submit “A:\filename.req“[/box]

When prompted with the CA name > OK > Take a note of the RequestID you need this in a moment. (Leave the command window open!)

Open the Certificate Services Management Console > Server-name > Pending Requests > Locate your request > Issue the certificate.

Back at command line issue the following command;

[box]certreq -retrieve {RequestID}A:\SubCA.crt“[/box]

When prompted with the CA name > OK.

Check the certificate has appeared on your floppy drive, and present that back to your SubCA server > Open the Certificate Services Management console > Server-name > All Tasks > Install CA Certificate > Locate the cert  > Open.

Start the Service (If it errors at this point you may have a problem with your CRL server see the following link for a temporary workaround until you can fix the CRL).

Certificate Services – Disable CRL Checking

Troubleshooting: Open an MMC Snap-in and Add the Enterprise PKI snap-in to point you towards problems.

At this point I like to copy the Sub CA Cert to C:\Windows\Sytem32\Certsrv\CertEnroll. You should see the CRL for the SubCA already there (and maybe a delta CRL like the image below).

Now we are going to publish those into AD, open an administrative command window and issue the following commands;

[box]

cd  C:\Windows\Sytem32\Certsrv\CertEnroll
certutil -dspublish -f SubCA.crt SubCA
certutil –addstore –f root SubCA.crt
certutil –addstore –f root SubCA.crl
certutil -dspublish  SubCA.crl

[/box]

 

Restart Certificate Services;

[box]

net stop certsvc
net start certsvc

[/box]

Back in Certificate Services > Properties > Extension > Remove the http and file entries. NOT the ldap or the one that’s pointing to C:\Windows.

With CRL Distribution Point showing > Add > Type in http://pki.{your-domain}/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl 

Note: You can add the variables in to avoid typing them, DON’T FORGET to put .crl on the end!

OK.

With your new URL selected, tick;

  • Include in CRLs. Clients use this to find DeltaCRL locations.
  • Include in the CDP extension of issued certificates.

Apply > OK > Services will Restart.

Once Again, click Add, this time type in the UNC path to your hidden PKI share on your CRL Server, e.g.

\\pki.{your-domain}\pki$\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

Note: You can add the variables in to avoid typing them, DON’T FORGET to put .crl on the end!

OK.

With your UNC path selected, tick;

  • Publish CRLs to this location.
  • Publish Delta CRLs to this location.

Apply  > OK > Services will restart.

That’s your PKI environment stood up and ready to go, you may also want to setup OCSP, see the following article;

Microsoft Certificate Services Configuring OCSP

You can now issue certificates, some of the things you might want to consider setting up are;

Windows Server 2012 – Enable LDAPS

Deploying Certificates via ‘Auto Enrollment’

Windows Server 2012 – Secure RDP Access with Certificates

Install and Configure Certificate Enrolment Policy Web Service

Related Articles, References, Credits, or External Links

NA

Windows Server – Locate CA / Certificate Services

KB ID 0001163

Problem

A colleague was having some certificate problems onsite the other week. Someone suggested just using Certificate Services to simplify matters. I said I’d spin it up and configure it for him, (I’ve done a lot of Microsoft CA work, search the site!)

My fist question was, “Do they already have certificate services?’, unsurprisingly the answer was “I don’t know”.

So if you’re on a domain, and you want to locate your CA server, or simply find out if you have one, what do you do?

Solution

The simplest option is look in Active Directory Users and Computers, then locate the ‘Cert Publishers’ group and look at its members.

Or you can run adsiedit.msc >  CN=Certification Authorities, CN=Public Key Services, CN=Services, CN=Configuration, DC={domain-name},DC={domain-extension}

Easy Option: If you’re lazy, (like me!) Simply run the following command;

[box]

certutil –config – -ping

[/box]

If you don’t have any CA’s this is what you will see;

But if you do (below there is one, but there may be many);

Related Articles, References, Credits, or External Links

NA

Event ID 128 – Certification Authority

KB ID 0001033 

Problem

Seen in the application log of a Windows Certificate Services server (Server 2012 R2)

[box]Log Name: Application
Source: Microsoft-Windows-CertificationAuthority
Date: 07/02/2015 15:55:26
Event ID: 128
Task Category: None
Level: Warning
Keywords:
User: SYSTEM
Computer: PNLPKI00v.petenetlive.com
Description:
An Authority Key Identifier was passed as part of the certificate request 29. This feature has not been enabled. To enable specifying a CA key for certificate signing, run: "certutil -setreg caUseDefinedCACertInRequest 1" and then restart the service.[/box]

Solution

The event is pretty much telling you exactly what to do to fix it! Open an elevated command prompt and enter the following commands;

[box]

certutil -setreg caUseDefinedCACertInRequest 1
net stop CertSvc
net start CertSvc

[/box]

Or you can simply open the registry editor and navigate to;

[box]HKLM > SYSTEM > CurrentControlSet > Services > CertSvc > Configuration > {your-server-name}[/box]

Change UserDefinedCACertInRequest and change its value to 1 (one). then restart the certificate services service.

Related Articles, References, Credits, or External Links

NA