Certificate Related Questions and Test Lab Guide Guidance

imageA couple of good questions were asked on a recent blog post and I figured it was worthwhile to answer them in more detail in a separate post.


“Can you clarify a couple points related to Certificate Authorities and CRLs?  I plan on getting a commercial certificate for the IP-HTTPS listener as you recommended, but how does that affect all of the other certificate related configurations in the test lab guide?  The CA created on the domain server is completely separate from this commercial certificate, right?…”

The IP-HTTPS Listener Certificate

The IP-HTTPS listener needs a web site certificate (intended use is server authentication) so that DirectAccess clients can establish an IP-HTTPS connection to the UAG DirectAccess server before establishing the DirectAccess IPsec tunnels. This requires mutual client and server authentication, something that is the default setting for UAG DirectAccess (the default for Windows DirectAccess is server authentication only).

The primary advantage of using a commercial certificate for the IP-HTTPS listener is that the commercial certificate provider maintains the Certificate Revocation List (CRL) and Distribution Points for you. Not only do they maintain that list for you, they also make sure that the CRL is highly available. While you could use your private PKI for the IP-HTTPS listener, you would then be responsible for maintaining the CRL and making sure that it it highly available.

Now how does this relate to what we did in the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess Test Lab Guide (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=71be4b7b-e0e9-4204-b2b5-ac7f3c23b16d)?

In the Test Lab we actually created a certificate template that removed CRL related information so that the DirectAccess client would not fail its IP-HTTPS connection when the CRL wasn’t published. This simplified the TLG environment because we didn’t need to go through the steps of publishing the CRL. In your production environment, you do want to make sure that the CRL is available for your private PKI; so you wouldn’t use the special configuration we did for the web site certificate template we used in the TLG. However, you don’t need to publish your private CRL because the commercial provider is handling the IP-HTTPS certificate’s CRL Distribution Points.

You still want to use your private PKI to distribute computer certificates to the DirectAccess clients and the UAG DirectAccess server. You also want to distribute computer certificates to any machines that you want end-to-end IPsec transport mode protection. And you want to make sure that the CRL is available so that you can revoke certificates (however, revoking certificates for DirectAccess clients is not an effective way to prevent them from connecting to the DirectAccess server – other methods should be used, such as disabling the computer account for the suspect DirectAccess client and changing the password of the user who lost the DirectAccess enabled computer). And you want to be able to use autoenrollment to make is easy to distribute the certificates.

The commercial certificate and the private certificates have no relationship to each other and don’t need any. The commercial certificate provider should be included in the Enterprise Root Certificate Authorities store on all your DirectAccess enabled machines.


“And you mentioned that you wouldn’t want to host the CRL on the DirectAccess server in a production environment.  Is this only because of performance reasons or because of something else?  And is this CRL not related to the IP-HTTPS listener?  So, just to make sure I’m getting it, there is one CA and a corresponding CRL for the active directory domain, and then another CA/CRL (in this case commercial) for the DirectAccess connections.  Is that right?…”

Public and Private CRL Distribution Points

There are a number of reasons why you wouldn’t want to host the CRL Distribution Point web site on the UAG DirectAccess server, but probably the main one is that every time you reconfigure the DirectAccess settings using the UAG DirectAccess wizard, it will end up resetting your CRL Distribution Point web site. There are also traffic related reasons – since the CRL check requires anonymous access to the CRL Distribution Point web site, you increase both the amount of traffic and the attack surface on the UAG DirectAccess server.

You are correct that there are two CRLs in use in the DirectAccess scenario discussed here:

  • The CRL maintained by the commercial certificate provider – they do all the work and you don’t need to worry about it
  • The CRL maintained for your private PKI – which is used for revoking certificates delivered by your private certificate servers. You are responsible for managing this CRL and CRL Distribution Point

It’s important to note here that only a “soft” CRL check is done when the DirectAccess client connects to the UAG DirectAccess server. If the DirectAccess client fails the CRL check, it will still be allowed to connect. So whether or not the CRL is available doesn’t determine connectivity for your DirectAccess clients.



Tom Shinder
Principal Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time):
Follow me on Twitter:

Visit the TechNet forums to discuss all your UAG DirectAccess issues

Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki http://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx

Comments (5)

  1. Anonymous says:

    Good post as usual. I've tested revoking the machine certificate but the system still connecting with the UAG server. How the authentication process works that a computer without a valid certificate has the ability to establish the tunnel.?

    Thanks so much

  2. Anonymous says:

    Hi Davison,

    There are potential issues with using .local on name resolution so we typically recommend that you don't use the .local label for your top level domain name.

    The subject and SAN names on the certificates don't need to be related to the actual names used for the machines or domain.

    For the IP-HTTPS certificate, we recommend that you use a commercial certificate since they handle the CRL Distribution Point and make it highly available for you. If you use your own private PKI for the IP-HTTPS certificate, you'll need to make sure that it's highly available.



  3. Anonymous says:

    Hi Davison –

    No problems! Actually, it's my bad because I planned to put that information in the main body of the article and I forgot 🙂

    You can find information on how to create the CSR at technet.microsoft.com/…/cc441488.aspx After you obtain the certificate, install is the local computers Personal certificate store, as described in the article.

    You are correct" the reasons a highly available private CRL is no needed for the private PKI is because we do a "soft" check, so even if CRL check fails, the clients are still able to establish their IPsec tunnels (which require client certificate authentication for both the infrastructure and intranet tunnels).



  4. Davison Long says:

    Thanks for the clarifications, Tom.  But I'm still a little confused as to how I actually install a third party certificate for the IP-HTTPS listener.  Where/how do I create the CSR to send to the commercial provider and where do I import the certificate?  Do I use IIS7 or the Certificates console?  I've done it on a Windows server for a website or Exchange, but I don't see any info on the specific procedure in this case.

    And finally, if I'm using a commercial certificate for IP-HTTPS, does the CRL distribution point for the private PKI need to be available on a public web site at all?  (I thought using a commercial certificate mitigated the need for a highly available CRL).  Or is the reason a highly available CRL is not needed for the private PKI because of the "soft" check?

    Sorry if I'm asking stupid questions.  I'm just trying to wrap my head around everything.

  5. Davison Long says:

    Thanks so much Tom.  I thought it would be pretty easy.

    Now that I've got some time to work on this I have one more question about which I haven't found any info yet:  I typically have been using a ".local" domain suffix for setting up Windows domains due to the ease of not having to deal with any additional DNS configuration for the "real" website domain on the internal network.

    However, since the TLG is using a ".com" suffix and because there are certain URLs that need to be exposed to the internet, will using an invalid suffix like this be a problem for DirectAccess?  Do the DNS records used for IP-HTTPS and the CRL distribution point need to match the internal domain suffix or can they be use a different suffix?  (i.e., the internal domain suffix is company.local, but the IP-HTTPS cert points to da.company.com and the CRL distribution point is crl.company.com)