Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Assessing Certificate Services
Before you start migrating certificate services from Server 2003 to Server 2012 R2, you need to have an understanding of what your current certificate services deployment looks like.
Orin Thomas
April 9, 2015
2 Min Read
Before you start migrating certificate services from Server 2003 to Server 2012 R2, you need to have an understanding of what your current certificate services deployment looks like.
The first question you need to determine the answer to is what kind of certificate servers do you have in your organization.
Certificate servers running on Windows Server 2003 come in four varieties:
Enterprise Root CA. Needs to be installed on a domain joined computer. If you’ve just gone one CA and you enroll and manage certificates automatically using Active Directory, chances are it is an Enterprise Root CA.
Enterprise Subordinate CA. Also must be installed on a domain joined computer. If you’ve got more than on CA and you are enrolling and renewing certificates using Active Directory, then you’re likely using an enterprise subordinate CA to issue certificates.
Standalone root CA. A standalone root CA can be installed on a domain joined computer or one that isn’t domain joined. Organizations that take their CA security very seriously use what is termed an “Offline Root CA” – which is a standalone Root CA that spends the vast majority of its time shut down (on the basis that it’s tricky to hack something that isn’t online). Offline Root CAs are only brought online to issue new signing certificates to subordinate CAs. The drawback with standalone CA’s is that you can’t get them to issue certificates automatically based on settings configured in group policy.
Standalone subordinate CA. Standalone subordinate CAs can be installed on computers that are and are not domain joined. Certificate issuance is manual. These CAs are often placed on perimeter networks.
Once you’ve figured out the disposition of your current certificate services deployment, the next thing you need to figure out is your Certificate Revocation List (CRL) Distribution Points. Depending on your environment, this can be within Active Directory (for Enterprise CAs), stored on web sites, or stored on file shares. If clients can’t contact CRL distribution points to check for revocation information, they’ll reject certificates as invalid. In a later posts I’ll talk about migrating all aspects of certificate services, including what you have to watch out for when moving CRL Distribution Points.
About the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
