Bogus certificate expired failure during mix deps.get

Questions / Help
,
1

I get a bogus certificate expired error when I run mix deps.get using an installation from macports. Similar circumstances to Unable to run mix local.hex and mix local.rebar, but a different error message.

Here’s what I’ve got:

$ mix --version
Erlang/OTP 27 [erts-15.0] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1]

Mix 1.16.2 (compiled with Erlang/OTP 26)

$ openssl version
OpenSSL 3.1.6 4 Jun 2024 (Library: OpenSSL 3.1.6 4 Jun 2024)

Here’s the error:

$ mix deps.get --only prod
** (Mix) httpc request failed with: {:failed_connect, [{:to_address, {~c"builds.hex.pm", 443}}, {:inet, [:inet], {:tls_alert, {:certificate_expired, ~c"TLS client: In state wait_cert_cr at ssl_handshake.erl:2158 generated CLIENT ALERT: Fatal - Certificate Expired\n"}}}]}

Could not install Hex because Mix could not download metadata at https://builds.hex.pm/installs/hex-1.x.csv.

This seems like the root cert expiration problem from a few years ago discussed here but am not sure why I’d be running into it now. The macOS side is very old but has no trouble otherwise with hex.pm’s cert or others from LetsEncrypt.

I can get httpc to cooperate if I specify an alternate cacertfile:

iex(1)> :inets.start
:ok
iex(2)> :ssl.start
:ok
iex(3)> :httpc.request(:get, {'https://builds.hex.pm/', []}, [
...(3)>   ssl: [
...(3)>     cacertfile: '/opt/local/etc/openssl/cert.pem',
...(3)>   ]
...(3)> ], [])
{:ok,
 {{~c"HTTP/1.1", 200, ~c"OK"},
  [
...

If I install hex through github and try to accomplish the same using cacerts_path, no luck:

$ mix archive.install github hexpm/hex branch latest
$ mix hex.config cacerts_path /opt/local/etc/openssl/cert.pem
$ mix deps.get --only prod
...
** (Mix) httpc request failed with: {:failed_connect, [{:to_address, {~c"builds.hex.pm", 443}}, {:inet, [:inet], {:tls_alert, {:certificate_expired, ~c"TLS client: In state wait_cert_cr at ssl_handshake.erl:2158 generated CLIENT ALERT: Fatal - Certificate Expired\n"}}}]}

Could not install Rebar because Mix could not download metadata at https://builds.hex.pm/installs/rebar3-1.x.csv.

No luck with unsafe_https either.

Past discussions touched on things like actually expired certs and skewed local clocks, but none of that seems applicable.

2

Interestingly enough, there was another thread very recently: Unable to run mix local.hex and mix local.rebar

I am thinking maybe it’s an OpenSSL 1.1.1 vs 3.0.x issue. Have you tried installing Erlang with asdf / mise and specify an OpenSSL directory?

3

Check your system time, maybe it is incorrectly set, that will influence the verification of certificate.

4

Hello, thanks for the replies. I’ve re-confirmed that system time is correct, and unfortunately did not having success building Erlang with OpenSSL 1.1 through asdf. I also don’t have any weird proxy or VPN situations.

I did find this OTP issue about default certificates on Darwin which I plan to explore further.

For Hex I opened an issue asking about cacerts_path.

I think i’ts a two-part problem. Something is not right with the system cert chain that Erlang looks at, and then the workaround that Hex provides in the form of the cacerts_path config option also doesn’t save the day. Hopefully a solution will eventually turn up in one or both of those GitHub issues.