vaultenv fails with HandshakeFailed error rejecting the certificate by NameMismatch

[sezaru]

Hello,

When vaultenv tries to connect to my vault server using TLS it fails with the following message:

vaultenv --addr https://127.0.0.1:8200 --token s.11iJ3aza8NC0UL1TWN2koAW3 --secrets-file /tutorial.secrets /script.sh
[ERROR] ServerUnreachable error: HttpExceptionRequest Request {
  host                 = "127.0.0.1"
  port                 = 8200
  secure               = True
  requestHeaders       = [("x-vault-token","**removed**")]
  path                 = "/v1/sys/mounts"
  queryString          = ""
  method               = "GET"
  proxy                = Nothing
  rawBody              = False
  redirectCount        = 10
  responseTimeout      = ResponseTimeoutDefault
  requestVersion       = HTTP/1.1
}
 (InternalException (HandshakeFailed (Error_Protocol ("certificate rejected: [NameMismatch \"127.0.0.1\"]",True,CertificateUnknown))))

My vault uses a certificate and key that was signed by my private CA. I will attach them here in the hope it helps resolve the issue (don't worry, these certs, keys, token, etc are all temporary, is not the ones in production).

certificates_and_keys.zip

Bellow is the output vault gives me in its log (journalctl -u vault.service):

Jan 31 04:05:01 tip-off vault[744]: 2021-01-31T04:05:01.213Z [INFO]  http: TLS handshake error from 127.0.0.1:46152: remote error: tls: unknown certificate

Also, using vault cli works without issue.

Any idea of what this could be?

EDIT:

Looking around to some solution I found this GitHub issue kubernetes-client/haskell#64 which has the same problem.

Looks like that the default implementation of TLS from Haskell doesn't support validating certificates based on IP addresses. There is some workaround discussed there, but since Haskell is very new to me, I'm not sure how to port these workarounds to vaultenv, to be honest.

[ruuda]

Indeed, this is a limitation of the Haskell TLS client library that Vaultenv uses. It looks like there are two solutions in kubernetes-client/haskell#64:

• Depend on a custom version of hs-certificate where Support server name validation using IP Address haskell-tls/hs-certificate#113 is applied, but looking at that pull request, it is not ready for production use.
• Depend on http-client-openssl instead of http-client-tls. I think that would be the best way to go. We use http-client-openssl in a different (internal) project, and it requires some fiddling to configure, but I think it would be worth it; it would also sidestep the problem that versions built with integer-simple rather than integer-gmp are extremely slow. On the other hand, it would also make it even harder to build a static binary then.