Blueprint 5.0, 5.1, and 5.2 R1/R2: Login delay during Secure Release Here session

Blog Post created by toleary on Aug 8, 2013

When I try to log in to a Secure Release device, there is a 15-30 second delay, sometimes followed by a message: "Session not authorized." If I try to log in again, it works just fine and there is no delay. If I let the system sit idle for a little while, the delay happens again. What's going on?



To provide our customers the safety and security of verified and trusted applications, Pharos Systems digitally signs, via a trusted Certificate Authority, our applications and DLLs and registers them with Microsoft. In many cases, signed applications run normally on the operating system because Windows itself does not check, nor validate, the signature. However, applications which run under .NET (like most of ours) can be an exception, and .Net can request signature validation, and this requires an expensive network-based request. Part of this network request will attempt to contact the Certificate Authority owner and Microsoft to determine if the certificate has been revoked by looking at a Certificate Revocation List (the "CRL"). In many cases, the server hosting the Pharos software is unable to reach an external network (VLAN rules, Internet proxy server restrictions, etc.), and so the requests eventually time out.


However, this check for the CRL -- and its eventual time out -- occurs during the authentication component of the user's terminal session, and so contributes to the "Inactivity Timeout" associated with the terminal. This causes the error message observed on the terminal's display. The subsequent log in (and log in attempts for the next several minutes) are successful because .Net temporarily "remembers" that it was not able to verify the signature for a short time and chooses not to validate the signature during that time.




Microsoft Windows provides, via Group Policy Object, a way to manage certificate checking for systems not able to connect to the Internet. This is described in Microsoft KB article 2677070. The following extract of this article describes the "how to" process to disable the network check.

From Microsoft KB Article 2677070:

If you cannot avoid installing this update on disconnected systems, you can disable the network retrieval of the trusted and untrusted CTLs. To do this, you disable automatic root updates by using Group Policy settings. To disable automatic root updates by using policy settings, follow these steps:

  1. Create a Group Policy or change an existing Group Policy in the Local Group Policy Editor.
  2. In the Local Group Policy Editor, double-click Policies under the Computer Configuration node.
  3. Double-click Windows Settings, double-click Security Settings, and then double-click Public Key Policies.
  4. In the details pane, double-click Certificate Path Validation Settings.
  5. Click the Network Retrieval tab, select Define these policy settings, and then clear the Automatically update certificates in the Microsoft Root Certificate Program (recommended) check box.
  6. Click OK, and then close the Local Group Policy Editor.
  7. In an administrative command prompt, run GPUPDATE to force the local Computer policies (note: this also refreshes the current user's policies as well). Alternately, the computer can be rebooted, but this is not necessary.

After you make this change, automatic root updates are disabled on those systems to which the policy is applied. We recommend that the policy be applied only to those systems that do not have Internet access or that are prevented from accessing Windows Update because of firewall rules.


Further to this advice, it is recommended to disable (uncheck) "Allow issuer certificate (AIA) retrieval during path validation." A completed policy is shown below: