This change in code signing will only affect customers with highly secure, isolated Web and Application Server environments that cannot reach the Internet. Extra caution should be taken with code signing, since typically test environments are not as thoroughly secure as production environments. To properly test code signing, if the production environment is isolated, an administrator should consider taking steps to make the test environment match the security level of the production environment.
Code signing is a way for customers to verify the integrity and authenticity of software binaries that they receive from Hyland. Microsoft created Authenticode, a code signing technology that is used on Windows operating systems and is what Hyland uses to sign binaries.
Hyland uses Authenticode code signing to provide customers with some assurance that the files they receive from Hyland have not been tampered with since they were built, and to verify that the files came from Hyland. This helps prevent attackers from replacing Hyland's binaries with malicious ones or modifying existing binaries to execute malicious code. Since Hyland's binaries are signed, administrators can verify that a particular file was signed by Hyland Software and therefore hasn't been modified or replaced since it was installed.
Authenticode signing uses a certificate to sign a file with a digital signature. When Windows tries to load a file with an Authenticode signature, it will first verify the signature. Windows does this by recreating the digital signature and comparing it with the signature embedded in the file. The certificate used to sign the file is also checked to make sure it is valid. If both of these checks are successful, the Authenticode signature is considered valid.
If a file has been Authenticode signed with a certificate that has since expired, the signature itself can still be considered valid if it includes a timestamp that was created by a timestamping service. A timestamping service will add a timestamp to the signature at the time of signing, asserting that the binary file was signed at that particular time. If the timestamp shows that the binary file was signed during the period in which the certificate was valid, then the signature can still be considered valid as well. It is considered a best practice to use a timestamping service as Hyland does so when signing binary files.
When executing a binary file that has an Authenticode signature, the signature verification itself adds negligible overhead to its startup time. Windows will try to validate the certificate used to create the signature. This validation includes whether or not the certificate has been revoked by a Certificate Authority (CA).
To determine whether a certificate has been revoked, Windows uses the Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRLs) to get information about the status of the certificate. OCSP and CRL checks can sometimes cause network requests to be made, in order to get the latest information from Certificate Authorities. In environments where there is limited or no Internet access, this can cause startup delays due to the network requests waiting to connect and timing out. A delay that is related to code signing will only occur before the User Interface is presented, if one exists.
There are a number of changes that can be made to an environment or machine to reduce the startup delay caused by CRL or OCSP network requests timing out in a limited connectivity or offline environment. Some indicators that code signing may be the cause of your issue include:
-
Windows Services take the full 30 seconds to start before failing in an environment with limited network connectivity.
-
OnBase Clients seem to hang during startup, but before the user interface is presented.
If you believe long startup times or service failure issues are related to Hyland's code signing, contact your first line of support to discuss potential solutions.