Setup and Configure a Public Key Infrastructure PKI

In this article I cover how to setup and Configure a Public Key Infrastructure PKI from scratch on a Window Server Domain. From that point on we can expand the PKI to cover other areas and services like AD RMS, NPS, WiFi, etc

1. PKI Theory
2. Installation of Enterprise Root CA
3. Configure the CRL Distribution Point
4. Configure the AIA Location
5. Configure the Online Responder
6. Revocation configuration
7. Configure a Key Recovery Agent
8. Configure Computer Auto-Enrolment
9. Configure User Auto-Enrollment
   

After you complete the configuration points above, it is time now to rock and roll and start using our CA now to enrol services

1. Issues certificates for internal IIS serves
   • Request a certificate using IIS

1. PKI Theory

First of all, and before jumping on murky waters, a bit of theory and oxygen: the principle of Certificates in IT Infrastructure are pretty simple, you have two things:

• A Public Certificate; you distribute it to everyone. A "Public Certificate" is nothing but a bunch of long numbers and letters that has been specially arranged
• A Private Certificate; you keep hold yourself of the "Private Certificate" and never, ever give it to anyone

With the Private key you scumble the message or the thing that you want to send across the open Internet. Your message will look like gobbledygook to anybody who is reading it...unless of course they have your Public key, on which case they can "unscramble" the message, having therefore the certainty that the message originated from you

We use certificates to Sign something (a driver for example) or to Encrypt something (a message or a file for example). The proper and long way to setup a PKI is as you see on this capture below, with a few CAs all of which have got 2/3/5 or even 10 years expiration certificates. This is tedious to setup but is flipping secure: that chain of encryption over encryption over encryption would be real hard to crack!

However, what I'll cove on this article, is a simple yet effective setup of configuration of PKI (single Enterprise-Root CA), without going all over the roof setting up server and adding extra-layers of complexity which by the way also increases the surface of attack. We are taking the approach of having all eggs on the same basket, which could be bad for obvious reasons but also good, as you only have one single point to extrar-protect and care about

2. Installation of Enterprise Root CA

On your FRDC (Forest Root Domain Controller), a Windows Server 2012 R2 on my case, open Server Manager >> Manage >> Add Roles and Features >> and select the "Active Directory Certificate Services". To start with we'll install only 3 roles: the compulsory "Certification Authority", the "Certification Authority Web Enrolment" and the "Online Responder"

The services that we are not selecting are:

• Certificate Enrolment Policy Web Service; needed only to enrol computers that are not member of AD, as below
• Certificate Enrolment Web Service; needed only to enrol computers that are not member of AD, as above
• Network Device Enrolment Service; this is to create certificates for devices like routers and switches

1) After the installation completes, open the Task in Server Manager to continue with the configuration (ensure you're logon with an account part of Enterprise admins, as this is the 1st CA on the forest)

2) Select "Enterprise CA", and for the next window select "Root CA", as this happens to be also the 1st CA server that we are installing on our domain

3) Select "Create a new private key". In this section we choose the details that determine how hard to crack the private key is, the harder you choose it though the longer it will take for certs to be decrypt, therefore the longer it will take clients to access services. For our first Root CA we'll chose a strong one (SHA256 and 4096 bit), for subordinate CA we can then use a lower key length, something like 2048

4) Don't mess with the name of the CA, and leave it all as default

5) Make the root certificate last longer than the subordinate. I recommend an initial period of 10 years

6) Leave the default database location of "C:\Windows\system32\CertLog" selected

7) Finally, click on "Configure" and off you go

To verify the installation of components:

1. Open the "Certification Authority" console from Server Manager >> Tools, and ensure you have a lovely green-tick on your CA
2. Visit http://localshost/certsrv to see the Web Enrolment interface

3. Configure the DRL Distribution Point

The CRL(Certification Revocation List) is a file located by default in "C:\Windows\System32\certsrv\CertEnroll" that contain the list of certs that have been revoked and therefore marked as invalid

The Delta CRL(CRL+) file only records the latest changes to the revocation list, before moving them into the CRL file, meaning that every time you publish the CRL, the data into the Delta CRL+ merges into the CRL file

The CDP is a location where all certs are published, and they are also refereed in AD and in http. After the installation of the CA, open the Certification Authority console >> see the properties of the CA >> Extension tab, and select the "http" entry, ensuring that both options "Include this location in CRL and CDP" are ticked. This will ensure that the list of certificates are available also by the web enrolment of the CA server

4. Configure the AIA Location

