Deep dive into UAG DirectAccess (Certificates)

I hope you survived my last blog post about IPv6. Today I’m joined by a fellow member of the UAG team: Max Braitmaiere, who is a software design engineer in the UAG DirectAccess team, Max designed many of the UAG DirectAccess specific features.

Let’s discuss today the certificate configuration in UAG DirectAccess.

Let’s go over the difference between the two certificate configuration items that are requested when UAG DirectAccess is set up.

PKI, IPsec and DirectAccess

As you’d expect, DirectAccess protects the tunnels between the DirectAccess client and the UAG DirectAccess server. DirectAccess uses IPsec for that purpose, specifically AuthIP. If you want to read more about AuthIP, here is a nice article about it by the Cable Guy. AuthIP enables using two levels of authentication, and DirectAccess leverages that, but for the purpose of this post we’ll focus on the first authentication – which requires the use of digital certificates in the local computer store as issued by a PKI. For successful certificate authentication in DirectAccess, the two IPsec endpoints need to trust a common entity – a root or intermediate certification authority (CA) in the certificate path of the CA that issued the certificates.

Although DirectAccess could have configured IPsec to accept any trusted root or intermediate CA, to be more secure DirectAccess uses a specific, single, common root or intermediate CA, which is trusted by IPsec on both the client and the UAG DirectAccess server. So, when you run the UAG DirectAccess Configuration, you need to specify the common root or intermediate CA that both the client and the server trust by selecting its certificate. If you “Browse” you’ll get the list of trusted CA certificates, and you can select one.

<<Figure 1: A snapshot from UAG’s IPSec CA certificate selection page>>

Since the trusted CA certificate list in the UAG machine is separated to “root” folder and “intermediate” folder, you have the option of picking either a root CA certificate, or an intermediate CA certificate.

<<Figure 2: A snapshot of the MMC snap-in for managing certificates>>

Please note that the CA certificate list consists of “public” certificates – certificates without a private key (the private key is a well guarded secret which the CA uses for signing the certificates it generates). The certificates in the Personal folder of the computer store however, usually contain a private key, and are used by the user for authentication, signing its communications and encrypting data.

You must ensure that both the DirectAccess client and the UAG DirectAccess server have a certificate in their local computer certificate store (as seen in the Personal folder in the Certificates snap-in) that was issued by a CA that has a path to the selected root or intermediate CA certificate (see the Certificate Path tab for the properties of the certificate in the Certificates snap-in). The certificates on the DirectAccess client and server should contain a private key and the Client Authentication object ID (OID) in the Enhanced Key Usage field to support IPsec authentication.

An advanced note: If there is more than one certificate on the client computer, IPsec prefers certificates that contain the IP security IKE Intermediate OID. If there is a health certificate on the client computer for NAP (that contain the system health OID), it is preferred over the IP security IKE Intermediate certificate.

Another advanced note: Certificate revocation list (CRL) checks on the certificates can be configured using netsh and or Group Policy (in netsh advfirewall set global ipsec strongcrlcheck 0|1|2. By default, the value used (for both the server and the clients) is 1 which means that CRL testing is done, but if any error occurs during the CRL validation, the certificate is accepted.

PKI, IP-HTTPS and DirectAccess

IP-HTTPS is a tunneling technology that enables the DirectAccess clients to connect over IPv4. The DirectAccess server publishes a Web service over SSL and acts as an IP-HTTPS server (for more information about IP-HTTPS, see protocol specification).

The certificate configuration is a little different – here you must pick a specific certificate for IP-HTTPS to use:

<<Figure 3: A snapshot from UAG’s IP-HTTPS certificate selection page>>

If you press the “Browse” key you would get a list of certificates from the Personal folder of the UAG DirectAccess server’s computer certificate store. The certificate you pick MUST have a private key (moreover – all array members must have this certificate with the private key).

The certificate in this case should be a regular Web server certificate, which means it should have the Server Authentication OID in the Enhanced Key Usage field.
(If you have a certificate with both Client Authentication and Server Authentication OIDs it can be used for both IPsec and IP-HTTPS).

Here again you should make sure that the client trusts the certificate, but trust is not limited to a specific root/intermediate CA like it is in the IPsec case. The client must trust the root CA that issued the IP-HTTPS certificate.
Regarding CRL, unlike IPsec, the client’s default in this case is “strong” check, which means that if the CRL distribution point is not available on the Internet, the client cannot validate the IP-HTTPS certificate and will fail in establishing SSL connection.

Summary

There are two types of certificates involved when you deploy DirectAccess: IPsec certificates, and Web certificates. Each one has a different configuration mechanism. To configure UAG DirectAccess you are required to pick the certificate of a root or intermediate CA that is in the certificate path of the CA that issues the DirectAccess client and the server IPsec certificates, and you are also required to pick a Web certificate to be used for IP-HTTPS.

Thanks

Max Braitmaiere

Ben Bernstein