No supported Vault instance found at the this URL
danielhass opened this issue · comments
The problem
Error trying to connect to Vault 0.10.0 Cluster.
Environment
- Cryptr version (or git revision) that exhibits the issue: 0.2.0
- Desktop OS/version used to run Cryptr: Windows 10 & Debian 9
- Vault version: 0.10.0
Details
I tried to connect to a Vault HA Cluster via Cryptr. After entering the URL a error notification (toast like message) pops up that says: "No supported Vault instance found at the this URL".
As Connection endpoint I'm using the Vault Active Node Address: https://X.X.X.X:8200
Steps to Reproduce
- Start Cryptr
- Enter connection details
- Error shows up
@danielhass I've confirmed that Cryptr still functions with 0.10.0 release of Vault. However, support for the newly released versioned k/v backend is not yet supported in Cryptr.
In regard to your issue, I have been unable to reproduce this as of yet. Can you confirm that you can connect to a dev server running on your local machine?
@jcrowthe thanks for your reply! I was able to connect against a local vault instance in dev mode version 0.10.0. But there I wasn't able to create any secrets (error message: An error occurred while updating this secret. Check permissions? ). Afterwards I started a local dev vault server v0.9.6 and there everything works fine...
@danielhass Yea, with a local dev server, the default secret backend is mounted as a k/v version 2 backend instead of a generic backend which has been discontinued. So it makes sense that you were unable to push secrets.
Right now, Cryptr doesn't yet support versioned secrets, nor the new k/v secret backend which has replaced the generic backend.
Were you able to find why you were experiencing the connection problem initially? My assumption is that there was a small race condition or network connection hiccup during that initial check. If you simply select another URL from the dropdown, then select your original URL again, does the error appear again?
@jcrowthe yes the error keeps showing up, even after I selected a different URL.
Is it possible to start Cryptr in some kind of a debug modus? A little more verbose output on the cli for instance?
@danielhass Yes, two ways to do so. If you have the code checked out, you can run npm run dev, or if you are using a binary release you can run CRYPTR_ENV=development open /Applications/Cryptr.app on a mac. These will open the Chrome Developer Tools allowing you full debug ability.
@jcrowthe sorry that it took me so long to come back to this one. With the development environment set I was able to find the cause of the error. It was our internally signed ssl cert. Cryptr/Electron doesn't seem to use the OS cert store to gain trust with CAs. Is there a way to add custom CAs?
I was able to see all the k/v version 1 backends. Are you planning to support version 2? Even without full support for versions, maybe only displaying the most recent one (like the offical vault ui does)?
I got same issue with self-signed CA. Please add posibility to add custom ca certs.
@danielhass @xelite
My tests with self-signed certificates indicate that Cryptr properly uses the OS cert store. Can you verify your certs are fully trusted by the OS? A good litmus test for this is to hit the vault URL in Google Chrome. If Chrome doesn't complain, nor should Cryptr.
After pondering over the feature request to allow untrusted self-signed certificates in Cryptr, I've decided that the answer should be 'no', with the following reasoning:
- LetsEncrypt allows creation of fully trusted TLS certs, free of charge. While this is not a recommendation to make vault servers publicly accessible, LetsEncrypt does support wildcard certs, which many companies will request and use to securely host internal services such as intranets.
- Companies with internal self-signed CA's typically install the CA root cert on all employee machines as a trusted CA. Since the OS trusts it, Cryptr also trusts it.
- Self-signed certificates otherwise are typically only used for dev/testing, or in home use cases. In local dev scenarios, Cryptr accepts the non-TLS URL
http://127.0.0.1:<port>, so it should not be an issue. In home use cases, where vault is hosted somewhere on your local network, it is recommended to use LetsEncrypt as in the first scenario, or alternatively to generate a self-signed TLS cert and add it into your OS's local trust store.
The summary is that TLS provides both authentication and authorization of a particular common name or SAN found in the cert. By allowing Cryptr to talk to servers hosted by untrusted TLS certs, we break either one or both of these tenets of TLS. Since the purpose of Cryptr is to provide easy access to highly secured information, we must maintain a high bar regarding security, and reject the request to lower that bar.
@danielhass As a last note regarding v2 secret backends, I spent last week fleshing out that feature. You should see something in Q1 regarding support for versioned secrets.
@jcrowthe thanks for your detailed answer! My use case exactly falls into case 2 but when I tested this a while ago it doesn't seem to work for me. I totally agree with you that you need to keep the bar high due to the critical role of TLS during secret access via Cryptr.
After new years eve I will dive into testing once more and see if the OS cert store is used properly in our setup. I will test this on Windows and Debian Linux. I will post feedback here as soon as the testing is done.
Regarding v2 backends: great to hear that you're planning to support this! I'm happy to see that Cryptr is still under development as it is my favorite Vault UI for quick access to secrets, mainly because of the "fuzzy search" feature.
@jcrowthe I can confirm that Cryptr is using ths OS cert store correctly on Windows 10 and 7. The issue still persists on my machine but I tested the setup on serveral machines form co-workers and there it's working out of the box. So there seems to something wrong with my machine only.
Under Debian 9 Chromium and therefore Electron is not using the OS cert store under /usr/local/share/ca-certificates/. I had to import the internal CA via the chromium installation on that machine (Settings->Certificates->Authorities->Import). Afterwards also Cryptr stopped complaining about insecure requests.
I think you can close this one know. Thanks for your support!
@danielhass Thanks for putting in the time to test! Good find with Debian as well. I'll go ahead and close this.