As it stands the --keystore-password option is required; should it be? We could prompt for the password if all of the other required arguments are present to access the keystore to prevent the password from being stored in bash_history and visible to anyone looking over the user's shoulder.

Additionally, the exception that you get when the --keystore-password option is missing is not very clear:

Problem occured:
Exception encountered:java.lang.RuntimeException: Unable to get keystore ([/path/to/vault.keystore])

There is no reason why it failed to help the user determine what to do :(

$ java -classpath tomcat-vault-1.1.7.Final-jar-with-dependencies.jar org.apache.tomcat.vault.VaultTool
Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  Other: Exit
0
Starting an interactive session
Enter directory to store encrypted files:/tmp/vault/
Enter Keystore URL:/tmp/vault/vault.keystore
Enter Keystore password: 
Enter Keystore password again: 
Values match
Enter 8 character salt:1234abcd
Enter iteration count as a number (Eg: 44):44
Enter Keystore Alias:my_vault
Initializing Vault
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tomcat/util/res/StringManager
        at org.apache.tomcat.vault.security.plugins.PBEUtils.<clinit>(PBEUtils.java:49)
        at org.apache.tomcat.vault.VaultSession.computeMaskedPassword(VaultSession.java:161)
        at org.apache.tomcat.vault.VaultSession.startVaultSession(VaultSession.java:191)
        at org.apache.tomcat.vault.VaultInteractiveSession.start(VaultInteractiveSession.java:77)
        at org.apache.tomcat.vault.VaultTool.main(VaultTool.java:123)
Caused by: java.lang.ClassNotFoundException: org.apache.tomcat.util.res.StringManager
        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
        ... 5 more

Using version 1.1.7 I'm getting this error when trying to run it in interactive mode for testing.

I am using Java 6 and Tomcat 6, but I can up the version of java no problem. This particular error seems to be the same regardless of java 6-8

Is this tomcat-vault.jar available on any public maven repo out there?

Please have a look thank you!

I was writing some documentation for a project that uses tomcat-vault and noticed a potential improvement. When using vault.sh, you have to specify the keystore, keystore-password, etc every time! Example:

$ ./vault.sh --keystore /path/to/vault.keystore --keystore-password my_password123 --alias my_vault --enc-dir /path/to/vault/ --iteration 120 --salt 1234abcd --vault-block my_block --attribute manager_password --sec-attr P@SSW0#D

Can we add an option to take vault.properties in (if you have one) and use that configuration instead? Doing so would shorten the command above to:

$ ./vault.sh -C /path/to/vault.properties --vault-block my_block --attribute manager_password --sec-attr P@SSW0#D

The following is the only logging message that we print when using vault.sh (under normal circumstance):

Dec 13, 2017 8:51:58 AM org.apache.tomcat.vault.security.vault.PicketBoxSecurityVault init
INFO: Default Security Vault Implementation Initialized and Ready

Can we hide that so that it isn't displayed on the CLI? I haven't seen another CLI tool that uses logging messages :)

There is Tomcat 8.0.15+ mentioned as required to run this library, but initializing vault with Tomcat 8.0.28 ends in exception:

Initializing Vault
Exception in thread "main" java.lang.NoSuchMethodError: org.apache.tomcat.util.res.StringManager.getManager(Ljava/lang/Class;)Lorg/apache/tomcat/util/res/StringManager;
	at org.apache.tomcat.vault.security.plugins.PBEUtils.<clinit>(PBEUtils.java:49)
	at org.apache.tomcat.vault.VaultSession.computeMaskedPassword(VaultSession.java:161)
	at org.apache.tomcat.vault.VaultSession.startVaultSession(VaultSession.java:191)
	at org.apache.tomcat.vault.VaultInteractiveSession.start(VaultInteractiveSession.java:77)
	at org.apache.tomcat.vault.VaultTool.main(VaultTool.java:120)

This is because getManager(Class<?> clazz) isn't in older version of tomcat-util.

Files with getManager(Class<?> clazz):

~/dev/tomcat-vault/src $ ack "getManager\(.*\.class\)" -l | sort
main/java/org/apache/tomcat/vault/security/ExternalPasswordCache.java
main/java/org/apache/tomcat/vault/security/Util.java
main/java/org/apache/tomcat/vault/security/plugins/PBEUtils.java
main/java/org/apache/tomcat/vault/security/vault/PicketBoxSecurityVault.java
main/java/org/apache/tomcat/vault/security/vault/SecurityVaultData.java
main/java/org/apache/tomcat/vault/security/vault/SecurityVaultFactory.java

I changed "newer" invocations of this method on my fork to use method with String attribute and it works just fine.

This issue is a result of things I found while working on #56. We need to go back and fix a bunch of incomplete javadocs and fix those invalid @see references.

Every option (except -h) that you can run in vault.sh prints the vault summary, e.g.:

Vault Configuration in tomcat properties file:
********************************************
...
KEYSTORE_URL=/path/to/vault-dir/vault.keystore
KEYSTORE_PASSWORD=MASK-31bRT4dFCADeFjdvZhG8Rq
KEYSTORE_ALIAS=my_vault
SALT=1234abcd
ITERATION_COUNT=22
ENC_FILE_DIR=/path/to/vault-dir/
...
********************************************

Can we add an option to allow users to print the summary when they want to see it? IMO it's unnecessary for every command and adds too much to the output.

I noticed that the default algorithm is PBEWithMD5AndDES .

