One of the questions we see in Dell ProSupport and across the TechNet forums is how to migrate Microsoft PKI – also known as Active Directory Certificate Services. Typically the issue falls into 3 different groups with 3 different goals.
Group1 needs to get rid of a CA running on a domain controller, and the CA isn’t doing anything: The CA is currently installed on a domain controller and gets in the way of upgrading AD as a result. The goal is to remove the CA so the domain controller can be decommissioned. This sets them up for a nice clean AD CS install when there is a future need. What makes this unique is that the CA does not appear to be in use, so the right move is to decommission the CA. http://support.microsoft.com/kb/889250/en-us
Group2 has a functioning CA they just need to move to a new server: This group is perfectly happy with their current PKI design (be it single-tier or multi-tier) and the type of CA’s (online enterprise root vs. offline standalone root, etc) they are running. They simply need to move it to a new server running the latest version of Windows Server. http://technet.microsoft.com/en-us/library/ee126170(v=ws.10).aspx
Group3 needs to redesign the environment: This group wants a do-over. The goal is to migrate to a new PKI infrastructure that leverages a more robust or secure design.
For the first 2 groups, I’ve posted links to articles that will help in the short run. In the long run, hopefully we can create a future blog post to cover this in detail.
In this post we’ll be addressing Group 3 because, quite frankly, it’s so easy as an admin or consultant to find yourself in this scenario. Since we at Windorks do not have any budget to hire a statistician, I don’t have any of the latest numbers in front me. That said, in my experience a decent share of the CA environments out there were….shall we say…..hastily put together at the last minute. Many were born of a project that required certificates and a single-tier CA was created on the fly to meet that need. Other PKI’s were implemented without enough thought put into future need. Whatever the case, we now live in an age of Exchange, Lync, ADFS, web, vpn solutions, and even hardware products like the Dell idrac using certificates. There is a greater need for certificates which necessitates a more robust infrastructure. Put bluntly, your single-tier Microsoft PKI running on Windows 2003 Standard from hardware built the same year isn’t going to cut it anymore. Wisely, you intend to change all that; that’s why you’re here.
What do you do about it?
Fortunately, this can be a pretty graceful transition with no hard cutover. Groups1 & 2 above are not always as fortunate. Let’s take a look.
First, get some data on what certificates are issued.
Are there 9 active certs or 9000? In any migration, it’s good have an answer to “big deal, little deal, or no deal at all.” In this case, start with viewing the Issued certificates. This can give you a rough idea of the number of certs that may be floating around the organization. Whether or not those certs are actually being used for anything is important as well, yet much harder to determine and more detective work than a technical issue. Be that as it may, here are some steps to start getting your arms around this
Open the CA console, click on the Issued Certificates key
Sort by the Expiration date to get a feel for how many of the certificates are still valid.
It’s also helpful to know at a high level what templates the certificates are coming from so we can know to include them on the new CA. This is more along the lines of a visual inspection.
In the end this brief exercise can jump-start the planning process & give you an idea what you are dealing with. If there are no valid issued certs or just a few certs that aren’t being used, maybe you move to Group1 and wait for our blog post on decommissioning a CA (coming to you spring of 2016!). If there are only a handful of certs issued to DC’s and a few web servers, it presents a lower level of risk versus hundreds or thousands of certs that require more design consideration and a healthy communication plan.
Second, consider the prerequisites.
In order to upgrade to a CA running Windows Server 2008 R2 or higher, the AD schema needs to be at a 2003 level (30) or higher. For most environments this will already be the case, but it bears mentioning. At some point the CA role will require a higher minimum version than this (and no doubt I’ll forget to circle back and edit the blog) so please just remember the two are linked. As a rule, the more updated your DC’s and AD schema level the better for anything depending on it, which means AD CS. New code is superior or they wouldn’t bother writing it….except for that whole Windows ME thing back in the early 2000’s…..
Also locate an account with Enterprise Admin rights and use this to perform the rest of the work, lest you see strange errors in even stranger places. There aren’t many times EA rights are needed….at least not in any way that’s rooted in fact. This is one of the exceptions to that rule. The PKI metadata is replicated to the entire forest, so it stands to reason Enterprise Admin rights would be required.
Next, plan & build your new PKI environment.
Unlike the time you accidentally unplugged the Exchange server network cable or when you badmouthed your boss on a conference call and forgot to hit mute, this, dear reader, is one time you can right the wrongs of the past. No more will your organization have a single-tier CA infrastructure where the Root CA is just waiting to have its root cert compromised. No longer will we demean and degrade ourselves by using V1 certificate templates. This is an opportunity to build a proper multi-tier Microsoft PKI and bring your organization – kicking and screaming if you must – into the present day of PKI. If there is any fairness in the world, your boss will shower you with riches, praise, and a promotion when the migration is complete. Unfortunately, nobody said the world was fair and your boss may not think the same way we do at Windorks. Moving on….
As with any migration or implementation, proper planning is key to creating something that will perform well and last long. In other words, unless at this moment you are absolutely certain what you want to do, you’ll need to plan. Microsoft has produced various planning, design, and implementation documents for PKI running on the different flavors of Windows Server to assist in making these important decisions. Getting familiar with them will smooth the road. These docs can help with things like determining location for the CA’s, how many tiers, how many issuing CA’s and so on. Putting thought into the planning portion pays dividends when implementation comes. Larger organizations might go so far as to engage a third party or Microsoft themselves to assist in planning and design. If you are reading this, you probably don’t need quite that kind of elephant gun. To impart some straightforward guidance on the subject, if you’re the admin or consultant for a small to medium business looking for a design that balances security and scalability, I recommend starting off with a 2-tier PKI. As you’ll see in the documentation, this consists of an offline standalone root (for the sake of security) and an online enterprise issuing CA. Use the following link, which is essentially a jump page to documents on building PKI on different versions of Windows Server, to assist in constructing just such a beast. Whatever your need and OS, this link should have another link to a walkthrough: http://social.technet.microsoft.com/wiki/contents/articles/4797.ad-cs-and-pki-step-by-steps-labs-walkthroughs-howto-and-examples.aspx
Admittedly, building a 2-Tier PKI is not for the faint of heart and presents its own challenges. A decent conceptual understanding is required, and the best way to gain that is read to the blogs/wikis/technical references then walk through what you’re doing in the lab. If information via the jump page still isn’t sufficient, here are some other helpful links and walkthroughs on how to build it.
- And the Queen Mother of Whitepapers; written for Server 2003 but still applies today: http://www.microsoft.com/en-us/download/details.aspx?id=20677
Despite all the referrals to build docs, here are a couple key points to remember when putting the new PKI together:
- Take care not to name any of the new CA’s the same as the old CA. This can overwrite the existing CA objects in AD, which can cause trouble. I worked a case alongside Microsoft where a customer did this, and it creates some unpleasantness to say the least. Again, if the goal is to move the same CA with the same name to a different server, you fall into Group2 which is an entirely different process.
- When creating the new CA’s, ensure the CAPolicy.inf includes “LoadDefaultTemplates=False”. If the CAPolicy.inf isn’t a familiar concept yet, it will be -in nauseating detail – after reading through the docs and building a PKI in your lab. This one line will keep the new CA from issuing templates without your knowledge until you say so.
Once the new PKI is built, don’t let the old PKI issue any more certificates.
This means going into the old CA and deleting the published certificate templates. First, make a note of which templates are published. These same templates will need to be published later on the new Issuing CA. Here are the steps to delete the templates from the old issuing CA:
Open certsrv.msc and click on Certificate Templates. The templates in the right pane are what is published.
You can select each template one by one or multi-select and hit the red X that appears in order to delete the templates.
For those whose heart just jumped into their throat at the thought of deleting the templates, let’s be clear that we didn’t delete the templates from Active Directory. We deleted the published templates from the old issuing CA. The templates themselves are still safe and sound in the Configuration container of our shared AD database.
Publish the certificates on the new Issuing CA
Like I said, certificate templates are stored in AD. You don’t need to move them over to the new issuing CA and they do not need to be recreated. However they do need to be published in order to begin issuing certificates from the brand new PKI. Here are the steps.
- Right-click Certificate Templates in certsrv.msc and choose New – Certificate Template to Issue.
- Select the template or templates that need to be published and click OK.
The bulk of the metadata that just changed is located in Active Directory, so it wouldn’t hurt to manually kick off an AD sync using repadmin. If your domain’s convergence rate is pretty quick, then just wait for it to take its course. Also best to ensure that AD replication is healthy or some DC’s may not get the change which will result in some issues.
Certificate Renewal (aka “pulling certificates from the New PKI”)
This is the part where you ring the dinner bell on the new CA. New certificate requests will henceforth be sent to and serviced by this new Microsoft PKI. Requests essentially fall into 2 different categories: automatic & manual. As long as there are no issues, automatic requests can and will take care of themselves however there is something we can do to speed things up a bit. Manually requested certs from now on will go to the new PKI. What about the certificates that were previously requested manually? You’re going to have to do something about those. Let’s take a look.
These are the manually requested, manually installed certs. Examples include web servers that use SSL, Exchange Outlook Web Access, Lync, SCCM, ADFS, and so on. When these platforms were configured with a certificate, the certificates were manually requested and the platform was configured accordingly. There’s no easy button for this, and it will need to be taken care of before sunsetting the old CA. The good news is 2-fold: First, you can keep the old issuing CA up as long as you need, so there is ample time to find the manually-issued certificates and change them. Second, the CA cert will eventually expire so there is a hard stop. In other words if you have an IT Manager that’s a little shaky making decisions to decommission servers for fear of the unknown, this will force the action. When the CA certificate expires, those handful of manually requested certificates that were overlooked are going to bubble to the surface and demand attention. This will be years henceforth, so if you didn’t find them by then, IMO you needed them to raise their hand.
We can signal the users and computers to automatically refresh their certificates from the new CA. There are 2 different components to this.
Step 1 The process that auto-enrolls users & computers in the first place is triggered by group policy – http://technet.microsoft.com/en-us/library/cc771025(v=WS.10).aspx As such, we need to edit the policy that sets auto-enrollment and ensure it is configured to update certificates that use templates.
Open the GPO in question for editing in the GPMC.
Browse to the Auto-enrollment settings. Note: This example happens to be in the Computer Configuration and while that will be the more frequent scenario, just bear in mind it could also be set in the User Configuration.
Ensure Update certificates that use certificate templates is enabled.
Step2 Set the flag on each of the certificate templates so the hosts/users know to refresh.
Open certsrv.msc on the CA.
Right-click Certificate Templates and choose Manage.
Right-click each certificate template that is published and select Reenroll All Certificate Holders.
The duration it takes for the certificates to actually refresh on the client end…..depends. You can manually force the process on a host by running “certutil – pulse.” Windows systems also check in at boot by default. Be it manual refresh or rebooting entirely, when validating on the client I recommend refreshing the Certificates MMC after doing so in order to determine whether the update has taken place. It’s also a good idea to check the aforementioned Issued Certificates area in certsrv.msc to monitor progress on the new CA.
Am I done?
Well, there is the small matter of the Old PKI. If you can, just wait until all of the issued certificates have expired. If you can’t wait that long, you can look into publishing a CRL for the same length as the validity period as the Old CA’s certificate. Here’s how:
In certsrv.msc, right-click on the CA and choose Properties.
On the General tab, click on View Certificate, which will show you the duration of the certificate next to Valid from
The value for my lab CA is essentially 10 years out from expiration. As such, I’ll need to publish a CRL for 10 years.
In certsrv.msc, right-click Revoked Certificates. Click Properties.
Set the CRL publication interval to (in this case) 10 years and click OK.
Again, right-click Revoked Certificates, All Tasks, and Publish.
Click OK to publish a New CRL.
That should do it. Migrating a CA is like giving driving directions; it’s harder to spell it all out than it is for the person who is actually doing it. In other words, don’t be intimidated. The process is easier than it looks, and this is one of those migrations where the odds are low that there will be any impact to users. Try it out in the lab to get more familiar, and good luck!