Installation of New Code Signing Version of iQSonar

After the release of a new version of iQSonar which has an updated signing certificate, the software should be updated in the normal manner. This document identifies some additional steps that should be executed following the update (especially, if the iQSonar server does not have access to the Internet). The result of an update (when there is no access to the Internet and the additional steps have not bene completed) will be identified as an error seen in the log files. The scan engine service fails to start with error messages like:

Unable to find iQuate Authenticode certificate on plugin iQuate.Sonar.Unity.Adapter.XenServer,
Version=0.0.0.0, Culture=neutral, PublicKeyToken=7ab60d41c2cec0e2 System.Exception:
An error occurred during server initialisation ---> System.Exception:Unable to find any Product Adapters.

The problem is most likely that the IQSonar server does not trust the new Authenticode (Code Signing) certificates used by CloudSphere. Signing the code is an important part of protecting the customer estate from product adapter code that has not been approved by iQuate.

Step-by-step guide 

Assuming that the signing cert for the  iQSonar product has been updated, the new certificate chain to Signing Cert intermediate and root CA's must be accessible on the iQSonar host The resolution for the problem can be achieved using two approaches (depending on whether the iQSonar server is connected to the internet).

Server is connected to the internet

The will typically only fail if the root-certificate is not available. Contact CloudSphere support if this occurs.

Server is not connected to the internet

If access to the internet is not available then a certificates file is provided with the release. The CloudSphere signing cert and its certificate chain can be installed using the following zip file.This file contains the full set of certificates that make up the certification path.

This file is also available in the same location as the iQSonar software release. Certification Path Certificates: http://downloads.cloudsphere.com/iQSonar/DigiCertCA.zip

Follow the following steps to install these certificates:

  1. Extract the certificate files from the DigiCertCA.ZIP

  2. This will create a folder with the following files:

  3. Import cloudsphere_limited.crt certificate file.
    Double-Click on the certificate file. This will display the certificate details as part of the Certificate Import Wizard and provide an Install Certificate... option

    1. Choose the ‘Local Machine’ storage location and click Next (if prompted accept the modification to the certificate store)

    2. Select the Certificate Store - allowing the certificate store to be automatically selected and clickNext

    3. Accept the import operation and click Finish.

  4. Import DigiCertCA.crt certificate file.
    Double-Click on the certificate file.


    Repeat the same steps as the previous certificate.

  5. Import TrustedRoot.crt certificate file.
    Double-Click on the certificate file.


    Repeat the same steps as the previous certificate. However, as this is a root-certificate this needs to be added to the Trusted Root Certificate Authorities Store.

  6. Certificate Revocation Lists

    If the scan engine does not have access to Certificate Revocation Lists (CRLs) then additional configuration is required disable CRL checking; otherwise, the scan engine service startup will fail. Several measures are built-in for security including specialized .NET signatures to ensure the integrity of each binary/DLL in the release. When the Scan Engine is started, the cryptographic signatures associated with the component DLLs are checked to ensure that a trust-chain can be established from the signing certificate to the root CA. If all certificates are published to the local certificate store, then access to the Internet is not required for certificate retrieval operations. The only occasion when additional information is required is when checking for Certificate Revocation Lists (CRLs). CRLs are typically retrieved through internet queries to the associated CA registration point (provided by the certificate). The default operation for the Scan Engine is to check certificates against online revocation lists. Failure to retrieve the CRL will cause the signature check to fail. This means that the DLLs used by the Scan Engine will not be loaded and preclude normal operation.

    This operation is controlled by a configuration key in the Scan Engine configuration file. The key is called Revocation Mode and the available values are:

    1. Online – Build and test the certificate chain and test the certificate against the online CRLs

    2. Offline - Build and test the certificate chain and test the certificate against locally stored CRLs (if available) but ignore any errors due to the lack of CRLs being available

    3. None - Build and test the certificate chain but don’t test for revocation.

If an install is made on a server that that has no access to the Internet, then either offline or none would be suitable values for this setting prior to starting the Scan Engine. An example extract of the configuration file is shown below. The revocation mode is located on line 11. This value should be changed as appropriate.

<?xml version="1.0" encoding="utf-8"?> <configuration> <configSections> <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/> <section name="ArtifactRelationshipConfigurationSection" type="iQuate.iQSonar.Adapter.ArtifactRelationshipConfigurationSection"/> </configSections> <appSettings file="user.config"> <add key="ScanRequestAmount" value="5" /> <add key="SignalRPort" value="33810" /> <add key="EnableTrusted" value="true" /> <add key="RevocationMode" value="Online" /> <add key="DisabledStrategies" value="Cassandra configuration file discovery - Windows,Unix Variant:Unix Variant ~ Targeted Folder Retrieval LS (NIX),Windows Variant:Full Windows Device Disk Folder Index(WMI),Windows Variant:Common Windows Device Disk Folder Index(WMI),Unix Variant:Unix Variant Folders Index,Unix Variant:Targetted Unix Variant Folders Index,ESX:ESX vSphere Scanning,Oracle Database:Oracle Privilege,Oracle Database:Oracle 7 Uniqueness,Oracle Database:Oracle 8 Uniqueness,VirtualBox,LMS Hardware Info" /> <add key="DisabledConnections" value="SSHOVMCLI,PacketAnalysis Provider,SMIS" /> <add key="ActivationUrl" value="http://host1.iquate.com/activate" /> <add key="ImpersonateDomainName" value="" /> <add key="ImpersonateUserName" value="" /> <add key="ImpersonatePassword" value="" /> <add key="DatabaseCommandTimeout" value="120" /> <add key="BuildVersion" value="#VERSIONNO#" /> <add key="EnableOracle11Client" value="false" /> <add key="MemoryAndCpuLogging" value="false" /> <add key="EnableGlasReportDebug" value="false" />

Conclusion

Once the certificates have been installed and the configuration file change made, the iQSonar service should now start successfully.