I've managed to configure my embedded tomcat to use a keystorefile and it works when i execute the project from eclipse.
The code is simple:
...
String keystore = new File(MyServer.class.getResource("/keystore").toURI()).toPath().toString();
httpsConnector.setAttribute("keystoreFile",keystore);
...
The file keystore
is located in a source directory added to the buildpath.
After exporting the project to an executable jar, i can verify the existence of the keyfile
in the root of the jar.
But on executing the jar, i get this error:
Exception in thread "main" java.lang.IllegalArgumentException: URI is not hierarchical
So i asume, that i can not configure the keyfile with httpsConnector.setAttribute("keystoreFile",...)
. is there another way to configure that? i really dont want to copy the keyfile in a temp dir and reference it from there.
I sympathize, but it looks like you will have to just that. A Java keystore can be loaded from any type of input stream (see Keystore.load) so you would think it would be possible to load your keystore from a resource in the jar file. However if you search the Tomcat 7 source code for the string "ks.load" you will see that it always interprets the keystoreFile attribute as the name of a
File
and creates a FileInputStream which it then passes the ks.load.Therefore it will be necessary to create the temp file containing the keystore and pass the location of this file as your
keystoreFile
attribute.BTW - if you are not intending to distribute this jar and are willing to keep it private, then your approach of embedding the keystore is probably OK.
However if you are planning on distributing this jar to multiple sites, then the security of every site is based on the same private key. Furthermore, anyone with access to the jar file can probably extract the private key and can then eavesdrop or perhaps man-in-the-middle attack all of your sites.
In general it is better to have an installation process that requires a new private key and certificate to be generated by the administrator of the site (even if it's just a self-signed certificate). That way every key is different and the only way to compromise the site would be to get access to that servers key store and password.