Windows Server Basic Certificate Authority Setup

tl;dr

  • Install certificate services, selecting all options.
  • This will ask you to install IIS, say yes and keep the options as default.
  • Let the server install the roles.
  • Configure the services remembering the bigger the numbers the better!

What is this for?


The word “certificates” to most IT professionals tends to make them recoil in horror. This is for one of two reasons, they either have to spend hours and hours studying to get one. Alternatively its because someone is talking about Public Key Infrastructure, something that most see as a bit of a dark art!

In a series of posts I am going to try and demystify this dark art. Public Key Infrastructure is extremely powerful and, if done correctly, can significantly improve your security posture. I will try and keep each post as sort and simple as possible. In this post I am just going to spin up a very quick and dirty certificate authority to be used in a lab. In the event you are installing a Certificate Authority into a customer / your business its something that needs a lot of consideration and careful planning. You defiantly should not be leaving your root certificate online, or even worse installed on your domain controller!

With the goal of keeping things simple I am going to do this on the domain controller I created in this post.

System Setup:


Operating System:
Windows Server 2019


Hypervisor:
VMWare ESXi

Getting down to business…

Okay so we have our domain controller setup and ready to go. Since the last article I have spun up a second Windows Server 2019 server with a GUI. I am then going to use this as a Jumpbox/Client to manage the “lab1” domain environment I have built so far.

First we we load up server manager, ensuring the server we want to install certificate services on is in the list. We will then go to “Add Roles and Features”.

We get a introduction page…

We then need to confirm that we want to install a Role or Feature.

We then select our domain controller as the target, in this case our domain controller.

We then select “Active Directory Certificate Services”.

We can leave the feature settings as they are.

We then get an introduction to setting up the Certificate Services.

In production we want to keep the features we turn on as limited as possible to decrease our attack surface. However, this is a lab and we want to play and better understand the technology so on this page I am going to select all the features.

When selecting the web features you will essentially be asked if you want to also configure the server as a web server. This is required for some of the features such as “Certificate Enrolment Policy Web Service” so click “Add Features” to confirm.

We then get an introduction to setting up the Internet Infomation Services.

What is selected by default here is fine. If this lab was about playing with IIS servers i would be saying tick all of the boxes!

We can then confirm we are happy with this setup and allow the server to reboot automatically. In this specific case a reboot should not be required.

Depending on the time of day/personal preference go and grab a tea/coffee/beer as this takes a bit more than 5 minutes.

In this case the server did not reboot so we are just presented with the success team. We can now just close the wizard.

If we then go back to Server Manager you will then get a notification to configure the service.

We need to start off by providing some credentials to be used by the role. As we are being quick and dirty I will just use the domain administrator account. In the real world this would be a really bad idea and you should be using a dedicated service account with the least possible permissions. I am going to do some more detailed articles about real world PKI setups later on so I will ensure I include this information in these posts.

We then get asked what role services do we want to configure. We will need to do this in two sections. As some are prerequisites to the others. For now just select the role services I have below.

In our case we want to configure an enterprise CA so it is tied in with Active Directory.

This will be a root CA as its going to be the first Certificate Authority in our environment.

As we have never had a certificate authority before in our enviroment lab we will need to generate a new set of keys for it. Don’t worry for now too much about the terminology I will write up the fundamental principles of PKI in a separate article.

As a rule of thumb the bigger the numbers we use here the more secure we will be.

Now we have the keypair sorted we need to start providing information for our root certificate. I could have left this as default but i have changed the Common Name (CN) so that it doesn’t specifically reference the servers name. Some may argue this adds a bit of security. It also means the certificate is not specifically tied to this server and can be moved at a later date if needed without triggering my OCD.

I normally say get your certificates to expire regularly. This helps to keep you well versed at changing them as needed. However for root certificates try and make sure the expiry date is some time after your predicted retirement date.

In a production environment you may want to put the on a separate drive but this is a lab and I didn’t want to add a second disk.

For authentication type we will leave this as windows integrated.

As we don’t yet have a working CA, we also don’t have a server certificate. Therefore we will choose to assign this later.

All we have to do now is review the settings and ensure we have not made any mistakes. So long as it all looks good we just need to click configure.

This should be relatively quick to confirm everything is looking good.

Hit close and then Server manager will ask you if you want to go back and configure the additional role services. Yes we do!

As with the first round we need to provide some credentials. I will stick to my bad practice for now and use the domain administrator.

We can now select the remaining two role services.

We will then be asked for a service account for the NDES service. This user needs to be part of the local IIS_IUSRS group. As this is a domain controller we don’t have local groups. Therefore we need to just ensure the administrator user is in the domain version instead located in the Builtin folder.

As with the distinguished name before I have just dropped the servers name out.

As before with the private key, the bigger the numbers the better.

We can just use the CA name for this one.

We will stick with Windows integrated authentication.

We then use our bad practice administrator account as a service account again…

This time we are able to use the Root certificate as the certificate.

Finally we just have to press configure.

Then about 20 seconds later we are all done.

We now have a working certificate authority. Check out these guides to:

Enjoy!

Leave a Reply

Your email address will not be published. Required fields are marked *