locked
UAG DA - IPHTTPS 0x103 RRS feed

  • Question

  • Hi,

    if I deactivate teredo on the testclient there is no connection. Netsh int httpstunnel will give


    Interface IPHTTPSInterface (Group Policy)  Parameters
    ------------------------------------------------------------
    Role                       : client
    URL                        : https://crl.mycompany.com:443/IPHTTPS
    Last Error Code            : 0x103
    Interface Status           : no usable certificate(s) found

    I tried Tom's Sh. ideas (certutil –addstore –enterprise –ntauth IssuingCACert.cer) with no success.

    Now I found http://www.forefrontblog.nl/2011/06/24/da-0x103-usable-certificates/

    I see on
    IP:port                 : 0.0.0.0:443
     Certificate Hash        : <hash>
     Application ID          : <ID>
     Certificate Store Name  : MY
     Verify Client Certificate Revocation    : Enabled
     Verify Revocation Using Cached Client Certificate Only    : Disabled
     Usage Check    : Enabled
     Revocation Freshness Time : 0
     URL Retrieval Timeout   : 0
     Ctl Identifier          : (null)
     Ctl Store Name          : (null)
     DS Mapper Usage    : Disabled
     Negotiate Client Certificate    : Disabled

    On the real address (this is fake) I see

    IP:port                 : 123.12.10.120:443
     Certificate Hash        : <hash>
     Application ID          : <ID>
     Certificate Store Name  : MY
     Verify Client Certificate Revocation    : Enabled
     Verify Revocation Using Cached Client Certificate Only    : Disabled
     Usage Check    : Enabled
     Revocation Freshness Time : 0
     URL Retrieval Timeout   : 0
     Ctl Identifier          : (null)
     Ctl Store Name          : (null)
     DS Mapper Usage    : ENABLED
     Negotiate Client Certificate    : Disabled

     

    Is it true that the DS Mapper Usage have to also Enabled on 0.0.0.0:443?


    Regards, Joe
    Tuesday, January 31, 2012 4:20 PM

Answers

  • No, I don't have a specific reason to believe that changing the IPsec cert will fix it. Generally IP-HTTPS probelms have to do with the SSL certificate, not the IPsec certificate.

    The reason I suggested swapping the IPsec cert to the one issued based on the default Computer template is because doing this has resolved other issues for me in the past. For example, I once had an installation where only the infrastructure tunnel would establish on all of the clients. I replaced and redid everything I could think of, leaving the IPsec certificate for last. Turns out it was a certificate that was issued off a custom template, and as soon as we changed over to certificate issued from the Computer template everything started working.

    • Marked as answer by JoeMu Tuesday, February 14, 2012 3:02 PM
    Friday, February 3, 2012 2:55 AM
  • Hi Jordan,

    you are right. Our certificate had the fqdn in subject field but not in SAN field.

    Using the computer template works. The SAN field had the fqdn DNS entry and the original certificate has not.

    • Edited by JoeMu Tuesday, February 14, 2012 3:47 PM update
    • Marked as answer by JoeMu Tuesday, February 14, 2012 3:48 PM
    Friday, February 3, 2012 8:48 AM

All replies

  • No, DS mapper usage is not required on the default binding.

    As long as crl.mycompany.com resolves to 123.12.10.120, you should be fine.

    Do you have a certificate on the client with client authentication intended pupose that has the client's FQDN specified in the certificate's DNS name?

    Tuesday, January 31, 2012 4:56 PM
  • Hello Yaniv,

    thanks for your help. Yes, the client certificate from internal CA is on the clien installed and works fine for teredo.

    Did you have any idea how I can resolve this IPHTTPS-Problem?


    Regards, Joe
    Tuesday, January 31, 2012 6:48 PM
  • Hi Joe

     

    I am having similiar issues, what type of certificate are you using for IP-HTTPS? A public certificate from a trusted authority or a cert from your internal CA?

     

    Amit

     

    Wednesday, February 1, 2012 12:45 AM
  • Hi Amit,

    I have tried two certs from different public CAs (for example Comodo). Both were looking good if  you go to https://uag.company.com. I have tried a second one because the lot of problems have read about…

    Any idea?


    Regards, Joe
    Wednesday, February 1, 2012 8:15 AM
  • Can you confirm that you get a 403 message (with no certificate warnings) when you browse to https://uag.company.com:443/IPHTTPS

    You must get a 403 with no certificate warning when browsing here for IP-HTTPS to work correctly.

    On this UAG box, have you in the past run a UAG portal on the same primary public IP address that you are now using for DirectAccess?

    Wednesday, February 1, 2012 1:50 PM
  • Hi Jordan,

    yes, 403 and no warning.

    There was no UAG SSL-Portal before, just DA, nothing else.

    Any idea?


    Regards, Joe
    Wednesday, February 1, 2012 3:17 PM
  • What certificate template did you use for assigning your machine certificates from your internal CA server? Was it based on the default "Computer" template or did you use a custom template? If custom, can you try replacing that certificate (on the UAG server and your client machine) with one built from the Computer template and try it again?
    Wednesday, February 1, 2012 3:44 PM
  • our template is close to the original computer template. As it is working fine with teredo I think we have there no problem.

    Or did you hear about a certifcate problem for IPHTTPS if it is working with teredo?


    Regards, Joe
    Thursday, February 2, 2012 1:05 PM
  • No, I don't have a specific reason to believe that changing the IPsec cert will fix it. Generally IP-HTTPS probelms have to do with the SSL certificate, not the IPsec certificate.

    The reason I suggested swapping the IPsec cert to the one issued based on the default Computer template is because doing this has resolved other issues for me in the past. For example, I once had an installation where only the infrastructure tunnel would establish on all of the clients. I replaced and redid everything I could think of, leaving the IPsec certificate for last. Turns out it was a certificate that was issued off a custom template, and as soon as we changed over to certificate issued from the Computer template everything started working.

    • Marked as answer by JoeMu Tuesday, February 14, 2012 3:02 PM
    Friday, February 3, 2012 2:55 AM
  • Hi Jordan,

    you are right. Our certificate had the fqdn in subject field but not in SAN field.

    Using the computer template works. The SAN field had the fqdn DNS entry and the original certificate has not.

    • Edited by JoeMu Tuesday, February 14, 2012 3:47 PM update
    • Marked as answer by JoeMu Tuesday, February 14, 2012 3:48 PM
    Friday, February 3, 2012 8:48 AM
  • Great news, thanks for the update!
    Tuesday, February 14, 2012 4:02 PM