Cannot manage to get MTLS working with elixir

Questions / Help
, , ,
1

I am able to do MTLS connections to a given service using curl and httpie. That works fine.

An example of a working httpie command http post --cert=./cert.pem --cert-key=./cert.key <url>
The key is passphrase protected, but I have tried using an unprotected one in Req/elixir and no dice.

But as soon as I try to replicate that in elixir using Req I get errors from the service saying that there is no client certificate being used.

I have tried using certfile and keyfile and password but nothing seems to work and there is remarkably no documentation about this.

I could swear I had it working before but I cannot for the life of me get it working now.

I appreciate this will be reasonably tricky to identify as I cannot obviously share the keys. But I would love any help, I am going slowly insane.

1 Like
2

What you’re probably missing is CAs for the sever you’re connecting to. curl has a bit of magic to look in your system for CA store files with all the typical globally trusted root CAs. However, you have to explicitly give that to erlang. Adding cacerts: :public_key.cacerts_get() option would probably fix it for you so the server chain can be validated.

When in doubt, you can also set log_level: :debug in the SSL options to get more hints about where it is failing

3

Problem is, its not failing the SSL its just not sending the client certificates (or so it seems)

Where do I set the debug level? Currently I am trying to use Req but I have tried several.

4

Req uses Finch as its default adapter and Finch uses Mint (which allows all of the Erlang :gen_tcp and :ssl socket options to be passed).

So looking at the Req run_finch/1 documentation we see :connect_options which contains :transport_opts which defers to Mint for the details.

The mutual TLS options for Mint was answered here as not all options are covered in the Mint documentation, only the ones they alter the semantics of.

So your code will be something like:

Req.post!(url, json: payload, connect_options: [transport_opts: [cacerts: :public_key.cacerts_get(), certfile: ~c"client.pem", password: secret_charlist]])

Note that Erlang needs charlists passed.

3 Likes
5

Great answer, I think there was something to do with a TLS1.3 → 1.2 bug in erlang itself. That might be partly to blame for this. I have to deprio this right now but Ill keep it in mind.