none
IP-HTTPS certificate chain and error 0x800b0109 RRS feed

  • Question

  • Hello friendly neighborhood UAG DA experts,

    We got our UAG DA server running and all was well with 6to4 and Teredo.  However, IP-HTTPS kept throwing the error, "failed to connect to the IPHTTPS server:  last error code 0x800b0109."  I looked this up and found out that it refers to a broken SSL certificate chain.  It turns out that our SSL cert from Entrust requires an intermediate certification authority cert as well as the trusted root cert in order to complete the chain.  In normal HTTPS connections this is no problem, because Windows automatically updates the trusted root certs on both clients and servers, and when using a Web browser to connect to a secure site the intermediate cert is automatically chained (i.e., it does not have to be installed in the local computer intermediate authorities store of all clients as long as it is installed in the intermediate store of the server that is hosting the SSL site).  However, with IP-HTTPS, if the intermediate cert is not specifically installed in the local computer intermediate store of all clients, the cert chain fails and IP-HTTPS cannot connect. 

    So, ultimately this can be solved, since we can distribute the intermediate cert via Group Policy to all DA clients.  However, it would be good to understand why IP-HTTPS would behave differently than a standard HTTPS connection with respect to cert chaining.

    Thank you!

    Wednesday, November 17, 2010 10:55 PM

Answers

  • Hi all,

    The main reason I wanted to open this thread was to learn more about how IP-HTTPS chains certs, and the differences between it and a standard SSL IIS server.  I haven't been able to find much on this topic elsewhere, and I thought that other DA admins might be in the same position and be able to benefit from such a post as well.  I have a good workaround (distributing the intermediate cross-cert via GPO), and I don't want to keep the thread open forever so I'll go ahead and mark the workaround as the answer and close the thread.

    My thanks to all who responded!

    Justin

    Wednesday, December 1, 2010 5:39 PM

All replies

  • I assume the intermediate cert has been installed on the UAG server itself?
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, November 18, 2010 1:34 AM
    Moderator
  • Yep!
    Thursday, November 18, 2010 5:40 AM
  • Yep!


    Hi,

     

    Are you sure your root authority certificate is also deployed in the Trusted Root Authorities?

     

    Have a nice day.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx
    Thursday, November 18, 2010 6:58 PM
  • Yes, because I can easily repro either a successful state or the error state by manually installing or removing the intermediate cert, respectively, from a client machine. 
    Thursday, November 18, 2010 7:07 PM
  •  

    Are you sure you can dowload CRL of this CA using certutil.Exe -url <fqdn of CRL>?

     

    Have a nice day.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx
    Thursday, November 18, 2010 7:10 PM
  • Yes, that works as well.

    URL:  http://crl.entrust.net/level1c.crl

    Status:  OK      Type:  Base CRL (0158)     Url:  [0.0]http://crl.entrust.net/level1c.crl

    Thursday, November 18, 2010 7:50 PM
  • Hi all,

    The main reason I wanted to open this thread was to learn more about how IP-HTTPS chains certs, and the differences between it and a standard SSL IIS server.  I haven't been able to find much on this topic elsewhere, and I thought that other DA admins might be in the same position and be able to benefit from such a post as well.  I have a good workaround (distributing the intermediate cross-cert via GPO), and I don't want to keep the thread open forever so I'll go ahead and mark the workaround as the answer and close the thread.

    My thanks to all who responded!

    Justin

    Wednesday, December 1, 2010 5:39 PM
  • IP-HTTPS seems to share a lot of similarities with SSTP so it may be worth researching if this limitation also exists with SSTP...


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, December 2, 2010 12:01 AM
    Moderator
  • Further update:  It seems as though this problem has gone away on its own.  The only thing I've changed in our DA deployment since the problem was first noticed was to install UAG SP1 RTM.  Perhaps this made a difference, and perhaps not.  I didn't see anything about this specific issue in the SP1 release notes, but maybe some magic happened.  :-)  Either way, I'm glad that this is no longer an issue!
    Thursday, December 9, 2010 11:49 PM
  • Hmmm. Will, SP1 is a good thing and magic is a good thing - maybe they're related.

    Might have been a transient issue with connecting to the CRL?

    Thanks for the follow up!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Friday, December 10, 2010 5:15 PM
    Moderator