Partager via

Another Cause of the “No Usable Certificate(s) 0x103 Error

  • Article

imageOne of the most mysterious errors you’ll see when working with DirectAccess are related to failures in IP-HTTPS connectivity. I did a blog post on this problem last year and you can find it at https://blogs.technet.com/b/tomshinder/archive/2010/03/30/troubleshooting-the-no-usable-certificate-s-ip-https-client-error.aspx

Phillip Sand clued me into another possible cause of IP-HTTPS connectivity problems. First, whenever you suspect a problem with IP-HTTPS connectivity, you should run the command:

netsh interface httpstunnel show interface

If you see the following:

Role : client

URL : https://da.domain.com:443/IPHTTPS Last Error Code : 0x103
Interface Status : no usable certificate(s) found

Where da.domain.com is the FQDN used to connect to the IP-HTTPS listener on the external interface of the UAG DirectAccess server, then you know you have a problem.

In addition to the cause I mentioned in the earlier blog post is a situation related to the CA certificate not being installed in the NTAUTH store of the UAG DirectAccess server. You can find out if the CA certificate is installed by running the command:

certutil –v –store –enterprise ntauth

on the UAG DirectAccess server. If everything is OK, then you’ll see something like what appears in the figure below (this is what you’ll see if you’re using the UAG DirectAccess Test Lab Guide for your UAG DA lab):

image

If you don’t see any certificate listed, then that can cause the 0x103 error on the client.

You can fix the problem by running the command:

certutil –addstore –enterprise –ntauth IssuingCACert.cer

Where IssusingCACert.cert is the root CA certificate.

Hat tip to Philipp Sand for this great info!

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management
Anywhere Access Group (AAG)
The “Edge Man” blog : 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
    The DirectAccess server definitely needs a default gateway - since it's receiving and sending messages from and to IPv4 hosts on the Internet. HTH, Tom

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    If you are getting an error that the AD is not available, that is significant. Could it be a name resolution issue? A routing issue? A firewall or some other filtering device between the UAG DirectAccess server and the domain controller? Let us know what you find out from your network captures. Thanks! Tom

  • Anonymous
    January 01, 2003
    Very interesting! So, if you're not using autoenrollment for certificate distribution for the server, the server won't get its certificate added to its local NTAUTH store. I can honestly say that I never heard of this before and I really appreciate you sharing this with us! Thanks! Tom

  • Anonymous
    March 15, 2011
    The comment has been removed

  • Anonymous
    March 16, 2011
    The comment has been removed

  • Anonymous
    March 16, 2011
    The comment has been removed

  • Anonymous
    March 22, 2011
    The comment has been removed

  • Anonymous
    March 23, 2011
    Figured it out. We were only using auto enrolment for our clients, not servers. Certificate auto enrolment must be enabled for the NTAUTH local certificate store to exist. That or you can manually create it using: certutil -enterprise -addstore NTAuth CA_CertFilename.cer

  • Anonymous
    March 24, 2011
    Microsoft KB article: The contents of the NTAuth store are cached in the following registry location: HKEY_LOCAL_MACHINESOFTWAREMicrosoftEnterpriseCertificatesNTAuthCertificates This registry key should be automatically updated to reflect the certificates that are published to the NTAuth store in the Active Directory configuration container. This behavior occurs when Group Policy settings are updated and when the client-side extension that is responsible for autoenrollment executes. In certain scenarios, such as Active Directory replication latency or when the Do not enroll certificates automatically policy setting is enabled, the registry is not updated. In such scenarios, you can run the following command manually to insert the certificate into the registry location: certutil -enterprise -addstore NTAuth CA_CertFilename.cer support.microsoft.com/.../295663

  • Anonymous
    March 03, 2014
    Set-DAServer -IPsecRootCertificate $certificate
    Set-DAServer : The system cannot find the file specified

    couldn't find a solution so far...

  • Anonymous
    November 05, 2014
    In case others come across this post (as I did, in search of an answer), here's what I posted as a solution:

    https://social.technet.microsoft.com/forums/windowsserver/en-US/33ce235b-f786-40bf-bcf0-7e819b00c049/setting-up-directaccess-everything-goes-well-hit-finish-and-an-unexpected-error-has-occured