I realise they may well be trying to force site administrators to cough up for certificates (am I right in assuming these are NOT free?) or see their sites rendered useless to the vast majority of visitors (all who regularly update Java).
Code signing certificates signed by a root in the Java certificate bundle are pretty expensive.
There are inexpensive sources of code signing certificates - StartSSL Verified
, which costs US$59.90, allows you to issue as many 2 year validity certificates as you need for 350 days, including wild card server certificates and code signing certificates
. You pay once for the validation, not per certificate.
There are limitations on a StartSSL Verified code signing certificate - there's an OID that prevents the signature from being valid on Windows after the certificate expires (even if the signature was time stamped during the certificate's validity, which normally prevents signature expiry), also you can't sign Windows kernel code with a StartSSL Verified certificate. These restrictions are lifted if you have Extended Verification, but that requires you to be a bona fide business or incorporated organisation.
StartSSL's root is in all the major browsers and operating systems. However, from previous conversations with Eddy Nigg who runs StartSSL, it's not cost effective to get StartSSL's root into Adobe's PDF software or Java - Adobe and Oracle wanted a sizeable amount of money to include the root and I believe wanted per-certificate royalties. You can add StartSSL's root to your own Adobe PDF or Java installation if you wish, but the signatures will not verify on a standard installation.
I guess it shows I'm a huge fan of StartSSL. If you want a 1 year client or server certificate, it's free of charge, so even hobby servers and network devices can use 'proper' certificates. My router and wireless access point have StartSSL certificates for their configuration GUIs!
There's a huge risk in Oracle's approach. Whilst the move to limiting unsigned applications is welcome considering all the security incidents relating to Java in recent times, requiring every application to be signed risks sloppy signing practices.
Most organisations only sign final releases after appropriate code review and security checks - there's a defined procedure to be followed to make a release, and only a limited number of people have access to the code signing certificate.
The correct approach if all applications have to be signed is to generate your own local CA and certificates, and add the CA to the Java certificate store on your development machines. The risk is that instead of doing this, organisations will sign every test build with a 'proper' code signing certificate. After all, a code signing certificate merely allows you to identify whose certificate signed the code - it says nothing about the quality or security of that code, or even if that certificate is still under the sole control of the individual or organisation it was issued to (he says, looking at the security tokens that contain his client and code signing certificates).
The other risk, which is potentially more serious, is that people will get so fed up with all the unsigned application warnings that they revert to a version of Java without the warnings and stop updating.