Public Key Infrastructure (PKI)

The role of PKI (Public Key Infrastructure) in URA is important to understand. With Windows 2008 R2, it was required to deploy certificates to every computer that needed to be a DirectAccess client, but this is no longer a mandatory requirement today, thanks to a component that proxies Kerberos authentication instead of using a certificate for the IPSec authentication. It's important to note, though, that this component can be used only if all your URA clients are Windows 8 clients. If you will be deploying this to the Windows 7 clients, you will still require this infrastructure, and we will discuss this in more details in the next chapter.

Even if you choose to deploy URA without issuing certificates to clients, there are other certificate requirements. Earlier, we mentioned that one of the IPv4-IPv6 transition technologies is IP-HTTPS. This requires the URA server and client to communicate with SSL, and for that, you will require a certificate. This can be achieved with a self-signed certificate, produced by the URA server as part of the setup, and it even publishes the root certificate through Active Directory so that your clients can trust it with no need for manual intervention.

The certificate used for this purpose is a server certificate and will be presented to the URA client by the URA server as a means of proving its authenticity. If you prefer, you can use a regular certificate, which can be purchased from any of the many commercial certificate providers such as Verisign, Thawte, and Geotrust. Using a public certificate provider for this situation has costs, of course. Another option is to use the Windows Certificate Authority role that's built into every Windows Server product and create a regular certificate at no cost. The challenge with using an "internal" certificate provider like that is the fact that all your URA clients will have to trust it, which means that if it's not integrated into your domain, you will have to find some way to deploy its root certificate to all clients. Another challenge is that a certificate generated by a certificate authority contains a CRL (Certificate Revocation List), which needs to be accessible to the client as part of the connection process. For this to work, you will need to publish the CRL to some publicly accessible website, and that may be somewhat challenging. We will discuss this topic in more details later on, but you can prepare for this by reading up on managing a Windows certificate authority through the article available at http://technet.microsoft.com/en-us/library/cc738069(v=ws.10).aspx.