Deploying Certificate Services in Windows Server 2012 #2

In part 1 of this series on deploying AD CS in Windows Server 2012, we discussed some of the features and functionalities that are new in the new server OS, including expanded role capabilities in different server editions, additional management options, new certificate templates, and better support for globalized organizations with limited IDN support. In Part 2, we'll continue that discussion, as we get into the details of the same-key certificate renewal requirement and the effects of the new increased default security settings on the CA role service. Then we'll discuss the planning steps you should take before deploying your Windows Server 2012 CAs.

Key-based renewal and same-key renewal of certificates

Certificate renewal is always an issue in managing a PKI. You want the renewal process to be as easy as possible for both users and administrators, but you also want to maintain optimum security. Windows Server 2012 includes some new features pertaining to certificate renewal that will help with both aspects.

One of the new features in Windows Server 2012 Active Directory Certificate Services is support for key-based renewal. What this does is make it easier to obtain certificates when the computer is in an untrusted domain or even when it is not joined to a domain at all. In many organizations, not all computers are domain-joined. You might have some that are members of a workgroup. In the past, administrators were required to renew the certificates for those computers manually, making for additional administrative overhead. With Windows Server 2012 AD CS, as now certificate requests can be made online through the enrollment web services to automatically renew certificates for computers that belong to a different domain or forest, or are not domain members at all.

Another new feature that we get with this version of Windows Server is same-key certificate renewal. This is an important security enhancement, because administrators can now require that certificates be renewed with the same key with which they were originally issued. This means the key stays on the Trusted Platform Module (TPM) after renewal. The keys can't be exported, thus making them more secure. The TPM also provides for anti-hammering. This is designed to thwarted attempts at brute force attacks, because the anti-hammering logic will kick in if a Personal Identification Number (PIN) is entered incorrectly too many times in a row. When that happens, the TPM locks and will not accept subsequently PIN attempts until a specified amount of time has passed.

Same-key renewal is enforced through the certificate template. On the Request Handling tab of the certificate template's Properties dialog box, you simply check the box labeled Renew with the same key, as shown in Pic 1.

Pic 1

With same-key renewal enforced, templates require that Windows 8 and Server 2012 clients use the same key to renew their certificates. Trying to use a different key will result in a failed renewal. Unfortunately, this doesn't work with clients running previous versions of Windows.

Increased default security settings

In Windows Server 2008 R2 and prior, you could increase the security level on your certification authorities by using a certutil command that would require packets sent as part of a certificate request be encrypted:

Certutil –setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST

That involved stopping and restarting the certification authority service (note that the enhanced security setting is not compatible with Windows XP client computers).

Windows Server 2012 has this enhanced security setting enabled by default. This makes sense, because otherwise an attacker could intercept the certificate requests with a sniffer and discern the names of users and machines, types of certificates, public key information and more. Encrypting the packets prevents this. However, as noted above, this won't work with Windows XP clients. If you have such clients that need to request certificates from your Windows Server 2012 CA, you should upgrade them to Windows 7 or Windows 8 (preferred) or you can lower the security level on the CA using the following command:

Certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST

Again, after running the command, you'll need to stop and restart the service:

net stop certsvc

net start certsvc

Planning your Windows Server 2012 AD CS deployment

The first step in planning your Windows Server 2012 AD CS deployment is to look at whether you will be creating a new public key infrastructure or extending your existing PKI. If you're in the latter scenario, your organization probably already has a certificate policy (CP) and a certificate practice statement (CPS) or similar documents. If you're creating a brand new PKI, these documents should be created first, to serve as a guideline.

The CP and CPS are part of your organization's security policy. The overall security policy is generally developed by corporate IT and or corporate security personnel. It defines the type(s) of security services that will be implemented through certificates. The CP defines responsibilities related to enrollment, issuance and usage of certificates. It will lay out the procedures for issuing certificates, including authentication methods, purposes for which certificates are issued, how private keys are to be managed, procedure in case of the loss or compromise of private keys, public and private key requirements (such as minimum length, where private keys are stored, whether they are allowed to be archived) and requirements for renewing certificates (such as same-key renewal). The CP also addresses the legal liability issues associated with certificates, and there should be input and review of the CP by IT, management, legal and other departments whose operations may be affected.

The CPS drills down to lay out the procedural guidelines for operating the CA(s). The CPS dictates how the CA issues the certificates that were defined by the CP. The CPS gets into specifics about the CA (name, server name, DNS address), specific algorithms, Cryptographic Service Providers, certificate issuance, renewal, recovery and revocation. The CPS is necessarily a more technical document that deals less with the "what to do" and more with the "how to do it." While the CPS should be reviewed by the legal department, it will be developed primarily by IT personnel who understand the technicalities of operating the CA on a day to day basis.

Your policies should cover such issues as how certificates will be revoked, implementation of Certificate Revocation List (CRL) checking by applications, how CRLs will be distributed, the order of CRL distribution points, publication of an externally available CRL for certificate validation by users and applications that are outside the local network, CRL redundancy, frequency of CRL publication and so forth.

Your policies should also address taking CAs offline, as well as physical security of your CAs.

After your CPs and CPS have been created, you need to consider the design or extension of the CA infrastructure. This involves a number of steps. You can get started by asking these questions:

• Will you use internal or third party CAs, or a combination of the two? The answer will depend on cost and budgetary factors, your existing hardware and software, how much control you need/want over the CA, whether IT personnel have the capability, time and resources to manage the certificates, and your comfort level regarding liability exposure.
• If you decide to use internal CAs, where will the root CAs be located? If you will use a third-party CA as the root CA, which third party CA will you use?
• What are the system requirements to have the performance and capacity needed to support your organization's needs based on usage? Will you use hardware cryptographic service providers? Will you use smart cards for the storage of keys?
• How many subordinate CAs will be needed? How many intermediate CAs? How many issuing CAs? How many RAs?
• Will you have enterprise CAs (integrated with Active Directory) or standalone CAs that don't require Active Directory? Will you have CAs that are workgroup members (to avoid problems with Active Directory updating when a CA is offline)?
• How will the CAs that are domain members fit into your Active Directory structure? Will you need to support client certificate requests from computers that are outside of the domain?

It is also important to develop a PKI management policy that assigns responsibilities for different management roles to different individuals, so that there is a separation of roles. This is important to create a system of checks and balances whereby one person is not able to compromise the integrity of the PKI. Thus, for example, the person who manages the certificate templates would not also be responsible for issuing or revoking user certificates, and someone else would configure and view the audit logs. You should never have the same person performing the duties of CA administrator, certificate manager and auditor.