Registration Authority and Device Certificates

Registration Authority (RA) in PKI implementations is used to authorize  issuance of certificates to the certificate subscriber. Usually it is used with user certificates, especially if they are issued on the Smart Cards. In some implementations it is necessary to provide RA functionality for device certificates. Usually it is done with PKI implementations that are covered by the Certificate Policy (CP) that require a “human sponsor” for every device certificate issued in the organization. One such CP is U.S. Common Policy CP, specifically check out section 4.1.1.3.

Most organizations implement Microsoft CA and take advantage of the auto-enrollment functionality provided by MS CA and Windows platform. Windows XP and Vista, Windows Server 2003 and 2008 all can easily auto-enroll with certificates from Windows 2003 or 2008 Certificate Authority. While it is easily configured and target Windows devices just auto-enroll behind the scene with required certificates it does not satisfy the ‘human sponsor’ requirement specified by U.S. Common Policy CP.

There are a few ways to keep auto-enrollment functionality and provide Registration Authority for device certificates. Here I’ll list a few way to do it with Microsoft products, from simple RA to full featured Identity Management solutions. As time goes, I’ll provide details on how to implement each of these solutions in your customer environment.

One of the key questions to decide about auto-enrollment and approval workflow is where the “human sponsor” comes into play with any number of approvers and where or how it is triggered in the system to allow specific computer to auto-enroll with new certificate.

The “human sponsor” usually should be the system administrator who owns the desktop or server. This person can be the initiator of the process, approver and the final executioner. Some companies might want to separate those roles between more than one person and maybe automate some of them.

The technical part can be achieved in couple different ways as well. It might be decided to require approval of each certificate on the CA itself or we can handle approval by managing security group membership that have been granted auto-enroll permission. Adding computer object to a group will trigger auto-enrollment on that computer.

Now it is really up to the customer to decide how they want to execute it and what components they want to automate, how much audit and historical data they want to have etc.

Here are a few approaches to solve the “human sponsor” requirement with auto-enrollment functionality still intact.

1. Enrollment with manual approval workflow.

With this configuration server administrator would fill in form(s) asking to issue certificate to the installed system. The form(s) will go to the approving manager, get approved or denied. Approved form can be routed to the AD group manager who would find the computer object in AD and add it to the appropriate security group.

In this approach the “human sponsor” is the system administrator. His request is approved by another manager and the execution is done by another administrator. It provides good separation of powers and in my opinion satisfy the requirements of the US Common Policy CP.

On other hand this process can be very slow. It can take days, sometimes weeks. Things can get lost. Not the best way to accomplish desired result.

2. Automated enrollment with Computer Admin Acting as RA.

With this configuration server administrator will add the computer object to the desired security group. There is no forms to fill. Quick and easy.

In this approach the “human sponsor” is the system administrator, he also acts as approver and executioner of the final step. While it might be acceptable and satisfy the US Common Policy CP it might not satisfy some other requirements as it puts little checks on certificate issuance to devices.

3. Automated enrollment with MS CA Certificate Manager as RA.

With this configuration certificate template will be configured to require manager approval before certificate issuance. Server administrator will be required to add computer object to security group that is authorized for auto-enrollment.

In this approach the “human sponsor” is the system administrator. Computer will try to auto-enroll for certificate and its request will go into the Pending Requests folder. Certificate Manager will be required to approve or deny the request. After request is approved the subject computer will finish enrollment process and get the certificate.

One of the potential issues in this design is figure out how Certificate Manager would know if the request is legit or not.

4. Automated enrollment with ILM 2 Workflow, ISO Manager act as RA.

With this configuration server administrator would logon to ILM 2 and create a request to add computer object to the desired security group. The workflow will route request to the manager who approves the request (or denies). The approval will trigger ILM to add computer object to the desired group and eventually target computer will auto-enroll with certificate.

In this approach the ‘human sponsor” is the system administrator. manager is approver and ILM 2 is the executioner of the workflow tasks. ILM 2 can enforce group memberships and provide historical data on who and when request certificates and approved it. Of course you’ll need to implement ILM 2.

I’ll set this up later in the lab and provide more details on how it works.

5. Automated enrollment with CLM Workflow, ISO Manager act as RA.

With this approach use Certificate Lifecycle Manager (CLM) product. More on it later.