Share via

Signed ActiveX CAB Packages With Java Permissions Won't Install

  • Article

Hello there!

 

My name is Joel Baxter.  I am Senior Support Escalation Engineer on the IE Support Team.  Today I’d like to discuss a recent issue that affects both Internet Explorer 7 and Internet Explorer 8 was uncovered during a recent support call.  The behavior manifests itself as a misleading information bar (aka 'gold-bar') notification which infers a problem with security settings:

IE7

Your security settings do not allow websites to use ActiveX controls installed on your computer.

This page may not display correctly. Click here for options...

IE8

An add-on for this website failed to run. Check the security settings in Internet Options for potential conflicts.

There are other causes for this dialog to appear but the one that very few will associate with it has to do with the way the control was signed.  No amount of security zone setting configuration will prevent this dialog from appearing, while still loading the control.   To make matters more confusing, you may have Windows XP clients running IE7 or IE8 that do not display this message when working with the very same cab files!

When the control fails, a log is generated in the Temporary Internet Files folder, named ?CodeDownloadErrorLog!name={the_failing_object_clsid}.htm    The log, when opened, will identify the class ID associated with the failure as well as the HResult error returned:

*** Code Download Log entry (19 May 2009 @ 11:21:00) ***

Code Download Error: (hr = 800b010b) Generic trust failure.

Operation failed. Detailed Information:

     CodeBase: https://mysite/myIE.cab

     CLSID: {12345678-ABCD-12AB-34CD-123456789ABC}

     Extension:

     Type:

LOG: Reporting Code Download Completion: (hr:800b010b (FAILED), CLASSID: 12345678..., szCODE:(https://mysite/myIE.cab), MainType:(null), MainExt:(null))

--- Detailed Error Log Follows ---

LOG: Download OnStopBinding called (hrStatus = 0 / hrResponseHdr = 0).

LOG: URL Download Complete: hrStatus:0, hrOSB:800b010b, hrResponseHdr:0,

LOG: Reporting Code Download Completion: (hr:800b010b (FAILED), CLASSID: 12345678..., szCODE:(https://mysite/myIE.cab), MainType:(null), MainExt:(null))

In the log sample above, the cab package myIE.cab failed due to a failure logged as HResult 800b010b, which translates to TRUST_E_FAIL.  When Internet Explorer encounters the TRUST_E_FAIL condition during the download and initialization of ActiveX objects, the information bar message mentioned earlier is displayed.  

You can obtain more information about code download failures from the following Microsoft Knowledge Base article: 

252937  How to find more information about why code download failed

https://support.microsoft.com/default.aspx?scid=kb;EN-US;252937

The problem stems from an attempt by Internet Explorer to validate the trust of an ActiveX cab package that contains Java permissions assigned to it.  These permissions are added during the application of the digital signature through the use of an additional signer library.  The Microsoft signing tools included one such signer named javasign.dll

These attributes are plainly visible on the 'Advanced' tab in the Digital Signature,  Details properties.  In the screenshot provided below, you will notice two attributes included by javasign.dll:  1.3.6.1.4.1.311.15.1 and 1.3.6.1.4.1.311.15.2.   If you are familiar with the object IDs related to Microsoft cryptography, you'd recognize that these are implemented by Microsoft Java.

clip_image001

For those not familiar, you can find them in the Microsoft Knowledge Base:

287547  Object IDs associated with Microsoft cryptography

https://support.microsoft.com/default.aspx?scid=kb;EN-US;287547

The purpose of these attributes is to assign a level of permissions to the Java classes within the package.  When the package was signed, individual properties were assigned by the javasign.dll signer.  The command-line options for Microsoft's signcode.exe utility supported -j to specify an additional signer resource.  In this case, it would have been -j javasign.dll and the -jp switch allowed the user to assign specific parameters to be used with the DLL referenced with the -j switch, such as LOW, the Java security level associated with the package.

When these attributes are present on a CAB file, Internet Explorer identifies that the OID refers to a Microsoft Java object.  Even though the contents are an ActiveX component, Internet Explorer follows the OIDs and expects the Microsoft JVM to handle the trust checking.  With no Microsoft JVM installed to validate the digital signature on the CAB, the component fails to initialize and run.  Clients with non-Microsoft Java runtime environments installed cannot complete this validation task.   This is why any machine that still has the Microsoft JVM installed can get the control initialized.

Ultimately, the solution to this problem is to resign the ActiveX packages that were signed in this manner.  Javasign is used for Microsoft JVM components, not ActiveX controls.  Simply omit the "-j javasign.dll -jp <parameter>" from your signing process and you should be able to install and run your objects without this error appearing, provided that the client security settings permit them!

Well that’s all for now.  I hope this information was informative and useful.

 

Regards,

The IE Support Team

Comments

  • Anonymous
    June 04, 2009
    Does this indicate that installing Microsoft JVM will solve the issue?
  • Anonymous
    June 24, 2009
    My system is Windows 2008 Server with IE8, I can not find the files CodeDownloadErrorLog!name={the_failing_object_clsid}.htm  in Temporary Internet Files folder. What should I do ?TIA.
  • Anonymous
    June 24, 2009
    My system is WinServer 2008 with IE8, but I can not find CodeDownloadErrorLog!name={the_failing_object_clsid}.htm in the Temporary Internet Files folder. What should I do?TIA