Vault: When using sudo vault server, the server uses https, disregarding the config.

[kenden]

When vault is started with sudo, the vault client requests https. Even if
export VAULT_ADDR='http://127.0.0.1:8200' is given.

The error message is:
Error initializing Vault: Put https://127.0.0.1:8200/v1/sys/init: http: server gave HTTP response to HTTPS client

This is from https://github.com/hashicorp/vault/pull/1406

Versions:

$ cat /etc/issue.net
Ubuntu 14.04.4 LTS

$ vault --version
Vault v0.6.0

Repro steps

• create server with sudo vault server command

sudo vault server -dev
==> WARNING: Dev mode is enabled!

In this mode, Vault is completely in-memory and unsealed.
Vault is configured to only have a single unseal key. The root
token has already been authenticated with the CLI, so you can
immediately begin using the Vault CLI.

The only step you need to take is to set the following
environment variables:

    export VAULT_ADDR='http://127.0.0.1:8200'

The unseal key and root token are reproduced below in case you
want to seal/unseal the Vault or play with authentication.

Unseal Key: e40f65ac19fec9151500cc301732a9a9db4a29f4fee65a0b9a8fe99ff09a3d08
Root Token: 55391c01-63b7-6d32-ca52-9cdc647b9a3a

==> Vault server configuration:

                 Backend: inmem
              Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
               Log Level: info
                   Mlock: supported: true, enabled: false
                 Version: Vault v0.6.0

==> Vault server started! Log data will stream in below:

2016/08/10 16:20:36 [INFO] core: security barrier not initialized
2016/08/10 16:20:36 [INFO] core: security barrier initialized (shares: 1, threshold 1)
2016/08/10 16:20:36 [INFO] core: post-unseal setup starting
2016/08/10 16:20:36 [INFO] core: mounted backend of type generic at secret/
2016/08/10 16:20:36 [INFO] core: mounted backend of type cubbyhole at cubbyhole/
2016/08/10 16:20:36 [INFO] core: mounted backend of type system at sys/
2016/08/10 16:20:36 [INFO] core: post-unseal setup complete
2016/08/10 16:20:36 [INFO] core: root token generated
2016/08/10 16:20:36 [INFO] core: pre-seal teardown starting
2016/08/10 16:20:36 [INFO] rollback: starting rollback manager
2016/08/10 16:20:36 [INFO] rollback: stopping rollback manager
2016/08/10 16:20:36 [INFO] core: pre-seal teardown complete
2016/08/10 16:20:36 [INFO] core: vault is unsealed
2016/08/10 16:20:36 [INFO] core: post-unseal setup starting
2016/08/10 16:20:36 [INFO] core: mounted backend of type generic at secret/
2016/08/10 16:20:36 [INFO] core: mounted backend of type cubbyhole at cubbyhole/
2016/08/10 16:20:36 [INFO] core: mounted backend of type system at sys/
2016/08/10 16:20:36 [INFO] core: post-unseal setup complete
2016/08/10 16:20:36 [INFO] rollback: starting rollback manager

• connect with client (in different terminal)

$  export VAULT_ADDR=http://127.0.0.1:8200
$  vault init
Error initializing client: open /home/ubuntu/.vault-token: permission denied
$ sudo vault init
Error initializing Vault: Put https://127.0.0.1:8200/v1/sys/init: http: server gave HTTP response to HTTPS client

Workaround: delete file~/.vault-token and re-create server without sudo.

The opposite is also true (server not created with sudo, and client using sudo)

• create server without sudo

$ vault server -dev
==> WARNING: Dev mode is enabled!

In this mode, Vault is completely in-memory and unsealed.
Vault is configured to only have a single unseal key. The root
token has already been authenticated with the CLI, so you can
immediately begin using the Vault CLI.

The only step you need to take is to set the following
environment variables:

    export VAULT_ADDR='http://127.0.0.1:8200'

The unseal key and root token are reproduced below in case you
want to seal/unseal the Vault or play with authentication.

