Direct Access IPHTTPS certificate RRS feed

  • Question

  • Hello,

    I have problems configuring IPHTTPS certificate for Direct Access server. My FQDN of direct access server which clients connect is da1.koncar-inem.hr.

    My question is does my certificate need's to have common name da1.koncar-inem.hr or I can place FQDN of da server in SAN field?

    I configured certificate with common name webmail.koncar.hr and SAN da1.koncar-inem.hr and keep getting error:

    No usable certificate find or when I try to connect to FQDN over IE i get

    404 - File or directory not found.

    The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.


    Wednesday, August 31, 2011 10:35 AM

All replies

  • Hi Igor,

    IPHTTPS should support SAN and also Wildcard CNAMEs. When openig the IPHTTPS FQDN (aka. root "/" URI) in IE you shouldn't see any specific results, since IPHTTPS register only specific URIs in HTTP.SYS. So the best thing you could do is to debug the IPHTTPS client settings to see if IPHTTPS has some problems connectiong to UAG. The command to see if IPHTTPS has some problems is...

    C:\netsh interface httpstunnel show interface

    BTW: UAG has a setup bug in the way its bind the default website (internal site) to When using DA this site gets accessible from the outside (without UAG URL Filters active) because the DA Wizards will create a TCP443 Paketfilter to allow this traffic. So the 404 message you get is most likely a responce from your Default Website (aka. internal site). To see if this is the case for you try using the following URL:  https://da1.koncar-inem.hr/internalsite/languages/en-us.xml If you can access this file (your Portal Trunk would deny it for a good reason), then you still have the default binding in place...




    Wednesday, August 31, 2011 11:10 AM
  • Hi Kai,

    When I run C:\netsh interface httpstunnel show interface I get the following:

    Interface IPHTTPSInterface (Group Policy)  Parameters
    Role                       : client
    URL                        : https://webmail.koncar.hr:443/IPHTTPS
    Last Error Code            : 0x103
    Interface Status           : no usable certificate(s) found

    Also when I try to access https://da1.koncar-inem.hr/internalsite/languages/en-us.xml I get xml open. How can I fix that UAG bug?




    Wednesday, August 31, 2011 9:55 PM
  • Hi Igor.

    1.) Please read the two blog posts below. They will most likely cover your specific IPHTTPS issue...



    2.) I corrected the setup by removing the :443 binding from the IIS Default Website. As far as I see UAG does only use 6001/6002 to access the internal site (as IAG did). Till now i didn't got issues and the setting did not reappear. Keep in mind, this fix is provided "AS IS" so please don't blame me if it breaks your specific environment. To get sure you should contact PSS/CSS to get an supported workaround (if they have one)... ;)


    • Proposed as answer by Kai Wilke Saturday, September 3, 2011 7:20 AM
    Thursday, September 1, 2011 10:58 AM
  • This is a common problem when you have a SAN cert and the common name is not the same as the Direct Access IPHTTPS name. You have to do some manual workaround on the client and server.


    Please check my blog, I wrote up an article explaining this issue and how to solve it. Hopefully this can help you.





    Monday, December 5, 2011 7:08 AM
  • Monday, December 5, 2011 7:10 AM
  • Hey Ahmed, I read your blog post and I wanted to let you know that I do not believe either of the steps you took are necessary (or recommended). When you specify which certificate to use for the IP-HTTPS listener in the UAG config wizards, if you choose a certificate that is a SAN or wildcard you should have been prompted to type in what URL you are actually using for the IP-HTTPS listener. My guess would be that this environment where you had the problem the name was not typed in during that step and so UAG assumed you were using the www main address instead. Because of this, UAG then setup its own listener and the client settings to use www.company.com.

    The correct way to fix this is to re-run the UAG wizards and choose the correct name from the IP-HTTPS screen of Step 2. This will allow UAG to fix itself, and it will also update the client GPO for you. If you modify the UAG server settings and the client GPO manually like you did, the next time that you activate UAG your settings will get wiped out and the incorrect settings will get put back into place.

    Just wanted to give you a warning on what will probably happen the next time you activate that guy. :)

    Tuesday, December 6, 2011 7:32 PM
  • Thanks Jordan for your comments. However in the Direct Access configuration, when you select the UCC SAN cert (didn't try Wildcard), the common name is selected by default and you are not prompted to select another name from the SAN list. This was my experience with 2 SAN certs on UAG SP1 latest updates.
    Tuesday, January 3, 2012 7:03 AM
  • Then it's possible this is a bug. Truth be told, SAN certificates are pretty rare. I can't actually remember ever using one on any of my installs, we always use a new certificate purchased for the single name, or an existing wildcard certificate (which does definitely prompt and ask you to type the listener name).

    Whether it's a bug or something particular with your server, you should definitely fix this by using a different certificate for the correct name. Modifying the DA Clients GPO is a big no-no for obvious reasons :) If you don't you will likely end up having to remember to make these changes over and over every time you make a change to the DA environment.

    Tuesday, January 3, 2012 2:12 PM
  • We are not supporting SAN certificates for IP-HTTPS.

    The prompt to select the IP-HTTPS URL pops up only in case of wildcard certificate.


    Tuesday, January 3, 2012 9:22 PM
  • Thanks Yaniv. Thats why for the SAN certificate (if you don't have other option as the client i checked), you need to do the workaround to make it work for you.



    Thursday, January 5, 2012 6:37 AM
  • Ahmed,

    So, your workaround is to pick the SAN certificate with the wrong CN, and then change the FQDN to the desired one in the client GPO and on the server?

    This seems like a valid temporary workaround. Just note that these settings will be reset to defaults on the next UAG activation and on the Group Policy generation.

    So this still isn't an officially supported scenario.

    Sunday, February 5, 2012 8:50 AM