We recently had a bug report in the Vault support of FinalBuilder. The bug was that if SSL encrypted client to server communication was enabled, the Vault actions in FinalBuilder would fail. When I re-familiarised myself with the Vault command line options, I found the following:
-ssl
Enables SSL for server connection
Now, this is not the hardest of command line parameters to pass to the vault client, and indeed, the FinalBuilder code was doing exactly that... so, further investigation as to why the FB action was failing had to be done.
So, after updating our vault client and server to the latest version, the next thing was to enable SSL. This quickly turned into a larger task than I was hoping for - SSL requires a certificate in IIS; you have to generate a certificate request file, sign up to a certificate provider (instantSSL, Comodo, Thawte, etc, etc), get a trial certificate, and then install the certificate in IIS. One of the problems with this series of steps is that the certificate provider has to verify your identity (via faxing your details to them or some other low-tech stuff....) and this can take some time, time that we didn't have to solve this seemingly simple problem.
So, getting the the point, you can self-sign your certificate files. Of course, if this was for an ecommerce website for customers, it wouldn't be a great idea to have a non-trustworthy certificate provider... but for a development box, it's perfect.
Here's the link to the tutorial I used to get IIS working in SSL including creating a self signed SSL certificate:
http://www.dylanbeattie.net/docs/openssl_iis_ssl_howto.html
This turned out to be exactly what was required. We got SSL working, Vault was happy, and the problem was diagnosed and fixed. It turned out that the vault client was outputting ssl information to stdout before the xml tag, and that caused FinalBuilder to fail parsing the xml output, and hence the action was reported as failed (even though it probably succeeded).