I'm trying to use Amazon S3 and Amazon Cloudfront CDN to deliver the jar files of my applet application.
I'm seeing several cache misses of my jars by the java plugin. This is a show-stopper for me, as the size of my application is around 3Mb, and I can't make my customers re-download the application every time.
The problem is that, due to a "security vulnerability issue" the java plugin cache is resolving the IP address of the jar remote host, but Amazon S3 uses a dynamic IP. I guess the same problem would happen with Akamai or any other decent CDN service.
Is there anything I can do?
Well the address has to be resolved at some point, that’s not exactly the problem.
The problem is that the applet wants to make sure the .jars come from the same source as the page holding the applet to make sure nobody is returning malicious jars instead of the originals. But when the sockets are opened using the URL it is resolving to a different address, yes, because you are using a cloud not a single server.
Im sure you can solve it by signing the .jars. That way the applet knows they are originals, no matter the source.
What I do is that I create a certificate manually. Like thie:
keytool -genkey -keyalg rsa -keysize 1024 -alias {put a name for the cert here} -validity 3650 -keystore {.. and a file name here.}
Note this will prompt for you to set a user and password for the certificate.
Then sign ALL your jars like this ->
$1/jarsigner -keystore { the above file name} -storepass password -keypass password whatEver.jar {cert name, from above.}
The only issue I have seen with this method is that since the cert is not signed by a recognized authority in the browser, it will promopt the first time to add it to the trusted certs. Normally not an issue.
Other wise you can:
1) Get a certificate from a recognized authority in the browser (Thwate, Verisign ) ( There are some that will do it for free)
2) Set up an authority and ask your users to add it into the browser's recognized authorities.
Hope this helps!
-Alex
Related
I'm trying to use a Web Service but I have many doubts about the certificates, I'm quite a novice in this topic, The team that developed the web services sent me a document where explains how to use it but to enable the connection, I need to USE a certificate (X.509), I generated p7b certificate from they website and I imported that certificate in my local environment, Using Keytool -import it generate a JKS file but they warn that I should install "Entrust" (Root and Intermediate) certificates that they provide me I used keytool -import with these .cer files and the command generated one .JKS for each file, I installed those cer too, my question is:
To use that web service Which certificate file I need to attach in my implementation logic in java, the jks or p7b ?
How I can use this certificate in all the Test environment? (I don't know if this certificate can be use only in the PC that generates the CSR).
I'm trying to simulate the call with the SOAPUI app i'm getting the authentication error so Probably something is worng with the certificate.
He implemented all using windows certificate store and .NET they can't give me support for keytool.
To do client authentication (also called mutual authentication) in SSL/TLS you (your program) needs not just a certificate but a certificate PLUS PRIVATE KEY and usually intermediate/chain certs. There are canonically 5 steps in the process:
On your computer generate a key PAIR which consists of a privatekey and a publickey, and a Certificate Signing Request (CSR) which contains the publickey. These steps may be done separately, or combined in a way that you don't notice there are both a CSR and a privatekey.
Submit the CSR to a Certificate Authority (CA) along with evidence of your identity and authorization as appropriate, and payment if the CA requres it.
The CA issues an 'end-entity' certificate (in this case a client cert) containing your publickey and identity(ies) plus some other information and gives you this certificate, usually along with an intermediate certificate or sometimes a few intermediate certs that form(s) a 'chain' from the entity cert to a trusted CA root or anchor cert. A 'p7b' file is one fairly common way, though not the only one, of transporting a group of related certs, such as your entity cert plus your chain cert(s).
You return the entity cert and the chain cert(s) to your computer and combine with your privatekey from step 1.
You use the combination of privatekey PLUS certificate chain with various program(s) such as a browser, a utility like curl, or a custom application.
Details of steps 1 and 4 (and 5) depend on the systems and software you use, which you don't specify in any recognizable way, although it sounds like you are ending up in the Windows certificate store. If that is the case, and it is specifically the Personal section of the current-user store (as opposed to a machine account like SYSTEM), then when you run MMC (aka Administrative Tools) and select the Cert Mgr addin, or directly run certmgr.msc, the icon for the cert should have a yellow key at the left:
Contrary to your Q, Java JCE (at least Oracle-was-Sun Java on Windows) can handle this; run keytool -list -storetype Windows-MY -keystore NONE and see for yourself.
However, some (probably many) Java programs cannot. For those, you need a keystore file containing the privatekey PLUS certificates; to create that run the Export wizard and select 'Yes, export private key', then format PKCS 12 (aka PFX) with 'include ... path'.
Recent updates of Java 8 by default can automatically handle a PKCS12 keystore (look for keystore.type.compat=true in JRE/lib/security/java.security) and older versions can do so if the program configures the store type (I don't know if SoapUI does that). For older versions that require JKS, after exporting to PKCS12 to let's say mykey.p12 convert with
keytool -importkeystore -srcstoretype pkcs12 -srckeystore mykey.p12 -destkeystore mykey.jks
What you try to archivee is something called a mutual-authentication. In order to understand the basics you need to understand that the humans have simply concepted a password to lock and unlock informations by the same (symetric) password. Everyone who knows the one password can
read the message
rewrite the message to send false informations
this is dangerous. So they have invented two different passwords, one for writing (private) and a compleatly different one for receive(public), we call them asymetric. The problem in asymetric encryption was, that you can choose free only one password, the opposite password is calculated and can not be choosen freely.
Finally they invented certificates to simplify the process. Certificates contains strong Passwords packed into files. Without looking into the certificates you dont know if the passwords are private or public, that means p7b(pkcsv7b) and jks can contain the absolute same informations. The difference is the format only, like the difference between .doc and .docx.
The second problem
In the big japaneese war's spionage was a big thing, the agents gathered informations about the opposite at the point of tactics and send theese informations to their real lords to find weaknesses in the tactics/strategys. Whenever a spoin has been uncovered he has been turned into a double-agent faking honeypots to let the warlord make wrong decisions and fall into traps.
So as an warlord you must trust your agent ... but, how to be sure? Well, you can ask the other agents about the agent you have the informations from to have the guarantee that the message can be trusted. So the first agent must ask other agents to sign the message too, this question between agents is the CSR! If the other agent(s) sign too, we have a "chain of trust". Ok we have four parties now, the agent, the signing-agent(s) the enemy(hacker) and you.
What must be placed where? Well, assuming you are a warlord (server),
you need the public passwords of all your clients(agents) in a truststore to send them messages(download),
you need to know your private password to encode messages(posts, requests, uploads) your agents sent.
Assuming you are a agent(client/browser) of a warlord inside the enemys lines (open field of world-wide-web), you must store:
your private key, to send messages and sign messages of other agents
the public key of the warlord to encode orders of your master.
You have learned now that a certificate can contain aswell private keys as public keys. How to technically use them?
You lucky, the keytools is open source, download the sources from grepcode (click here) and you will have your implementations by copy-and-paste.
Some hints for mutual-authentication:
The server should not offer its public certificate because all authenticated clients already have the public certificate(key) in their truststore.
The client's certificate should be sent in a non-electronic way (printed as rf-code or whatever).
The client should presented the server's public key and the clients private key in two seperate physical letters (you may noticed if you use the electronic-cash-card (ec-card) you had two letters, one for the PIN and one for the ec-card).
I can't seem to figure out why I can't get my ssl on tomcat in centos 7 to work I have created the ip tables to match the incoming request
I have also set up the server.xml file
with that being said I have followed all of the text book standards and even standards in other tutorials. I have done this on my desktop to test how it may work or may not work, I had no issues with it on my desktop whatsoever.
After building the keystore file like so:
keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA -keystore tomcat.keystore
and as I have already shown with the server xml image set the server up to look at this file.
After doing all of the necessary steps before wasting time and downloading the certificates and importing them I decided to run a test against the server. I plugged the ip address:8443 into the url bar of the browser like so:
and this is what I am getting in return...
Anyone have any ideas of what is going on here? As I said I did all of the same things when trying this on my desktop and got it to work fine there but no luck here.
EDIT:::
Okay so I got the SSL to work, I am still not sure what it was, I think it just took some time for my iptables to pick up. However now I am having an issue when setting the certificates, I set the certificates to the keystore file but afterwards the site practically dies. My question here is that when do I derive the private key for the node balancer that I am using. I imagine that this would have to be done after the certificates are set to the keystore correct?
I currently have a website hosted with Hostgator that has a java upload applet; however, on page visit, the browser blocks the java applet from executing. Reason given is security settings have blocked a SELF-SIGNED application from running.
My question is, how can I get past this, WITHOUT modifying java security levels. I want users to be able to access the applet without getting this error AND without having to modify any of their current browser settings.
(I signed the applet myself using keytool).
Thank you.
There are two ways:
You need to buy a SSL certificate from a trusted party like Verisign or Thawte, or any other (cheaper) trusted provider. Then you need to sign your applet with this certificate instead. Since such certificate will be provided by a globally-trusted party, your users' JVM will automatically trust it.
If you decide to go with the cheaper ssl provider, make sure it's root certificate is in the default list of trusted certificates of the JVM. You can check that, by listing certificates, that come with the installation of Java - like this:
keytool -list -keystore cacerts -storepass changeit
where changeit is the default cacerts keystore password, and the cacerts file can be found in lib\security folder of jour JRE installation - on Windows this will be something like:
c:\Program Files (x86)\Java\jre[version]\lib\security\
Send the public key to your users, and make them add it to trusted certificates of their JVM (usually that means, importing the certificate you provide to the aforementioned cacerts file. This step however requires using keytool and command line and will most likely be troublesome for most of your users.
I have Vaadin application and my applet which integrated in it. When I start my web application every time i see this warning.
In turns when applet begins to start. After I push run and click button on web application to start applet turns new warning.
My boss told that it is ridiculous to show web app with that warnings. But i don't know how i have to sign my applet to turn off this warnings.
Now i sign my applet with this instruction. It will be nice, if you will help me.
In order to get rid of this warning you're going to have to sign your applet.
By default an Applet is running inside a sandbox. This sandbox isolates the applet preventing malicious code from running without the user's granted permissions. Applets are considered untrusted if they are not signed with a security certificate. Unsigned applets are limited to execute only a set of "safe" operations. Unsafe applets cannot execute the following:
Accessing the local file system, executable files, system clipboard,
and printers on client’s computer.
Connecting to any server other than the server where they are hosted.
Loading native libraries.
Altering the SecurityManager.
Creating a ClassLoader.
Reading some of system properties.
In order to sign your applet you'll need to purchase an RSA certificate from a trusted source. You can purchase for RSA certificates from a Certificate Authority (CA), such as VeriSign and Thawte. To obtain a certificate from a CA, you need to provide the certificate signing request (CSR). The steps are as follow:
Use keytool to generate an RSA keypair.
Use keytool to generate the certification signing request, then submit the CSR to the CA.
The CA will send you a certificate reply (chain) by email.
Import the chain into your keystore.
Use jarsigner to sign applet’s JAR file.
Once you have everything all you need to do is sign the JAR with your certificate and you should be good to go. To sign the JAR just do the following:
jarsigner -keystore <keystore_name> -storepass <store_pass> -keypass <key_pass> -signedjar <signed_jar_file_path> <original_jar_file_path> <alias_name>
I have never done https so far, but trying to get grips with it. I understand how to do self-signed certificates which is from what I understood is completely pointless as browsers will fire up straight away the warning. "As one cannot say trust me because I am honest."
From SO posts I understood that Tomcat or any other server environment is responsible for configuration. All clear and good.
The confusion is how these certificate signed when not self-signed. In other words, how do I point my keystore to CA provider.
I am following guide:
http://consultingblogs.emc.com/richardtiffin/archive/2010/10/15/applying-ssl-to-a-spring-web-application-on-tomcat.aspx
The problem is that I don't know what happens after I buy certificate from CA. Do I get a file which I need to point my keystore to or I import keystore itself remotely?
For self-signed we do:
"
Generating a keystore file (Self Certification)
The keystore file is the one which would store the details of the certificates necessary to make the protocol secured, to-do this we'll use the keytool provided as part of JDK 1.6, the following should create the keystore :-
From your Java installation directory %JAVA_HOME%/bin
keytool -genkey -alias emc -keypass password -keystore emc_tomcat.bin -storepass password"
This implies that for not self-signed the details must come from CA provider? So need to add something to the line(URL path?)? Or is it the client responsibility to verify whether my certificate is valid...then how do I link my certificate to the one I purchased. I am completely confused.
Rephrasing other way: how to install CA from official CA providers?
Or I am telling complete rubbish and missing something fundamental. :-)
My apologies if there is duplicate, I've spent quite good bit of time of researching SO and reading wikipedia articles, but the internal mechanics are very difficult for novice users. I've marked bold the actual questions for people short on time. Thanks.
All the information you are asking for is readily provided by any reputable ("trusted") CA. See for example http://www.digicert.com/ssl-certificate-installation.htm
Quoting:
After you create your CSR, purchase your certificate, and the SSL
Certificate validation and processing are complete, you are ready to
install your SSL Certificate(s).
Your certificate will be provided via email or will be available to
download in your DigiCert Management Console. The SSL Certificate is a
text file with encrypted data that your server will use once the
certificate is installed
And following down the Tomcat link:
Tomcat SSL installations can be a bit tricky, but don't worry. Our
knowledgeable support staff is familiar with both the keytool utility
as well as common Tomcat installation methods. We will be happy to
help you generate your Certificate Signing Request (or CSR), install
the certificate to your Java keystore, and configure your server to
use it via either the Tomcat Admintool utility, or by editing the
server.xml configuration file directly.
It seems that this answers all your questions... "buy it and you will see how easy it is".