Get rid of Signed Java Applet Security Dialog - java

this might be a ridiculous question.
I have a signed applet which only read and write on the client's computer file system.
I can purchase a digital certificate from the Well known authority like Verysign or Thawte etc. to sign the applet.
If i sign applet using above mentioned authority can i get rid of this ambiguous Security verification held by Java Plug-in ?
someone says in SO that you can configure policy file and you can get
rid of this. may i know how ?
Thanks

The best way to get rid of the dialog is to import the certificate into the JRE trusted certificate store. Another solution is to modify the Java policy file.
Just have a look into Oracle's documentation: http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/plugin.html#gcexdl

Related

Java code to get IE browser certificate

Is it possible for a java web application to get digital certificates installed in Browser. What I am looking for is I will read the digital certificate from the browser and based on the certificate, I will give certain access. I tried to search in stackoverflow but did not see any similar questions.
To make things more clear, we have users have company issued laptops and has company specific digital certificates installed. Now my web application should allow or deny access based on whether these digital certificates are available. From the browser I can see the certificates as shown in the following image
I am looking for some method like getting all the certificates based from httpservletrequest(i know its not available, but just giving reference so that someone can point out if api of some sort is available and if it is really feasible/). Read the certificates one by one and get details like who issued it, what is the expiration date, CRL Distribution points, etc.
I know it may be a dumb question and may have security flaw, but still going for it.

Professionally sign an applet

I've made a Java applet and I self signed it before, but due to security changes in recent Java updates, self signing no longer gives the applet the necessary permissions.
I need the applet to be able to read the local file system to use images and to be able to connect to a MYSQL database.
The applet used to work with the database when I self signed it, but not anymore.
In addition, many unknown users will be using the applet, so I won't have control over their machines.
Where can I get my applet professionally signed and if possible, is there another way to self sign that will make the applet work?
Purchase a certificate from any reputable certificate authority. Use that to sign your code. List of CAs
Or, some companies also do this: Sign the jars themselves, but pre-populate the JDK trust store with your (self created) CA cert. If you have control over the JRE that is installed on all user machines, you can place your certificate in JRE/lib/security/cacerts so that is trusted ahead of time.
update: This page (Java Control Panel Documentation) describes what type of signature is required for various client side security level settings:
As long as the applet 'phones home' to the DB & this demo. of the JNLP API file services1 works for the problem machines you should be set to go for a Plug-In 2 JRE (1.6.0_10+) JRE. And if the client has less than that, they should seriously look to update. The Deployment Toolkit Script can assist with that.
It is relevant in that:
It uses a self signed certificate
It allows a sand-boxed app. to read/write to the local file system.
An applet launched using JWS has access to the API.
This should only be considered a work-around. The correct way to solve the problem is to heed the advice offered to get a certified code certificate. Oracle seems to be heading towards making it so that unsigned or self-signed code will not just be sand-boxed, but entirely forbidden (& that is for the best).
As an aside re. DB access: For the protection of the DB. The applet should be forced to go through a 'public interface' (via the site that hosts the applet). Do not give the applet direct access to the DB. Otherwise hackers also have direct DB access.

requesting a .java.policy file from URL security risk

