共用方式為

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 (https://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.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Forefront iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): https://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder

Visit the TechNet forums to discuss all your UAG DirectAccess issues https://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads

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

Comments

  • Anonymous
    January 01, 2003
    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

  • Anonymous
    January 01, 2003
    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. HTH, Tom

  • Anonymous
    January 01, 2003
    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). HTH, Tom

  • Anonymous
    January 25, 2011
    The comment has been removed

  • Anonymous
    January 28, 2011
    The comment has been removed