Your server is almost ready to service DirectAccess connections! The last thing we want to do before adding the Remote Access role is to put all of our certificates into place on the server. We will talk more extensively about certificates and what options are available to us in Chapter 2, DirectAccess Environmental Best Practices, but in almost every implementation there are two certificates with which you want to be concerned at this point.
For the purposes of this book, we're not going to talk much about what IP-HTTPS is, but the key for this section is that we need an SSL certificate installed onto the DirectAccess server that is going to validate the connections coming in. Any time that you want to view, add, or change certificates on a DirectAccess server, you are best to do so using the Certificates snap-in for the Microsoft Management Console. Open the console on your DirectAccess server, and navigate to File | Add/Remove Snap-in…. Then choose the Certificates snap-in.
When you click on the Add button, you will be prompted to choose which certificate store you want to manage. We always want to choose Computer account when we are dealing with DirectAccess certificates.
And on the next screen, choose Local computer.
Now, if you navigate to Certificates | Personal, right-click and choose All Tasks | Import… and finish out the wizard to import the SSL certificate that you have acquired for the purposes of IP-HTTPS.
The other certificate that we want to make sure exists in this same certificate store on the DirectAccess server, in almost every DirectAccess implementation scenario, is a machine certificate that has been issued by your internal Certification Authority (CA) server. Many companies already have something called autoenrollment enabled in their network which automatically issues certificates to machines as soon as they join the domain. If this is the case, you will already see a (or many) certificate(s) listed inside the Personal certificate store. If this certificate was issued from the internal CA server and the subject name of the certificate matches the FQDN of the DirectAccess server, this certificate may work for IPsec authentication. You can take a look at the next chapter of this book for further details on what criteria the IPsec certificate needs to meet to be successful for DirectAccess. Otherwise, for this example, we will assume that you do not have an IPsec certificate already assigned to your server, and we will walk through the process of requesting one from your internal Public Key Infrastructure (PKI). Right-click on the Personal certificate store again, but this time navigate to All Tasks | Request New Certificate….
Click on Next, and then click on Next again on the screen that shows Active Directory Enrollment Policy. Nothing to change or adjust on this screen, simply click on Next.
This will poll your internal PKI for any certificate templates that are available to be issued. If your CA server is setup properly, you will see one or more options available to select, and hopefully one of these options is named Computer.
This is a predefined template that exists in Windows CA, and meets all the requirements for a successful IPsec authentication certificate to be used with DirectAccess. You may have also chosen to create a custom template on the CA server that is going to be used specifically for DirectAccess, as detailed in the certificate details section in Chapter 2, DirectAccess Environmental Best Practices, and if that is the case, then you would have that option available to you as well for issuance. Either way, simply select the certificate template from the list for which you would like to request a certificate, click on Next, and you will be issued a machine certificate from the internal CA server onto your DirectAccess server, and this certificate will show up in the Personal certificate store.