First published on TechNet on Jun 30, 2013
Hello everybody, Randy here. I am new to the PFE role, but have a number of BLOG Posts under my belt from my time as a CTS engineer for the Directory Services team. One of my first tasks as a PFE was to clarify some features available in Server 2012 AD Certificate Services. This BLOG Post focuses on the Key Based Renewal feature but also can be a refresher on the topics of the Certificate Enrollment Policy Web Service (CEP) and the Certificate Enrollment Web Service (CES... .
The Windows Server 2012 Key Based Renewal feature offers non-domain joined computers the ability to automatically renew their certificates. You may be asking yourself “Why do we need Key Based Renewal to accomplish this?”
For auto enrollment and renewal of certificates to work, the CA requires a very important piece of information: The identity of the requestor. In an intra-forest or Trust scenario, we can leverage Windows Integrated security to achieve this goal. Key based Renewal considers that the ownership of the certificate can be your identity. With the certificate itself as the authentication, any subject with access to the private key will be able to renew the certificate prior to its expiration. Now let’s look at the components and their settings to better explain this concept and how it can be secure. First let’s look at the certificate template requirements.
The Certificate Template: Requirements for Key Based Renewal
· The first requirement is that the template be marked to require “CA certificate manager approval". This is an extra layer of administrative overhead to ensure the auditing of certificates issued with this capability.
· A parameter on the certificate template to identify its eligibility for key-based renewal. You (the PKI administrator) choose what templates can produce certificates that renew themselves by selecting this option under the “Issuance Requirements” tab of the template.
NOTE: Marking a certificate template as Allow Key Based Renewal does not restrict it from use by authenticated requestors and leveraging auto-enrollment or auto-renewal. This behavior would be controlled by your standard permissions on the template.
· A parameter on the certificate template allowing for the use of the existing subject name of the certificate to be used for auto enrollment renewal request. This option is under the “Subject Name” tab of the certificate template. You cannot leverage AD information to build the subject name because the requestor is not identified by a security principal that holds the certificate.
· The certificate itself is the identity of the requestor, therefore the key usage must include “Client Authentication.” This setting is on the “Extensions” tab and double click on “Application Policies.”
Now that we have our template, we need a way to get to it. We cannot use our default Enrollment Policy (which is LDAP.) LDAP would need authentication and the CA will just use that to identify the requestor. What we need is a Web Enrollment Policy Service that does NOT use Windows Integrated.
Here is a refresher on the concepts of CEP and CES Certificate Enrollment Web Services .
First we will take a look at the requirements for the Certificate Enrollment Policy Service. This service is responsible for querying Active Directory for a list of available certificates the requestor is permitted to enroll. This service will require some unique settings in order to process a request using only the previous certificate as identification. Fortunately, the setup Wizard will guide you through all these settings if you select the CEP for Key Based Renewal.
Certificate Enrollment Policy: Requirements for Key Based Renewal
· Authentication Type cannot be “Windows Integrated.” We are not authenticating in the traditional sense, so we must select either Username \ Password or Client Certificate. Client Certificate in this context means a certificate mapped to a specific security principal in Active Directory and does NOT mean Key Based Renewal. This setting identifies how the CEP will initially validate a connection when configuring a CEP target on a client. I was able to change the password of the account originally used when setting up the policy and was still able to renew my certificate.
· We need to Enable Key-Based Renewal on the Policy server. Pay close attention to the informational in the wizard. It indicates that this feature is “All or Nothing” so if you offer Key-Based Renewal on this Policy Server, it will only offer those templates where Key-Based Renewal is configured.
Certificate Web Enrollment: Requirements for Key Based Renewal
· Renew on Behalf of (ROBO) mode. When setting up a CES Server, you can configure it for both enrollment and renewal services, or (for the security conscious) only for servicing certificate renewal requests. I mention the security conscious because CEP servers are often public facing or in a DMZ, and therefore exposed to a greater attack surface. By configuring the CEP service in ROBO mode, an attacker would only be able to extend the validity of an existing certificate and not obtain fresh ones. Revocation checking can deactivate any certificate that has been compromised. The important point here is the requirement of this setting, meaning that enablement of Key Based Renewals now limits the CES to performing ONLY renewal requests.
· Selecting a Service account. This step is slightly more important when considering Key Based Renewal because this Service Account will be enrolling on behalf of the owner of the certificate. You will also need to register the http SPN to this account and use the same account for CEP if running both these services on the same machine. See the TechNet articles in the “Additional Resources” section for more information.
· Authentication Type must be Client Certificate Authentication. Although the Policy server can implement “User Name\Password” or “Client Certificate authentication”, the Web Enrollment Service requires that you use “Client Certificate authentication.” This setting coincides with the requirement of the Certificate Template EKU to have “Client Authentication”.
· And Last but not Least, enabling the Key-Based Renewal feature.
To summarize our requirements of Key-Based Renewal. This feature is only available through the Web Enrollment services and require that both of these Services be configured specifically for this purpose. This configuration limits the CEP service to only enroll requestors for Key-Based Renewal Certificate Templates and the CES service to only provide Renewal services to the certificate and only allow for the client certificate to be used in identifying the requestor.
Additional Resources
If you have read this information and feel something is missing, or ready to implement and need a more step-by-step approach, then here are some great resources on TechNet:
Certificate Enrollment Policy Web Service Guidance
Certificate Enrollment Web Service Guidance
Test Lab Guide: Demonstrating Certificate Key-Based Renewal
Certificate Enrollment Web Services Whitepaper
Renewing a Certificate
Now that we have all the configuration out of the way, my next step is comparing the Key Based Renewal Capabilities against a Windows Integrated CEP \ CES Authentication. To do this I set up two separate Servers; one hosting CEP \ CES in regular Windows Authentication mode and the other CEP \ CES server configured for Key Based Renewal. Now I can create two different Web Enrollment Policies on a Domain-Joined member and be able to toggle between the two for testing.
The First thing to point out is that my Key-Based enabled Certificates are also available for enrollment when going through the Windows Auth CEP (Adatum AD CEP.) I was able to enroll in the new certificate as well as any number of certificates currently available for a domain-joined computer.
So I select my KBWeb (Key Based Renewal Certificate Template) and enroll using my Windows Auth CES service (remember that the Key Based Renewal CES service can only do renewals.) I must issue the certificate and copy it to my client because of the template restriction of requiring CA Certificate Manager Approval. This step is a typical PKI trade-off. You are taking the security burdens away from your users and replacing it with the administrative burden of your CA administrators. The explanation of that for mentioned comment is as follows:
· The Website administrator does not need to worry about setting and protecting a secure password, or even now requesting a new certificate before expiration.
· The CA administrator now needs to perform potentially high assurance issuance measures to vet, track and monitor these self-managing certificates.
Now I have my new certificate on my domain joined member and I turn off my Windows Auth CEP / CES server and try “Renew Certificate with New Key…”
I ultimately receive an error that the “Windows Auth CES server” is unavailable (Not the Key Based Renewal Server.)
Keep in mind that because this machine is domain-joined, it will be able to present its identity and enroll in either of the CES servers that are defined in the msPKI-Enrollment-Servers attribute on the object “CN=<CA Name>, CN=Enrollment Services, CN=Public Key Services, CN=Services, CN=Configuration, DC=corp, DC=adatum, DC=com.” This is where the Policy server knows to direct the client to for Enrollment.
Another interesting point on the error above is the “Continue” button. If I press this it brings up a Certificate Selection Window with all of my certificates that include the EKU for “Client Authentication”.
I select this certificate and now it goes to the Key Based Renewal CES server. So ultimately what happened was:
· The Policy server identified the available template and iterated through each of the Web Enrollment Servers in order of Priority.
· The Windows Auth failed because it was turned off, so we went to the Key based Renewal CES and that server was only able to accept the credentials of the certificate.
To verify this behavior, I renewed again with the Windows Auth CES server online and it went through Windows Auth CES to process the request.
This can also be seen by looking in the CA database at the issued certificate requests and the identity of the requestor.
The first and last certificate was requested by the computer account which enrolled in the template Randt38$ and the one in the middle was my Key Based Renewed certificate and the requestor was identified as my service account running the Key Based Renewal CES (CESSvcKB.)
I then wondered if there was any auditing I could implement to identify the requestor for Key Based Renewals. I turned up security auditing and turned up the CEP and CES operational logging and received nothing that would indicate a name or IP address.
NOTE: Enabling Verbose Logging on the CEP and CES services: <add key="LogLevel" value="4" /> under the web.config file. For more information read the Certificate Enrollment Web Services Whitepaper
Your solution to audit this would be to query the Request IDs where the requestor name equals the CES service account name and give each certificate issued of this type a unique parameter in the “Subject Name” that would identify where it came from.
Summary
The example above shows how a renewal request can be serviced without supplying credentials to the CA. Certificates can perform a variety functions, including client authentication, which can now be leveraged in the renewal request. This reduces the administrative overhead involved with supporting certificates issued outside of the Windows Security Boundary. The behavior of my non-domain joined machine would be that I would not be offered the option to enroll with the Windows Auth CES because the machine account was unable to identify itself to the Policy (CEP) service. I would be offered a renewal of the existing certificate through my Key Based Renewal CES by selecting the certificate as my credentials. The auto enrollment services on my client will be able to detect the expiration of the certificate and locate the Policy (CEP) service as defined in the local GPO configuration of the non-domain joined client.