Unseal Key: 134d7d75e88e60449e34471b225745297895f859e9de113bebca4cd4084d2152
Root Token: 11c4f0f0-9604-edb5-d94c-ddae941746fb

==> Vault server configuration:

                 Backend: inmem
              Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
               Log Level: info
                   Mlock: supported: true, enabled: false
                 Version: Vault v0.6.0

==> Vault server started! Log data will stream in below:

2016/08/10 16:31:29 [INFO] core: security barrier not initialized
2016/08/10 16:31:29 [INFO] core: security barrier initialized (shares: 1, threshold 1)
2016/08/10 16:31:29 [INFO] core: post-unseal setup starting
2016/08/10 16:31:29 [INFO] core: mounted backend of type generic at secret/
2016/08/10 16:31:29 [INFO] core: mounted backend of type cubbyhole at cubbyhole/
2016/08/10 16:31:29 [INFO] core: mounted backend of type system at sys/
2016/08/10 16:31:29 [INFO] core: post-unseal setup complete
2016/08/10 16:31:29 [INFO] core: root token generated
2016/08/10 16:31:29 [INFO] core: pre-seal teardown starting
2016/08/10 16:31:29 [INFO] rollback: starting rollback manager
2016/08/10 16:31:29 [INFO] rollback: stopping rollback manager
2016/08/10 16:31:29 [INFO] core: pre-seal teardown complete
2016/08/10 16:31:29 [INFO] core: vault is unsealed
2016/08/10 16:31:29 [INFO] core: post-unseal setup starting
2016/08/10 16:31:29 [INFO] core: mounted backend of type generic at secret/
2016/08/10 16:31:29 [INFO] core: mounted backend of type cubbyhole at cubbyhole/
2016/08/10 16:31:29 [INFO] core: mounted backend of type system at sys/
2016/08/10 16:31:29 [INFO] core: post-unseal setup complete
2016/08/10 16:31:29 [INFO] rollback: starting rollback manager

• connect with client using sudo

$ export VAULT_ADDR=http://127.0.0.1:8200
$ sudo vault init
Error initializing Vault: Put https://127.0.0.1:8200/v1/sys/init: http: server gave HTTP response to HTTPS client

[jefferai]

This isn't a bug.

When you run something with sudo you have different permissions than when you run it normally, hence reading the token file. And your environment changes as well, hence the VAULT_ADDR issue.

There's nothing we can do about this.

[abdelhegazi]

I guess @mitchellh should make a clear hint about this ~/.vault-token at Vault/getting-started as I recall it happened with me first time I started vault in dev mode and didn't delele this file when restarting the server it will always give this error until you delete this file

Error writing data to secret/hello: Put https://127.0.0.1:8200/v1/secret/hello: http: server gave HTTP response to HTTPS client

I just googled it and found many were asking about same issue, following up vault getting started.

[philipmattingly]

it is more related to how sudo works, it is dropping the environment vars for your own protection.
you can override that behavior but understand your risk, by default it drops all but a very few env vars

$ man sudo 
-E, --preserve-env
                 Indicates to the security policy that the user wishes to preserve their existing environment variables.

$ export VAULT_ADDR=http://127.0.0.1:8200

$ sudo env |grep VAULT

$ sudo -E env |grep VAULT
VAULT_ADDR=http://127.0.0.1:8200

$ sudo -E vault status
vault status
Key             Value
---             -----
Seal Type       shamir
Sealed          false
Total Shares    1
Threshold       1
Version         0.9.3

with the -E the vault cmd actually sees your setting in the env.

[LuyuanBai]

I delete the ~/.vault-token, but not work. What's the root cause????

[bangle-98]

I also met that error and this is my solution

$ export VAULT_ADDR=http://127.0.0.1:8200

You must make sure in your shell session have that environment variable, you can check with

$ printenv

Because in some of terminal application, e.g iTerm in my case, when you use other tabs or duplicate current profile, the environment variable use the default one, so the VAULT_ADDR=http://127.0.0.1:8200 will not be configured.