[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.
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.
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.
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.
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.
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.
(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.
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.
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]
Tom Shinder firstname.lastname@example.org 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