Also under the extensions tab you'll find the AIA (Authority Information Access) which points to the location where users/computers will get their certificates from the CA. Under this section, select the "http" location and do choose the option to "Include this location to AIA extensions of issued certificates", which sadly by default is not selected

 Click on "Apply" >> "OK" >> and go ahead and restart the services when asked

5. Configure the Online Responder

The "Online Responder" is a service also called "Online Certificate Status Protocol" or OCSP, and what it does is to check the revocation status of specific certificates (those that you submit), therefore rather than checking the whole list of CRL which in large and not so large organisation may contain hundred of certs, particularly as time pass by, the Online Responder services just does a quick check to ensure the certificate you want to use is still valid and hasn't been revoked. Ensure you right-click on "Certificate Templates" >> Manage >> OCSP Response Signing and add the CA computer name with the permission of "Read" and "Enrol" ( do not autorenrol, because being part of a domain the "enrol" actually means auto-entol)

Enable the template on the CA by selecting New >> Certificate Template to Issue

Once you have done all that, visit the AIA settings again, and add a new location that reads the FQDN of the CA plus "oscp", just like that, leaving all the settings as default:

Once the extension is added, don't forget to also check the two "include" boxes:

http://ad1.nazaudy.local/ocsp

Click "OK" and then "Yes" to restart the Active Directory Certificate Services. That finishes the configuration of the Online Responder for our clients, as an alternative method

6. Revocation Configuration

Once you have done all the above, open Server Manager from the CA server >> Tools and start the "Online Responder Management" console. Right-click "Revocation Configuration" and add a new one called "AD_Revocation_Config"

• Select the certificate for an existing Enterprise CA
• Click on "Browse" and the OK to accept the local Root CA certificate
• On the next window, click "Auto-Enroll for an OCSP signing certificate"

If at this point you get a nasty error message, please ensure that you have completed the steps in " 5. Configure the Online Responder" correctly. Your final window should look like this, with the config on green status

7. Configure a Key Recovery Agent

First of all, create a Global Security group in AD called "KRA Group", and add in there the members you want them to be Key Recovery Agents

To configure a KRA, duplicate the template "Key Recovery Agent" and set it as follows:

• Compatibility tab: set the CA and client to both Windows Server 2012 R2
• General tab: rename the cert "Key Recovery Agent YOUR-DOMAIN-NAME", and set it to be published in Active Directory
• Request Handling: set the parameters like this screenshot:

• Security tab: add the "KRA Group" previously created and ensure the "Read", "Enrol" and "Auto enrol" permissions are set

Press OK, and the make the Template available by issuing it

8. Configure Computer Auto-Enrolment

To make our life easier and ensure that each computer gets a valid certificate from the CA upon rebooting, we need to enable automatic enrolment. To do that, open the Certification Authority console on your CA >> Certificate Templates >> right-click to "Manage" and duplicate the "Computer" certificate template. On the "Compatibility" tab on the new certificate, raise the Operating System of both the CA (which in my case is running Windows Server 2012 R2) and the OS of the clients so that you don't issue certificate for machines that are older than Windows 8.1... ages ago!

Visit the General tab an name our certificate "Computer YOUR-DOMAIN-NAME", and publish it into AD, ensuring that you do not automatically reenroll if duplicated certs already exist on your AD

Very important! Now visit the "Security" tab and ensure that both Read and Autoenroll and ticked in addition to "Enroll"

After that, go to Certificate Templates >> New >> Certificate to Issue and select the newly create template to make it available to computers

Finally, open Group Policy Management and either create a new GPO or edit the Default Domain GPO, and set the

Double-click on that setting and set the Configuration Model as "Enabled", setting the Renew Expired Certs and Update Certs as selected

Finally, either reboot the computer for them to pick up a new certificate after reboot or run "gpupdate" on them

9. Configure User Auto-Enrollment

To auto enrol users duplicate the "User" certificate, and ensure that under "Request Handling" you set the "Allow private key to be exported"

• Subject Name tab; note that if you set the "Email Name", the user needs to have an email address otherwise the cert will not be generated
• Security tab; for Domain Users, ensure the Read, Entoll and Autoenroll have been selected

Let's now explore the practicality of CA, issuing certificates 

1.- Issues Certificates for internal IIS servers

First, create a Global Security group in AD called "Web Servers Certificates" , and add as members all the server running IIS to which you want to issue a certificate

Now open the Certification Authority console from Server Manager >> Tools. The "Web Server" template the appears by default under CA console >> Certificate Template, is not good enough, very limited, and the best thing is ALWAYS to create a duplicate of a template so that you can adjust it to your needs. Therefore, click on "Manage" to open the Certificate Temples list, right-click on the "Web Server" certificate and select "Duplicate Template", then visit the General tab of the duplicated template and set it as follows:

• Name to be: "Web Server YOUR-DOMAIN-NAME" instead of "Copy of Web Server"
• Valid period of the template must be less than the CA root template (which we configured to be 10 years), so the web server template to last 2 years is good enough
• Select the option to "Publish certificate in Active Directory"
• Select the option "Do not automatically reenroll if duplicate certificates exists in Active Directory", that way you don't duplicated certs for the same machine

Visit the "Superseded Templates" and add the Web Server template for Windows 2000, this is so that any servers using this old template will get override by this new template; this is option but a nice to do, so you remember that this option exist in case you want to superseded Templates that you have with new ones

An important step that we need to complete is to visit the "Security" tab and add the Security Group ( the group created earlier, of which all Web Servers that are going to be using this template are members) or the name of the computer that will use this template, but is better to have a group even if you are planning of issuing certs to only a single IIS. Select the options "Read" and "Enroll" and click Apply to finish the configuration of the template

Finally, click on Certificate Templates >> New >> Certificate Template to Issue  >> and select our newly created "Web Server NAZAUDY" so that it shows as available in the Templates node:

Request a certificate using IIS

Visit the server running ISS (ensure that this server is a member of the group "Web Servers Certificates" previously created!!!), open the Internet Information Services console and double-click on the "Server Certificates" widget, in there you'll find a default certificate that is not valid for server authentication. What we need to do is to click on "Create Domain Certificate" from the left-hand side pane and follow the wizard:

• Common Name: enter whatever the users will type on the browsers (normally the FQDN unless you have a CNAME of DNS bound to that server to be know as something else). This field is very important because if you type something different of what the users will type on their browsers, they'll get the error of "untrusted certificate, do you really want to continue?"
• Organisation: yours
• Organisational Unit: nothing to do with the OUs in AD, just type something in there
• City: London
• State: London
• Country: GB

On the next window click on "Select" to pick the online CA, on our case the Enterprise Root CA, and then type a "Friendly Name", this could be different of what they users type on their browser, so no pressure here, it is purely for administrative purposes so just type whatever you fancy that identifies this server, and then hit "Finish" (the CA must be online, wait a few minute while it issues the new cert for this IIS server)

If you don't have auto-enrollment, you'd need to open a mmc console from the client machine, add the Certificates snap-in >> Personal >> All tasks >> Request New Certificate...

For AD FS you request a "Web Server" certificate from the CA

Implementing and managing certificate deployment
When implementing and managing certificate deployment, consider the following:
■ ■ You can deploy certificate servers in a hierarchy. A single root CA issues the signing
certificate for subordinate CAs. You configure the root CA so that it only issues signin
certificates. You configure day-to-day certificate issuance tasks to be performed by
subordinate CAs. This way, should a subordinate CA become compromised, you can
revoke its signing certificate. Where practical, you should use an offline root stand-
alone CA.
■ ■ Certificates (and private keys, if archiving is enabled) are stored in each CA’s database
If you deploy a large number of CAs and you need to recover a certificate or a private
key, you’ll need to figure out which CA originally issued the certificate.
■ ■ If you deploy a large number of CAs, each will have its own CRLs. You can publish the
CRLs from different CAs to shared locations. Use multiple CDPs, including one on you
organization’s perimeter network, to ensure that CRL checks can occur in the event
that one or more CDPs become unavailable.
■ ■ A CA cannot issue a certificate with an expiration date that exceeds the expiration da
of the CA’s signing certificate. You need to ensure that the signing certificates of CAs
that issue certificates either are configured with a long validity period or are updated
on a periodic basis. If you don’t do this, the signing certificate and all the certificates
issued from the CA will expire at the same time.
■ ■ Create a duplicate template each time you want to make changes to an existing
template. You can configure template supersedence within the template’s properties.
Update the compatibility settings to meet the minimum CA server and client operatin
system level where possible. This allows you to implement more advanced features.
■ ■ Use autoenrollment and automatic certificate renewal as much as possible to minimiz
the amount of administrative effort required around certificate issuance.
■ ■ Use the certificate hold status as the primary reason to revoke certificates. This allows
you to reverse the revocation should circumstances change.
■ ■ Publish a new CRL after performing a certificate revocation. This minimizes the amou
of time that the revoked certificate is accepted as valid.