locked
Offline Revocation Server Error

    Question

  • We have installed the Softgrid client on a number of XP and Vista machines.

    A refresh after a logon always results into the following error on some of the XP and Vista machines:

     

    The revocation function was unable to check

    revocation because the revocation server was offline.

     

    Error code: 450260-24C02F2A-80092013

     

    We think that those machines who generate this message don't use the proxy as defined in IE.

    Defining a proxy in the Softgrid client neither solves the problem.

     

    Why does it work on some of the machines? How do we have to solve this problem?

     

    Friday, December 07, 2007 10:04 AM

Answers

  • We've indentified this is a Windows configuration issue around validating the CRL.

     

    I've posted the solution below. 

     

    Problem:

    The customer is using a 3rd party Certificate Authority to issue certificates to their SoftrGrid Servers.  The SoftGrid clients are having an issue trying to validate the certificate revocation lists (CRL’s) that are outside the customer’s network (i.e. hosted at VeriSign so the client must traverse a proxy server).  If we can’t validate the CRL (during server auth), then we fail the connection (by design).

     

    What’s going on?

     

    In our 4.5 release, our TLS implementation uses (Windows) Schannel.  What this means is our client passes the request to validate the CRL (as part of the server authentication process) to Schannel.  Schannel makes this call using the LSASS.EXE process and is executed under the System context.

     

    In order for Schannel to make the call to validate a CRL, which traverses a proxy server, we need to provide the local system with machine wide proxy settings so it can validate the CRL.  By implementing the solution outlined below (either by GPO or script), the machine should then be able to successfully traverse the proxy to validate the CRL.

     

     

     

    What’s the solution?

     

    We need to provide the local system with machine wide proxy settings so it can validate the CRL.

     

    For Vista clients, the customer should use netsh winhttp set proxy command to configure machine wide proxy settings.

     

    ex. netsh winhttp set proxy proxy-server="http=myproxyserver.company.com"

     

    For XP clients, download the tool http://support.microsoft.com/kb/830605 from here to set the system settings.

     

    Regards,

    Gene Ferioli

    Monday, March 03, 2008 5:45 PM

