Cert authentication login problem

[aaron64]

Describe the bug
A clear and concise description of what the bug is.
When setting up certificate authentication on vault in an enabled path, the login command errors and logs a PUT command, when everywhere else I have seen it is listed as a POST.

Here is a log form the console:

: vault login -method=cert -client-cert=cert.pem -client-key=key.pem name=concourse     
Error authenticating: Error making API request.

URL: PUT https://{URL}/v1/auth/cert/login
Code: 400. Errors:

* client certificate must be supplied

To Reproduce
Steps to reproduce the behavior:

1. create a certificate and private key (cert.pem, key.pem)
2. enable a new path (in my case /concourse)
3. create a new policy
4. attempt to log into policy with cert authentication

Expected behavior
A successful login, definitely not a PUT header

Environment:

• Vault Server Version (retrieve with vault status): 0.9.3
• Vault CLI Version (retrieve with vault version): 0.10.4
• Server Operating System/Architecture: Mac OSx

Vault server configuration file(s):

path "concourse/*" {
	capabilities = ["create", "read", "update", "delete", "list"]
}

Additional context
Add any other context about the problem here.

The tutorial at: https://www.vaultproject.io/docs/auth/cert.html is exactly what I was following, the curl command for the same vault command has a POST header when vault has a PUT

[jefferai]

Vault makes no distinction between put and post. That has nothing to do with your problem.

Are you going through a proxy or load balancer?

[aaron64]

No proxy or load balancer.

These work:

curl -k \
--request PUT \
--cert cert.pem \
--key key.pem \
--data '{"name": "concourse"}' \
https://{URL}/v1/auth/cert/login

curl -k \
--request POST \
--cert cert.pem \
--key key.pem \
--data '{"name": "concourse"}' \
https://{URL}/v1/auth/cert/login

This does not:

vault login -method=cert -client-cert=cert.pem -client-key=key.pem name=concourse

[jefferai]

Does it work with the 0.9.3 CLI?

[senglin]

@jefferai I work with @aaron64

It seems that the CLI is handling errors different given different options. We finally found out that the encrypted key.pem file was the issue. However, what made us go on a merry-go-round is that the following commands return different error messages which do not relate to the actual issue.

1

$ vault login -address=https://<redacted>/ -tls-skip-verify -method=cert -client-cert=cert.pem -client-key=key.secure.pem name=concourse
Error authenticating: Put https://<redacted>/v1/auth/cert/login: x509: certificate is valid for 127.0.0.1, not <redacted>

Shouldn't the -tls-skip-verify option handle the above error?

2

$ VAULT_SKIP_VERIFY=1 vault login -address=https://<redacted>/ -tls-skip-verify -method=cert -client-cert=cert.pem -client-key=key.secure.pem name=concourse
Error authenticating: Error making API request.

URL: PUT https://<redacted>/v1/auth/cert/login
Code: 400. Errors:

* client certificate must be supplied

This seems to bypss the ssl certification verification (even though -tls-skip-verify was provided)
Even then, shouldn't Vault complain that it can't open encrypted key files?

3
What puzzles us is that when an unencrypted key is generated and used, the original command from 1 works:

$ vault login -address=https://<redacted>/ -tls-skip-verify -method=cert -client-cert=cert.pem -client-key=key.pem name=concourse
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                            Value
---                            -----
.
.
.

Environment:
Vault Server Version (retrieve with vault status): 0.9.3
Vault CLI Version (retrieve with vault version): 0.10.4

[jefferai]

1 works for me:

$ vault login root
Error authenticating: error looking up token: Get https://127.0.0.1:8200/v1/auth/token/lookup-self: x509: certificate signed by unknown authority

$ vault login -tls-skip-verify root
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                root
token_accessor       eb250ff3-cb1e-0cc8-3fdc-4a75fafc0662
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

For 2 and 3, note that Vault's CLI does not currently support reading encrypted PEM files. If you want to use them you'll have to log in via some other mechanism like curl at the moment.

[senglin]

@jefferai Yes, the CLI does not currently read encrypted PEM files. (Found that out eventually)

However, the point here is that when an encrypted PEM IS provided, the error messages are different and not indicative, depending on which flow you are using: environment variables vs argument options.

Note that your 2nd command line might return the same error (x509 error) if you were to provide an encrypted PEM file.

Hence example 1 vs example 2.

It might be a smoking gun for other issues.

If you think this should be a separate issue, let me know. The original issue has been solved.

Thank you.

[jefferai]

If you run command (1) with TLS_SKIP_VERIFY=true instead of 1, does it work? I think what's happening is the env var takes precedent over the flag, but the flags library doesn't know how to parse 1 as a bool.

[nagaraju02]

Does this still an issue when logging?

[identitymonk]

Hi,

Got the exact same issue. Client cert and Client key are PEM encoded and not encrypted. Still.

I ensured that my TLS protected API endpoint certificate can be resolved thanks to export VAULT_CACERT=/home/ca-bundle.pem but this does not change anything.

The error message s far from being exhaustive as the client cert is effectively correctly provided through -client-cert=client.pem.

Any idea for debugging is appreciated.

Jeff

[catsby]

Hey @identitymonk can you copy and paste some of your attempts, including the command(s) and error(s) you're getting? Please be sure to obfuscate any sensitive data, but otherwise seeing the full command and error could help here. Thanks!

[catsby]

Hello - we haven't heard back in some time, so we're going to close this issue for now. If you have more information please let us know by opening a new issue, and optionally referencing this one. Thanks!

[mikearruda]

I had the same issue and resolved by switching from an ALB to NLB in AWS.