When getting to know a new customer and network as part of my day job, I generally find that one of two things are true. Either they don't have a CA server, or they do, but it isn't being used for anything yet. Most folks know that certificates are upcoming and in demand and that new technologies are released all the time that require a fairly large use of certificates. Technologies such as Lync (Skype for Business), SharePoint, System Center, DirectAccess, or even just building a website almost always require the use of a certificate in today's world. Jumping into a project to deploy almost any new system these days will quickly bring you to the realization that a knowledge of certificates is becoming mandatory. Even in places where they aren't required, they are usually still recommended in order to make the solution more secure or to adhere...

The first hurdle to overcome when you want to start certificate work is putting the server into place. There are many valid questions to be answered. Do I need a dedicated server for this task? Can I co-locate this role on an existing server? Do I need to install an Enterprise or stand-alone CA? I've heard the term offline root, but what does that mean? Let's start with the basics and assume that you need to build the first CA server in your environment.

In an AD domain network, the most useful CA servers are of the Enterprise variety. Enterprise CA servers integrate with AD, making them visible to machines in the network and automatically trusted by computers that you join to your domain. There are differing opinions on the matter of best practices when setting up a series of CA servers. For example, there...

We build Subordinate CAs not really for the purposes of redundancy, like with many other kinds of servers, but because there are specific tasks that you may want to perform on a subordinate CA rather than a Root CA. If you issue a lot of certificates or different kinds of certificates, you may want to differentiate between CA servers when issuing. Perhaps you want machine certificates that are used for IPsec to be issued from IPSEC-CA, but the SSL website certificates that you issue should show as being issued from WEB-CA. Rather than building out two independent Root CAs that both have top-level rights, you should consider creating a single Root CA, maybe called ROOT-CA, and placing these two CA servers in a subordinate role under the Root CA in the chain. This can also be useful for geographically dispersed networks, having...

This recipe is the first hurdle that many new certificate admins bump into. You may have a CA server up and running, but what's next? Before you can start granting certificates to computers and users, you need to establish certificate templates that you are going to publish. You will configure these templates with particular settings, and when a certificate is requested against the template, that new certificate will be built based on the information in the template combined with the information provided by the certificate requestor.

There are some built-in certificate templates that preinstall when you add the CA role to your server. Some companies utilize these built-in templates for issuing certificates, but it is a better practice to create your own templates. There is no need...

One of the most common certificate troubleshooting tasks I encounter is figuring out why a particular certificate template is not available when the user or computer tries to request a certificate. Having created a new certificate template does not necessarily mean that you are ready to start issuing certificates based on that template. We also need to publish our new template so that the CA server knows that it is ready to publish out to computers and users. There is also a security section of the template properties, where you need to define who or what has access to request certificates based on that template. In this recipe, we will find those settings and configure our new certificate template so that any domain joined workstation is allowed to request a certificate from our new template.

The most common way that I see administrators interface with the certificates on their systems is through the MMC snap-in tool. MMC is short for Microsoft Management Console, and by using MMC, you can administer just about anything in the operating system. Though this is perhaps a greatly underutilized tool, I only generally see it being opened for a few select tasks. Requesting certificates is one of those tasks.

We are going to use the MMC console on a new server that we have in our network. There is a new certificate template that has been created, and we would like to issue one of these certificates to our new web server.

A Server 2016 Enterprise Root CA server is online...

Sometimes when requesting a new certificate, you may not have access to query certificate services directly by using a tool such as the MMC snap-in. Or perhaps you want to provide a way for users to be able to request certificates even while outside the office. By enabling the web services portion of the CA role, we turn on a website that runs on our CA server. This website can be accessed from inside the corporate network and could potentially even be published out to the Internet with some kind of a reverse proxy solution.

For our recipe today, let's access the web interface that is now running on the CA server where we installed the web services part of the CA role. We will use this website to request and acquire a certificate on our client computer.