Share via

Troubleshooting the “No Usable Certificate(s)” IP-HTTPS Client Error

  • Article

[The original version of this posting can be found on "The Edge Man" blog over at http://blogs.technet.com/tomshinder/archive/2010/03/30/troubleshooting-the-no-usable-certificate-s-ip-https-client-error.aspx]

An interesting case came in last week and I thought it would be useful to share it with you all. It’s especially interesting because it covers some not so well documented features of the IP-HTTPS client configuration and how it works.

For those of you who haven’t worked with DirectAccess, or who are in the process of learning about it, IP-HTTPS is a new protocol introduced with Windows 7 and Windows Server 2008 R2 for Microsoft DirectAccess that allows a DirectAccess client to connect to the DirectAccess (DA) server by using HTTP (SSL) as a transport. This enables the DA client to connect to the DA server even when the client is located behind a firewall or web proxy that only allows outbound HTTP/HTTPS.

In this example, the admin had a problem with getting IP-HTTPS connectivity to work. As part of his troubleshooting process, he ran the command

netsh interface httpstunnel show interface

The results were:

Role                       : client

URL                        : https://da.domain.com:443/IPHTTPS

Last Error Code            : 0x103

Interface Status           : no usable certificate(s) found

The problem seemed to be related to the interface status: no usable certificate(s) found.

When the admin checked whether there was a computer certificate installed on the computer, he saw that there was, so it didn’t make sense that there was no usable certificate. Perhaps there was something missing from the computer certificate itself?

To understand the problem, it helps to understand how the computer certificate is used in establishing the IP-HTTPS connection. The DA IP-HTTPS client uses the computer certificate to establish the IPsec tunnel,  just as it does when it’s acting as a 6to4 or Teredo client. However, when acting as an IP-HTTS client, the computer certificate is also used to provide credentials for client authentication when connecting to the IP-HTTPS listener on the DA server.

Client certificate authentication is a default setting on the UAG DA server when the client connects over IP-HTTPS, but it is not a default setting on the Windows DA server. If you want to require client certificate authentication to the Windows DA server (which protects the IP-HTTPS listener against denial of service attacks) you can configure the setting manually by using the information in the article Configure Client Authentication and Certificate Mapping for IP-HTTPS Connections. These instructions will enable the DS Mapper usage feature on the DA server. However, keep in mind that if you are using a UAG DA server, you do not need to do this – the UAG DA wizard takes care of this configuration for you.

You can confirm that DS Mapper Usage is enabled by using the netsh http show sslcert command on the DA server, as seen in the figure below.

http://blogs.technet.com/blogfiles/tomshinder/WindowsLiveWriter/TroubleshootingtheNoUsableCertificatesIP_D55F/image_thumb_6.png

Notice the title of that article. Not only does the setting configure Client Authentication, but it also configure Certificate Mapping.

What is this certificate mapping of which I speak?

If you look in Active Directory Users and Computers and right click on a DA client computer account, you will see the Name Mappings option in the context menu, as seen in the figure below.

http://blogs.technet.com/blogfiles/tomshinder/WindowsLiveWriter/TroubleshootingtheNoUsableCertificatesIP_D55F/image_thumb.png

After selecting the Name Mappings option, you’ll see the Security Identity Mapping dialog box, as seen in the figure below. Here you see that the mapped user account (which is mapped in the Active Directory) is to domain1.corp.company.com/Computers/CLIENT2.

http://blogs.technet.com/blogfiles/tomshinder/WindowsLiveWriter/TroubleshootingtheNoUsableCertificatesIP_D55F/image_thumb_1.png

This name maps to the DNS name assigned to the computer account, which you can see in the Properties dialog box of the computer account, as seen in the figure below.

http://blogs.technet.com/blogfiles/tomshinder/WindowsLiveWriter/TroubleshootingtheNoUsableCertificatesIP_D55F/image_thumb_2.png

In order for client certificate authentication to work, the subject name or a SAN on the certificate must match the DNS name assigned to the computer account. For example, in the figure below you can see that the first SAN shows the DNS name of the computer, which is the same DNS name used by the computer account for this DA client computer.

http://blogs.technet.com/blogfiles/tomshinder/WindowsLiveWriter/TroubleshootingtheNoUsableCertificatesIP_D55F/image_thumb_3.png

So what could cause this problem? It might be that the certificate template used to create the computer certificate didn’t include DNS name of the computer account in the subject name or the first SAN. If you use the default Computer certificate template, you will see that the DNS computer name is used as the subject name in the certificate, as shown in the figure below.

http://blogs.technet.com/blogfiles/tomshinder/WindowsLiveWriter/TroubleshootingtheNoUsableCertificatesIP_D55F/image_thumb_4.png

(Note: the certificate above is from a different client computer than those shown in the other figures, that’s why it shows CLIENT1 instead of CLIENT2).

However, if you use a custom certificate or another certificate template to assign the computer certificate, you will need to configure the template so that the DNS name of the computer is included in the subject name or in a SAN entry.

For example, look at the Properties dialog box for the Workstation Authentication certificate template. On the Subject Name tab, you can select the option Build from this Active Directory information option and then select your preferred Subject name format. If you don’t choose the Common Name or DNS Name option, then you’ll want to make sure that the DNS Name checkbox is selected from the Include this information in alternate subject name list**.** In fact, even if you choose the Common Name or DNS name option, it’s not a bad idea to select the DNS name entry for the first SAN, as there are scenarios that require this.

http://blogs.technet.com/blogfiles/tomshinder/WindowsLiveWriter/TroubleshootingtheNoUsableCertificatesIP_D55F/image_thumb_5.png

It is important to note that this is one of the reasons why you want to use an Enterprise CA in your environment, so that this AD mapping takes place automatically. When the UAG DA server receives the computer certificate from the DA IP-HTTPS client, it will use the DNS name to forward to the domain controller for authentication. If this name does not match the name associated with the computer’s account, authentication will fail.

CONCLUSIONS:

  • On the Windows DA server, client certificate authentication is not enabled by default for DA IP-HTTPS clients
  • On the UAG DA server, client certificate authentication is enabled by default for DA IP-HTTPS clients
  • When client certificate authentication is enabled on the DA server, the client must provide a computer certificate to authenticate to the DA server’s IP-HTTPS listener
  • The subject name or a SAN on the computer certificate must include the DNS name listed for that computer account in Active Directory
  • If the computer certificate does not include the DNS name of the computer, as listed in AD, in its subject name or SAN entry, then you will see that the Interface status will state that there is no usable certificate(s) found after running the netsh interface httpstunnel show interface command
  • If you create a custom certificate template to computer certificates for your DA clients, make sure you include the DNS name to be included in the subject name or a SAN name.

Let me know if you have any questions on this and I’ll follow up in another blog post.

[Props to Billy Price for coming up with this solution]

Thanks!

Tom

Tom Shinder
tomsh@microsoft.com
MS ISD iX
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder