failed to connect to the IPHTTPS server. Waiting to reconnect RRS feed

  • General discussion

  • We have installed Direct access 2012 in our environment intermittenly we are getting below are

    Interface IPHTTPSInterface (Group Policy)  Parameters
    Role                       : client
    URL                        :
    Last Error Code            : 0x2afc
    Interface Status           : failed to connect to the IPHTTPS server. Waiting to reconnect

    Tuesday, April 9, 2013 12:14 PM

All replies

  • Have you installed a computer certificate on the client from the internal PKI?

    Hth, Anders Janson Enfo Zipper

    Tuesday, April 9, 2013 2:09 PM
  • I am not sure Anders how can I check

    I have one doubt if we are using computer cert from Internal PKI / CA  and it reachable over internet does that sound ok ?

    Thanks a lot for your help.


    Wednesday, April 10, 2013 10:20 AM
  • I have little information on how your system actually is configured so I have to go with my own experience.

    Each client needs a computer certificate from the internal PKI in order to negotiate the IPSec connection. Look in the local computer store on the client for a computer certificate issued to the client computer (MMC -> Certificates snapin -> local computer).

    Your internal PKI does not need to be accessible over the internet with one exception, if you are using an internal certificate for the IP-HTTPS interface, the client needs to be able to verify the CRL and hence the CRL needs to be accessible over the internet.

    Now, Server 2012 changes this a bit and I don't know how you have deployed your DA-system and what clients you are using (support for Win7 or Win8 only for instance), "DA in a box" etc.

    But the error message usually indicates that the client computer does not have a (valid) computer certificate.

    Hth, Anders Janson Enfo Zipper

    Wednesday, April 10, 2013 11:21 AM
  • I don't understand why connection to IPHTTPS is intermittent It works for 4 days then does not work for 1 day betwee Help appreciated
    Sunday, April 28, 2013 7:34 PM
  • also do we need to exclude that CRL from  NRPT of direct access 2012 ?

    Thanks for suggestion.

    Monday, April 29, 2013 12:22 PM
  • Yes you need to exclude the CRL in your NRPT if it is within the same namespace as your internal domain. Having intermittent issues like you describe may come from the fact that the TTL of the CRL times out and the client fails to download a new.

    Anyway, using a public certificate for your IP-HTTPS interface is in my opinion a better option as you don't have to deal with the CRL then.

    Hth, Anders Janson Enfo Zipper

    Tuesday, April 30, 2013 8:49 AM
  • thanks anders if we will use public certicate for ip-https interface we dont need CRL for authencation ?

    sorry i m not that good with certificates if you could provide more light would be usefull to me.

    I mean how using public cert client will authenticate with CRL.

    Thursday, May 2, 2013 5:05 PM
  • Hi

    CRL is only required to check for certificate revocation. If you choose a public certificate for IPHTTPS protocol, you wont have to deal with CRL as it your certificate provider that publish CRL information on Internet. If you use an internal certificate, you must publish your own CRL information on Internet. It's a common best practice to use a public certificate for IPHTTPS.

    BenoitS - Simple by Design

    Monday, May 6, 2013 11:26 AM
  • I agree with Benoit and Anders, changing to a public certificate for IP-HTTPS should help. They will handle publishing the CRL so you don't need to worry a thing about it. What could be happening now is that the CRL check is failing if you have something with your own publishing of the CRL setup incorrectly, possibly only failing occasionally, and then IP-HTTPS fails the check and won't connect. IP-HTTPS problems almost always turn out to be certificate problems.
    Monday, May 6, 2013 6:30 PM
  • Hi,

    It's possible to check CRL access with a certutil.Exe -url <URL of CRL as included in your IPHTTPS certificate>.

    If you cannot retreive CRL and your CRL copy is expired, you cannot check certificate revocation. You can monitor this with the CAPI2 eventlog on the client side. It's an additional event-log that need to be activated.

    BenoitS - Simple by Design

    Monday, May 6, 2013 6:43 PM