My client wants to use an applet to do drag and drop file transfers from the browser. We have everything working for the most part, but the .java.policy file granting the applet file system access needs to be uploaded to every client in order for the applet to have permission to read/write to the file system.
My technical counterpart at the client has just done some research and wants me to look into the java deployment toolkit (a js library that takes care of deployment instead of using html tags). He wants me to see if I can configure the applet to use a policy file requested from a URL. I haven't been able to find how to do this, which is what I expected, since I think it would be a terrible security risk.
The trouble is that they need to be able to grant the applet read/write file system access, but I feel that requesting a policy file from a URL is a bad idea and I need help explaining why.
So that's my question: is requesting a .java.policy file from a URL even possible? If so, isn't that a terrible security risk?
So that's my question: is requesting a .java.policy file from a URL even possible?
Yes it is, but not in any way that is practical. The thing is:
The policy file needs to be in a certain location on the local file system, in order to work.
Any Java app. or applet would need trust to place it there, or even find out where the right location is.
A Java app. needs extended permissions to be able to import the policy file to where it will have an affect.
If a Java app. has the permissions to insert the policy file, it is already trusted.
If so, isn't that a terrible security risk?
Yes, it would be.
If this applet needs trust, digitally sign it.
Addendum
See Java 7 Update 21 Security Improvements in Detail for more info. on the ever tightening Java security environment.
It is apparently planned to have a future JRE default to maximum security. That would mean that by default, only classes in a Jar, digitally signed by a certificate issued by a Certification Authority (e.g. Comodo $180/year, Thawte $300/year) would ever run. Everything else would be rejected.

access denied ("java.net.SockerPermission" "irc.esper.net" "resolve")

I'm getting this error in my applet when I run the applet embedded in a webpage:
acess denied ("java.net.SockerPermission" "irc.esper.net" "resolve")
It works fine when I run the applet otherwise...
How do I fix this?
Its just like this. You dont talk to strangers! the same way, an unsigned applet is a stranger if it is accessing from outside. Signing is just a process of establishing a trust between two entities. that is your system shall agree to provide permissions for this applet on a run.
You need to sign the applets using a digital certificate. i think you have a basic idea on certificates. you can generate certificates using keytool in java. After you generate, there should be a common trustee (Certified Authority[CA]) to say your certificate is valid and not a fake one. the imprint of that CA is called signed certificate.
You can also have a self-signed certificate. But the browsers will show a warning that certificate is not trusted, and ask the user that whether to trust?!. If user says Ok, then ur certificate is added to browsers Truststore.
Please go through some documentations on this. http://www.herongyang.com shall be a good option for some hand-on!
If your applet is unsigned, it is only allowed to open sockets to the same host from which it is loaded by the web browser. So, you need to either host your applet on irc.esper.net or obtain a signature for it. A self-signed certificate is sufficient for this (obviously, the user will have to confirm the notice that appears).
See http://download.oracle.com/javase/1,5.0/docs/guide/plugin/developer_guide/rsa_signing.html for instructions on signing.

How to install own certificates into system certificates storage?

I would like to develop an own API for Android that will request "Signature" protection level and will be accessible for 'my" applications.
Idea is following:
"install" my own certificate into system certificates storage
sign "trusted" application with my own certificate
As a result during request from any application to my API system will check if this application is signed with an appropriate certificate. If my sertificate is installed into Android everything should be fine.
I'm going to prototype that approach, but if there is something obvious that can prevent me from doing that - please let me know.
The question:
how to install own certificate into system certificates storage (assuming we will build Android ourselves and can modify system (in a reasonable borders))?
Thank you very much.
P.S. I'm not very familiar with Java/Android development, so please don't mind if you see something strange.
UPDATE:
As I wrote in a comment to zeetoobiker's answer, If I sign my API with my own certificate then it will be accessible for all my applications (signed by my certificate), but it won't have any system permissions. And I don't want all my 'customers' to navigate to the "realmb.com/droidCert/" web site. Instead I want manufacturer to add my certificate into an OS, now I'm working on making a proof of concept.
I don't think you need to install the certificate.
From the permission docs for signature:
A permission that the system grants only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user's explicit approval.
This means that it's the certificate you use to sign the apps that matter (not any installed certificates) - if you sign App 1 and App 2 with the same certificate then it will have permission. If App 3 which is signed with a different certificate attempts to access the API then it will get a no permission exception.
According to the docs (I have to admit I've not done it although I'm looking at for some of my apps) it should work on vanilla Android without any necessary customisations / access to the device / root.
If you really need to install the root certificate, this may help but I don't think you do for your stated aim.

Categories