[UPDATE] Oracle just revised the crypto roadmap (https://www.java.com/en/jre-jdk-cryptoroadmap.html), they will not deprecate SHA-1 for codesigning: 2017-03-14 Target date changed from 2017-04-18 to 2017-07-18. Narrowed scope from all SHA-1 usage: only TLS will be affected, *code signing will not not be affected at this time*.
This does not affect, in any way, the fine answer I received below, as it will apply, no doubt, in the future.
--
Original post:
Attempting to run our Webstart-deployed Java application on JRE 9 ea 153, I get the following popup:
Looking further at details, I see that the certificate will still be valid for a while:
, therefore, I am wondering if deprecating SHA1 is the reason?
This certainly does sound like a policy in line with (others' in the industry), but the message doesn't really sound neophyte-friendly (especially if it is meant to face end-users), so I am left wondering.
I looked for a roadmap. This is what I found, but I'm not sure whether I'm interpreting correctly this paragraph correctly:
Disable SHA-1 in certificate chains anchored by roots included by default in Oracle's JDK; local or enterprise CAs are not affected. Signed code that is timestamped before 2017-01-01 is not affected.
as the reason for the failure above. I would very much appreciate a confirmation.
FWIW, our certificate is issued by a CA, which I presume is different from an "enterprise" CA.
Thank you.
If that signed Jar is meant to be used by end-users there is no way a package that was SHA1 signed in 2017 is going to work.
Phasing out SHA1 was announced a long time ago.
Only way would be to install a local CA or something, but that is not going to happen on end-user machines (neither should it).
To sign a Jar for your end-users you need a new valid SHA-256 Cert from your CA, and re-sign any Jar that was signed with the old one AFTER 31.12.2016.
Your cert would have expired in a few month anyway.
Whether you have to dualsign your jars depends on the oldest JVM version you are targeting. As far as i understand it anything >=1.4.2 supports SHA-256. If you want to target even older Versions (hell when i started programming java 1.5 was already considered OLD) you would need something like dual-signing. More Information can be found here and here
"How to dual sign a jar" is probably a new topic because it is hardly related to this question i think.
Related
I formerly signed jar files using a locally installed keystore as part of an automated build. I'm now faced with having to use a hardware-based device, due to recent changes to minimal code signing requirements, and while I've figured out how to do it, I'm seeing extreme slow-downs.
Just as one example, a jar file with 180 classes that I could formerly sign in about half a second is now taking about 30 seconds. As it's going, I see my token device's access light flashing a few times a second, presumably once for each class in the jar file.
Is there any way to speed this up, e.g. some way to reduce the token accesses to a single access for the entire jar file?
It was not an answer, but it is too long for a comment:
If your supposition of an access to the token for any file is correct, then it would mean the hash of the files is also being calculated in the device, not only the signature.
Does your PKCS11 device have a logging option that could show which pkcs11 calls are the device receiving (hash operations are called C_Digest in PKCS11) to confirm?
Maybe with the option mentioned in java keytool with opensc pkcs#11 provider only works with debug option enabled (I haven't tried it)
Since I don't know if there's any way to tell jarsigner to hash by software and to sign by hardware, if you can't find a better answer, maybe you can write your own provider: ( http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/HowToImplAProvider.html ) :
implementing a software hash (MessageDigestSpi, just forwarding the call to the default software java provider)
and a device signature (SignatureSpi, just forwarding the call to the PKCS11 provider configured in java ). I think it was Signature signature = Signature.getInstance("SHA1withRSA", "SunPKCS11") and so on. And analog for KeyStoreSpi.
And then call jarsigner with your provider as parameter.
Try adding -sigalg SHA512withRSA to your jarsigner options.
For further information, check my answer to a related question
I am having a problem with getting a ruleset.xml file to function as expected. I am using a Windows 10 client for testing and to keep things simple, i'm trying to get http://javatester.org/version.html to use version 1.8.0_92 as specified within my ruleset.xml file (below).
Deployment Rule Set - ruleset.xml
There are two versions of JRE installed on my machine i.e. 1.6.0_25 as well as that already mentioned above. Unfortunately, when i browse to the above URL, the instance reported is the 1.6.0_25 version which is not what i want.
In terms of the DeploymentRuleSet.jar file, as you can see this is valid and i have appropriately signed the certificate etc. Additionally, if i remove some essential content from the ruleset.xml file then the DeploymentRuleSet.jar becomes invalid which further suggests that up to the point of reading the file everything is OK...i just can't seem to figure out why this isn't applying. In fact, i've even tried blocking everything by default yet this also doesn't work...Any help and suggestions would be much appreciated.
Thank you!
I managed to figure this out.
The short answer is that I had two different versions of Java running, however one of those versions was x64 whereas the other version was (obviously) an x86 version. The DeploymentRuleSet.xml was working as expected however the x64 version was not firing. It wasn't firing because because i needed to add the site in question into the 'Trusted Sites'. This was due to the enhanced restrictions within IE and come as a result of the 'Enhanced Protection Mode' and 'Enhanced Protection Mode for 64 bit Processes' (i believe it comes under this from the top of my head). Adding the sites in question to the Trusted Sites is not a security issue (for us)given these are national systems we know and use.
Java Applet is signed by Comodo and looks fine. It starts as per picture:
I am not allowed to post pictures so I will try to describe it. The Java Applet starts and it says, "the publisher name is verified and the digital signature for this application was generated with a certificate from a trusted authority"
but when I press on "run" the following is popped up straight away:
"The publisher name is unknown. There is no digital signature for this application."
and the security warning as per picture above pops up all the time the applet is accessed / started. I tried cleaning Java cache and browsers' cache but no joy. I also tried re-installing Java completely to make it thoroughly clean "vanilla" but no dice either. The certificates are not expired, their validity is up to March 2016. I even tried importing the certs into Java's keystore but it did not help. Java is version 8 update 45 (build 1.8.0_45-b15) and it's run on Windows 8. Could anybody suggest anything, please as I am completely lost... Many thanks in advance!
In other words in order to get to the applet I have to click through the warning each time the applet is accessed..
I am able to run applets that have signed jar files on Internet Explorer with Java 1.7 Update 45.
I am however not able to run applets with unsigned jar files.
I tried clearing the cache.
I have also changed the security java control panel settings to Medium.
I still get the error JarSigningException.
Is there any way I can proceed here?
Are only signed jar files allowed? This looks like a major limitation.
Is there anyway I can tweak some settings to get unsigned applets to load?
Any help is appreciated.
Is there any way I can proceed here?
Sure. Digitally sign the code with a certificate that links back to a trusted key chain.
Are only signed jar files allowed?
It is progressing towards that, yes.
Is there anyway I can tweak some settings to get unsigned applets to load?
On your own machine? Probably for a little while longer, as Oracle continues to tighten the security along the lines you have discovered.
For the users? No, nothing that is practical beyond 'educate your users as to the advantages of the digitally signed code', and to 'click OK when prompted'.
The best thing you can do if these are your applets is to sign them with a decent signing key. (Or if the applets are solely for your own use, a self-signed certificate will do once you have imported it into your JVM's keystore as trusted.)
If these are applets supplied by someone else, either convince the supplier to sign them (with a good key), or stop using their applets. Period.
The reason that Oracle are moving in this direction is that applets can do a variety of nasty things to your machine by exploiting security holes of various kinds. Disabling unsigned applets helps protect the user from being a victim of malicious applets ... since the "bad guys" are unlikely to sign their code with a certificate that says who they are.
From appearances, Oracle really screwed up. Not only did they break hundreds of thousands of man-hours worth of benign legacy applets... Having to digitally sign applets between local builds undermines new applet production. They seriously need to give some thought to this.
I guess you can always download and use an old version of Java (one that actually works...):
http://www.oldapps.com/java.php
I will never undestand why have the security slider in the Java settings if it does nothing...
After install, restart your browser.
It works like a charm for me.
I have developed an applet. But when my browser fetches it from the webserver it pops a security warring. I don't want this message to come. Meaning applet should run without the end users permession. How can I do that? Do I need to get my applet signed? If yes, from where can i get it signed? What's the cost of geting it signed?
Your description might relate to a number of problems, such as the code trying to do things which require trust. That does not sound like the case in this instance. If your unsigned code tried to do things that required trust, it would not prompt the user at start-up, but either prompt them when the trusted action is attempted (e.g. for cross site access in later JREs) or just fail with an AccessControlException or similar.
It could be that your applet uses multiple Jars and has run into the mixed code restrictions introduced in Java 1.6.0_20. But the symptoms do not sound quite right for that either.
Is your applet publicly available? What is the URL where I/we can visit it?
As an aside, if your applet tries to break out of the security sand-box, it must be trusted. That means the code must be digitally signed, and OK'd by the end user at the prompt. There is no way around it.
But it does not require a code signing certificate issued from a CA. You can roll your own code signing certificate using the tools of the SDK. I have a few small demos. of code projects that compile and build code before signing it.
You need to get yourself a code-signing certificate. Probably by some "well-known" CA if you want to avoid all warnings. The certificate itself costs money, but once you have it, you can use it to sign as many applets as you want (you do the signing yourself).