When you run vault.sh and don't provide a password (or provide an incorrect password) you get the following vague error:

Exception encountered:java.lang.RuntimeException: Unable to get keystore ([/path/to/vault.keystore])

the actual exception is (before it's caught and rethrown as a generic RuntimeException):

java.io.IOException: Keystore was tampered with, or password was incorrect

Is that really intentional? I think we should tell the user that there is an issue with the password rather than a generic error that it can't be loaded which implies that there are other problems.

Looking at the following example:

$ bin/vault.sh --keystore | tail -n1
Missing argument for option: k

only the short hand option reference is displayed. The -k option is obviously --keystore in the example, but when you're actually using the tool it requires many more options and can be confusing.

Here is an example of how ls handles missing arguments:

$ ls -w
ls: option requires an argument -- 'w'
Try 'ls --help' for more information.
$ ls --width
ls: option '--width' requires an argument
Try 'ls --help' for more information.

Following the instructions to configure vault in INSTALL.md, but using a different password for the storepass and keypass when generating the keystore causes vault to fail.

To reproduce, use the following two commands to demonstrate that using a different key and store password fails:

$ keytool -genseckey -keystore /tmp/vault/vault.keystore -alias vault  -storetype jceks -keyalg AES -keysize 128 -storepass storepass -keypass keypass -validity 730
$ bin/vault.sh --keystore /tmp/vault/vault.keystore --keystore-password keypass --alias vault --enc-dir /tmp/vault/ --iteration 44 --salt 1234abcd -g vault.properties
=========================================================================

  Tomcat Vault

  VAULT_HOME: /home/coty/tomcat-vault/lib

  JAVA: java

=========================================================================

Problem occurred:
Exception encountered: java.lang.RuntimeException: Unable to get keystore ([/tmp/vault/vault.keystore])

This generic message (which is what #49 is about) doesn't provide much help to troubleshoot the issue, so users are left not knowing what the problem is.

This repository is marked as a fork of the outdated original repository (jfclere/tomcat-vault). I recall a conversation with @jfclere about this and wanting to 'fix' that problem. In order to remove that reference you can open a ticket with Github support to switch it to 'normal mode'. See excerpt from here:

'To detach the fork and turn it into a standalone repository on GitHub, contact GitHub Support. If the fork has forks of its own, let support know if the forks should move with your repository into a new network or remain in the current network. For more information, see "About forks."'

Alternatively it seems that you can delete the repo, recreate it, and push your local copy up but switching the mode is probably safer :)

Has anyone been able to get this working with tomcat 6? The application launches fine, but then the authentication doesn't work where i substituted the password.

I'm trying to do attribute replacement on a oracle datasource in server.xml

The option description is as follows:

 -c,--check-sec-attr            Check whether the secured attribute
                                already exists in the vault

but the output on line 200 and line 203 refers to it as "Password" rather than "Secured attribute". Not a big deal, but it's still a bug.

The current version stores almost all of the pieces necessary to decode the keystore password in use with the vault. Should we provide users with an option to store none of it and require the password to be entered at runtime?

Against JDK 11, I had the error
[ERROR] Source option 5 is no longer supported. Use 6 or later.
[ERROR] Target option 1.5 is no longer supported. Use 1.6 or later.

I added the plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.0</version>
    <configuration>
        <release>11</release>
    </configuration>
</plugin>

While looking into another issue I noticed that the init message prints "null" instead of the actual message.

May 21, 2018 10:14:15 AM org.apache.tomcat.vault.security.vault.PicketBoxSecurityVault init
INFO: null

That is due to the StringManager not finding the message it needs. This is easily fixed by adjusting the package name that the StringManager uses:

--- a/src/main/java/org/apache/tomcat/vault/security/vault/PicketBoxSecurityVault.java
+++ b/src/main/java/org/apache/tomcat/vault/security/vault/PicketBoxSecurityVault.java
@@ -82,7 +82,7 @@ import java.util.StringTokenizer;
  * @since Aug 12, 2011
  */
 public class PicketBoxSecurityVault implements SecurityVault {
-    private static final StringManager sm = StringManager.getManager("org.apache.tomcat.vault.security.vault.PicketBoxSecurityVault");
+    private static final StringManager sm = StringManager.getManager("org.apache.tomcat.vault.security.vault");
     private static final Log log = LogFactory.getLog(PicketBoxSecurityVault.class);
     private static final StringManager msm = StringManager.getManager("org.apache.tomcat.vault.security.resources");

The latest version of apache commons-cli is 1.5.0, so we should update tomcat-vault's pom to that version.

$SUBJECT

Even though this is a small project they would be very helpful when developing new features to make sure we're not breaking things.

This looks like a great approach to setting up a vault for Tomcat. I've got your solution working, with local customization, but am concerned about a warning I'm seeing.

When I initialize the vault with keytool, i'm getting the follow:

Warning:
The JCEKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore vault_data/vault.keystore -destkeystore vault_data/vault.keystore -deststoretype pkcs12".

The vault.sh tool (next step in initializing) works fine though.

If I do what the warning suggests and switch to pkcs12, then the vault.sh tool gives this error:

Exception encountered: java.lang.RuntimeException: Unable to get keystore ([vault_data/vault.keystore])

(yes, i've made some modifications to how the vault location works, but have it working fine with jceks)

Any way to get rid of that warning? Also, is the keystore configuration as you implemented it FIPS compliant?