One question I get asked often is “How to determine what certificates are expiring?”.  This is especially critical for certificates that are not enrolled for with autoenrollment.  This is due to the fact that autoenrollment will renew certificates.  However, when requesting a certificate for a server, often the Subject or SAN are supplied in the request, limiting the ability to use autoenrollment to renew the certificate.  Also, since servers generally host services that are critical to the environment, it is often better to actually enroll for the certificates manually as well as renew manually to ensure this gets completed successfully.

In this post I will cover migrating Enterprise Certification Authorities to Windows Server 2008 R2.  These steps will work for Enterprise CAs regardless of whether they are a Root CA or a Subordinate CA.  The assumptions I make in this blog is that Key Archival and Role Separation is not enabled.  This posts also assumes that the machine you are migrating to will have the same hostname.  If you have a more complex scenario, such as one that includes Key Archival please see the Active Directory Certificate Services Upgrade and Migration Guidance.

The steps from Migrating the CA are the following:

In this segment I am going to cover upgrading Standalone Certification Authorities. Standalone Certification Authorities are Certification Authorities (CAs) that do not use certificate templates for forming and validating certificate requests. Standalone CAs can be joined to an Active Directory Domain or can be joined to a workgroup. In this segment I am going to focus on upgrading standalone CAs that are not joined to a domain, which would be the case for offline Root and Policy CAs. Also, in this discussion I am not going to cover the process of upgrading CAs that use Hardware Security Modules (HSMs), although the process would be somewhat similar.

One of the really nice things about upgrading a standalone CA that is a member of a workgroup and that does not use an HSM is that you can get the CA you are migrating to, up and running while the previous CA is still setup. This is nice, because if you run into an issue you can simply start the migration over, while still using the old CA for any necessary functions (issuing CRLs, renewing subordinate CA certificates).

Today, I am going to talk about some things that you should consider before upgrading your existing PKI.

The first question is “Are you happy with your existing PKI?” PKI is a niche technology. Many organizations setup a PKI with limited experience with this technology. As such many times an organization’s PKI is not configured correctly or may not be configured in a way that meets the organization’s needs. If your PKI falls into one of these two categories, it may make more sense to replace your existing PKI, rather than upgrade your existing PKI.

A lot of my customer site visits are for upgrading a customer’s PKI from Windows Server 2003 to Windows Server 2008 R2. I am going to cover the steps for upgrading a PKI in future postings in this series. However, before getting into the upgrade process, it is important to know why you may in fact want to upgrade.

A very general argument I make for upgrades of any sort are the following: