Error 1330 (Invalid digital signature in data1.cab) installing 1.6.0_15

I am running into the same issue, WIndows Vista 32Bit. I have tried installing the digital signature which did not work, I went through MSKB article and tried every method listed and still have not been able to install the JRE...

Is there anywway to get this escalated... or someone we could talk to?

Chuck,

That's not really a fix, it's a workaround; it doesn't identify the actual cause of the problem, nor how to repair it. And it doesn't help in this case, either. We have to be able to digitally distribute via ConfigMgr2007 -- Creating user accounts on the systems is by and large out of the question, and largely unnecessary considering there are 14 other revisions of Java that haven't had this problem.

Anybody else seen this? Somebody from Java have any input?

I was hopeful that maybe the release of 16 would spontaneously correct the problem, but 1.6.0_16 gives the same issue. I don't doubt it's a configuration issue on my systems, but I have no idea what to look for at this point; the usual fixes that I can find by googling, few as they are, haven't helped. Any more suggestions?

I have user also getting this. We are doing silent install and the error is like this:
"Java(TM) 6 Update 16 -- Error 1330.A file that is required cannot be installed because the cabinet file C:\Users\Administrator\AppData\LocalLow\Sun\Java\jre1.6.0_16\Data1.cab has an invalid digital signature. This may indicate that the cabinet file is corrupt. Error 270 was returned by WinVerifyTrust."

Are you getting this on hosts that are completely offline?
This seems like some variation of this problem that Visual Studio had http://blogs.msdn.com/heaths/archive/2008/12/11/another-possible-workaround-for-error-1330.aspx

Were you able to work around it?

I was finally able to solve this; apparently there is a new VeriSign certificate being used on these installers, and my Vista workstations either didn't have it/weren't able to download it, while my XP systems were able/already had it. Once I had that certificate installed everything worked fine.

Do you happen to know the exact VeriSign certificate? Or would aplaying this http://support.microsoft.com/kb/931125 would get the problem resolved?
Thanks in advance.

Hi,

I found this was a problem on our newly installed Windows Server 2008 machine, because we had previously enabled the "Turn off Automatic Root Certificates Update' option in Group Policy.

It appears that for this installation to work, you need a root certificate which is not supplied with Vista/Server 2008 by default, but which can be downloaded via this feature.

If you are having the issue, you might want to make sure that you have not got this Group Policy option set, and also that Automatic Root Certificate Update is enabled under Add/Remove Programs / Add/Remove Windows Components / Update Root Certificates (under XP/2K3). I don't know if there is an equivalent feature that can be disabled/enabled under Vista's 'Programs and Features' control panel, but it is possible.

If this is enabled already, and you don't have Group Policy set, you may also want to check your Application Event Log for events from 'crypt32', especially Event ID 8, which may indicate that the automatic root certificates update process is not working. In particular, if you are running on a network with a proxy, you may need to configure machine-level proxy settings for your computer using proxycfg.exe - see the 'More Information' section of [http://support.microsoft.com/kb/317541|http://support.microsoft.com/kb/317541] for more details.

Hope this helps - it certainly worked for me!

Chris

Edited by: Borgquite on Oct 23, 2009 7:45 AM

Edited by: Borgquite on Oct 23, 2009 7:47 AM

Every system I have come accross with this error is solved with the cmd

regsvr32 initpki.dll

Update 16 installs just fine afterwords.

Borgquite, RAC_Reaper,

Thanks on your tips, much appreciated. I'll check that on the problematic systems. I suspected of a missing root certificate from the get go.

Hello all,

Just though I would share my findings on this issue.

I'm a Information Assurnace engineer for a large communications company. I'm responcible for developing security solutions for a vast array of Windows based devices. Recently it had come to my attention that our security solution was blocking the install of the JAVA Runtime Enviroment. I naturally set to work on a resolution and here is what ultimatly solved this problem. I noticed that the JRE install worked on a freshly installed copy of the OS, but after applying security settings. . .they immediatly failed. I was able to root cause our failure to two registry keys. Below is the details:

Please note, that we had this 1330 error due to the fact that our prodcuts are NOT connected to the internet, hence they are off-line.

This solution worked for: XP, 2003, 2008, Vista, and 7.


WARNING: I cannot be held responcible for any issues the below may cause. Plase use at your own risk. Take good notes so that you can restore the two settings below to the origional "as found" values. Exporting the registry key before making changes is a good idea, that way it can be restored.


Basically there are two registry keys that can cause the JRE install to fail with 1330.

The first Key is a very complex beast. It is located in:
Registry Hive:     HKEY_CURRENT_USER
Subkey:           \Software\Micorosft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\
Value Name:     State
Type:           REG_DWORD
Value:          23c00

The default windows value for "STATE" should be 23c00 in hexidecimal / 146432 decimal. If the STATE value is NOT 23c00, then someone, or something changed this setting for a reason, and this is the root cause of your problem. Now, the quick and easy fix is to set this key back to 23c00 HEX. But you may want to investigate why this value was changed. . .it may be important.

The resason why this settin is complex, is because the BINARY representation of this number activates a bunch of switches related to .NET security. 23c00 = 100011110000000000 in BINARY. Look at page 65 of this document (http://iase.disa.mil/stigs/checklist/dot_net_checklist_v1r2-3.pdf) to understand the individual switches, as I don't have the time to explain them here. Please note however, that the DISA / FDCC / CIS security requriments for this setting is 10,000 HEX or 010000000000000000 BINARY, or 65536 DECIMAL. If you see this number, some form of security has been applied to your box. Please note that 10800 HEX, or 010001000000000000 BINARY, or 69632 DECIMAL will also fix the JAVA 1330 problem.

Lastly, since this setting is based on a "per-user" basis. . .this is the reason why logging into another account to install JRE sometimes works. If this setting was set in a LGPO or GPO. . .then all accounts would fail. But if this setting was only set in for one user, then all other user accounts would allow JRE to install.

NOTE: The above setting will fix 1330 ONLY if JRE had been installed previously. If the above setting does not resolve the problem, then you will need to change the following registry as well.

Registry Hive:     HKEY_LOCAL_MACHINE
Subkey:           \Software\Policies\Microsoft\SystemCertificates\AuthRoot\
Value Name:     DisableRootAutoUpdate
Type:           REG_DWORD
Value:          1

Quite simply, this registry value should NOT exist in a default install of any Windows OS. Once again, if this value exists someone or something has applied some level of security to the computer. Simply deleting this value (in conjunction with the about value) will enable JRE offline to install without errors.

PLEASE NOTE: It's probably a good I idea to put these registry settings back to how your found them when you are done installing JRE. . .as these settings are important security settings.

Hope this helps,
Regards
Boliskmail