In this final page of the series, I'll list out some other resources that might be helpful now that you have a working Certificate Authority.

In this post we're going to talk about the operational work associated with managing the Microsoft CA. There are three things we'll touch on here. First, manually updating your Root CA CRL which should be done based on how you setup your CA. In this lab, that would be at least once every 6 months. Second, we'll talk about how to approve pending certificate requests. Finally, we'll cover how to revoke certificates that either no longer required, or that may have become compromised.

In this post, we'll discuss how to use the Certificate Enrollment Web Interface that we installed back in Part 2 of this series. The web interface doesn't seem to be widely used since the Certificates MMC snap-in does most of the work, but it's useful to know it's there.

Finally – the moment you’ve been waiting for!  Issuing Certificates!  We’re going to cover three enrollments for our three different certificate templates created in Part 4.

In this part of the series, we’re going to start getting ready to issue some certificates, and we’re going to do that by creating some Certificate Templates.  This can be done from any workstation that has domain access and has the Certificate Templates console installed (part of the Remote Server Administration Tools), but we’re going to do it from our Intermediate Server in this lab since we know everything we need is already installed there from Part 2 of the series.

In this post we’re going to setup the trust for your Root Certificate in your environment. If we think about what we talked about back in Part 1 of this series, you’ll remember that once we trust the guy at the top, we trust anyone down the chain as well.  By trusting your Root Certificate, we automatically trust your intermediate certificate and anyone who your intermediate authority generates a certificate for.

I'd like to tie together everything we've done so far.  If you're following along, you've probably gotten through standing up two servers in a lab environment in under 30 minutes, but perhaps without understanding the implications of the changes you've made along the way. We're not going to make any changes to your environment in this part of the series, so you're welcome to skip it and you'll still end up with a perfectly valid environment, but I feel like there might be some value here for you.

In this post, we'll stand up a subordinate Certificate Authority server.  This will be your domain joined, always online server that will actually hand out the certificates to clients.

In this post I'm going to walk through the steps necessary to standup a pretty basic Certificate Authority (CA) within your on-premises Active Directory environment.  This is an introduction to CA only, and I'll admit that all of my knowledge is from working with consultants to stand environments up and from reading Microsoft's documentation.

The following AutoIt script will allow you to set the Microsoft Office Registered User Name, Initials, and Company via a script by getting the name information from Active Directory and modifying the keys . This is useful in corporate environments where you don’t want it to have a generic name when you’re being told …