All replies

  • Sounds like you're using RTSPS.  The client, when trying to authenticate the server, cannot retrieve a valid certificate revocation list (CRL) based on the CDP attribute in the certificate.  If the SG client can't check the crl, then we fail connection.

     

    Regards

     

    Gene Ferioli

    Senior Program Manager

    Application Virtualization

    Microsoft Cambridge Office

    Sunday, December 09, 2007 4:32 AM
  • Gene,

     

    Yes, we use RTSPS to stream the application to the client.

    But other desktops on the same network using the same proxy can retrieve a valid certificate revocation list.

    What could be wrong on the machines which cannot retrieve the certificate revocation list?

    All the machine have the same proxy configuration.

     

    Sunday, December 09, 2007 5:27 PM
  • I would try connecting manually from the clients to the CDP.  Can the clients resolve and download the crl?

    Sunday, December 09, 2007 5:44 PM
  • We manually connected to the CDP and downloaded the CRL with success using IE and its proxy configuration.

    Obviously the Softgrid client does not use the proxy setting defined in IE nor it uses the proxy settings as defined in the Softgrid client.

    Monday, December 10, 2007 1:32 PM
  • We need to better understand why some machines succeed with RTSPS and others fail.  I would recommend doing a netmon capture of a "good machine" and a nemton of a "bad" machine.  Then, compare/contrast the differences.

     

    Gene

    Monday, December 10, 2007 1:46 PM
  • I had the same error on my clients after setting up my lab environment. The network service account did not have read permissions to the certificate. It may not be the same issue you are seeing as some of your machines work, but when I gave Network Service Read permissions to the certificate, it worked. I had gone through the same steps of downloading the certificate chain etc with no changes to the situation.

     

    Here is the path: C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys. In "Microsoft SoftGrid 4.5 Component Installation Details Guide" on page 11, there is a descprition of a utility to determine which item in MachineKeys is the correct certificate.

    Tuesday, December 18, 2007 9:13 PM
  • Michelle,

     

    In our enviroment we have a proxy server for accessing the internet.

    We have used the Microsoft Network Monitor and detected that the Softgrid Client on Vista does not use our proxy settings and tries to access i.e. crl.globalsign.net directly.

    We believe it is a bug in the Softgrid Client.

    Thursday, December 20, 2007 1:13 PM
  •  Joop van Bussel wrote:

    In our enviroment we have a proxy server for accessing the internet.

    We have used the Microsoft Network Monitor and detected that the Softgrid Client on Vista does not use our proxy settings and tries to access i.e. crl.globalsign.net directly.

    We believe it is a bug in the Softgrid Client.

     

    There is a manual HTTP proxy setting in SoftGrid Client that might help in your case... but I cannot guarantee if it works properly as similiar RTSP proxy setting has been known to not work correctly. Test it and see if it works.

     

    br,

    Kalle

    Thursday, January 03, 2008 7:56 AM
    Moderator
  • We have tried the HTTP proxy settings in the Softgrid client. But without any result.

    After that we used netmon to pinpoint the problem. The results were send to Gene who opened a bug # for it.

    Thursday, January 03, 2008 9:44 AM
  • Gene,

     

    Is there a possibility to test the bug fix during the Beta period?

    Monday, January 07, 2008 4:53 PM
  • Hi Joop,

     

    Sorry to say but there are no plans to release fixes outside of the closed TAP program during Beta. However, if a workaround is found we will post it here and / or on the team blog.

     

    Thanks,

    Sean

     

    Monday, January 07, 2008 6:11 PM
  • We've indentified this is a Windows configuration issue around validating the CRL.

     

    I've posted the solution below. 

     

    Problem:

    The customer is using a 3rd party Certificate Authority to issue certificates to their SoftrGrid Servers.  The SoftGrid clients are having an issue trying to validate the certificate revocation lists (CRL’s) that are outside the customer’s network (i.e. hosted at VeriSign so the client must traverse a proxy server).  If we can’t validate the CRL (during server auth), then we fail the connection (by design).

     

    What’s going on?

     

    In our 4.5 release, our TLS implementation uses (Windows) Schannel.  What this means is our client passes the request to validate the CRL (as part of the server authentication process) to Schannel.  Schannel makes this call using the LSASS.EXE process and is executed under the System context.

     

    In order for Schannel to make the call to validate a CRL, which traverses a proxy server, we need to provide the local system with machine wide proxy settings so it can validate the CRL.  By implementing the solution outlined below (either by GPO or script), the machine should then be able to successfully traverse the proxy to validate the CRL.

     

     

     

    What’s the solution?

     

    We need to provide the local system with machine wide proxy settings so it can validate the CRL.

     

    For Vista clients, the customer should use netsh winhttp set proxy command to configure machine wide proxy settings.

     

    ex. netsh winhttp set proxy proxy-server="http=myproxyserver.company.com"

     

    For XP clients, download the tool http://support.microsoft.com/kb/830605 from here to set the system settings.

     

    Regards,

    Gene Ferioli

    Monday, March 03, 2008 5:45 PM
  • Gene,

     

    Again thanks for your investigation and of course the solution.

     

    I hope the posibility of the SG client to configure a proxy will disappear in the upcoming release. Because the client does use this setting at all.

     

    Tuesday, March 04, 2008 6:50 AM
  •  Joop van Bussel wrote:

    I hope the posibility of the SG client to configure a proxy will disappear in the upcoming release. Because the client does use this setting at all.

     

     

    Hi Joop,

     

    Yes, the ability to configure a proxy in the Client UI has been removed and will be in the RC release.

     

    Gene Ferioli

    Tuesday, March 04, 2008 3:22 PM
  • The presented solution of Gene did work. But we did a little more investigation. Below the results:

     

    Decription of the problem:

     

    In our configuration we have configured an automatic proxy configuration (with a proxy.pac) in internet explorer.

    When we install the softgrid client and configure it to only allow secure connections the update of the client does not work.

    The error message is that the certificate revocation list cannot be accessed.

    A network trace revealed that the softgrid client tries to connect directly to the revocation list url instead of using the proxy as configured in internet explorer.

     

    Suggested resolution

     

    In a first response to this problem Microsoft suggested to configure a system wide proxy setting with proxycfg.exe in Windows XP or netsh proxy … in vista.

    We tried this and were successful. The softgrid client now is able to access the revocation list.

     

    Further investigation

     

    We reproduced the problem in a separate environment. If we configure the proxy in internet explorer with a proxy.pac the softgrid client cannot access the certificate revocation list and will not work. However, if we change the internet explorer configuration with a direct proxy configuration (not automatic) the softgrid client is able to connect the revocation list via the proxy server.

    When using proxycfg.exe or netsh we configure a system wide direct proxy configuration. This is the same a configuring a direct proxy in internet explorer.

     

    Conclusion

    The softgrid client looks at internet explorer for proxy settings.

    The softgrid client does not work with an automatic proxy configuration via proxy.pac

    System wide proxy settings are used by the softgrid client if a proxy.pac file is used in internet explorer.

     

     

     

    Thursday, March 06, 2008 10:26 AM
  • I have a problem wirh my vista I can not run the MSN & microsoft word Im 101 in useing computer

     

    Friday, March 14, 2008 4:14 AM