Freigeben über

UAG DA clients not able to connect using IPHTTPS intermittently.

  • Artikel

Sometime back I worked on a case where UAG DA clients were not able to connect using IPHTTPS intermittently . In such scenarios, we can get initial diagnostic information from DCA(direct access connectivity assistant) logs. So I collected this log at the time of issue and found following for the IPHTTPS interface. more on DCA (https://technet.microsoft.com/en-us/library/gg274289.aspx)

netsh int httpstunnel show interfaces

 

Interface IPHTTPSInterface (Group Policy) Parameters

------------------------------------------------------------

Role: client

URL : https://da.contoso.com:443/IPHTTPS

Last Error Code :0x80092013

Interface Status : failed to connect to the IPHTTPS server. Waiting to reconnect

 

If we do err lookup we could see

 

C:\Err>err 0x80092013
# for hex 0x80092013 / decimal -2146885613 :
  CRYPT_E_REVOCATION_OFFLINE winerror.h
# The revocation function was unable to check revocation
# because the revocation server was offline.
# 1 matches found for "0x80092013"

 

It was clear that client was not able to connect to the CRL. So from the client machine's browser I tried to open this URL https://da.contoso.com:443/IPHTTPS and collected network monitor trace while doing that and found.

 

 1. That admin was using internal Certification Authority to issue the IPHTTPS SSL server authentication.

 2. The CRL checking for this certification was failing as seen below. Double click the picture to zoom it.

 

 

 

 We could see that for URL https://crl.contoso.com/certenroll/samplenameofserver+.crl we were getting URL denied. I found that Admin had published his CRL through ISA server 2006 and this URL path was missing. I engaged our directory services team and they explained that this is incremental CRL update location https://crl.da.com/certenroll/samplenameofserver+.crl .

Then suggested customer to publish this as well along with the usual CRL he has published on his ISA server. Once he did that , we did not see issue occurring again.

 

Conclusion

Given above scenario , its recommended that we should use a public Certificate Issuing authority to issue certificate for IPHTTPS website, so that CRL check can be done easily for this certificate from any external or internet location. But in case if internal CA is used then we should make sure that CRL is available for anonymous access, i.e. we should publish it the way we did through reverse proxy servers like ISA/TMG servers.

We know that CRL check is required for IPHTTPS. If CRL is not available then connection will always fail. In this scenario we had intermittent failures because the client has cached CRL information from AD synchronization. Once this cache expires IPHTTPS fails due to this incremental path not being published and hence not available to external users for CRL download and checking purpose.

Comments