Mix: "Certificate expired"

, ,

Hey guys,

Today I did a mix deps.get after installing a new dependency in my project. Result was and still is:

13:00:09.218 [info]  ['TLS', 32, 'client', 58, 32, 73, 110, 32, 115, 116, 97, 116, 101, 32, 'certify', 32, 'at ssl_handshake.erl:1354 generated CLIENT ALERT: Fatal - Certificate Expired', 10]
# Same as above, repeated many times.
Failed to fetch record for 'hexpm/phoenix_swoosh' from registry (using cache)
Failed to check for new Hex version
{:failed_connect, [{:to_address, {'repo.hex.pm', 443}}, {:inet, [:inet], {:tls_alert, 'certificate expired'}}]}
{:failed_connect, [{:to_address, {'repo.hex.pm', 443}}, {:inet, [:inet], {:tls_alert, 'certificate expired'}}]}
Failed to fetch record for 'hexpm/combine' from registry (using cache)
# The above is repeated many times for all dependencies.

This is on Linux with asdf:

$ asdf list erlang
$ asdf list elixir

I also removed the dependency and re-ran. Same result.

Curiously enough, even after doing mix deps.clean --all on a Windows 10 PC for one of my hobby projects mix deps.get is running with zero issues. No asdf on Windows.

Can somebody enlighten me as to what I can do?

1 Like

Right now I’m seeing a certificate that was issued 10 minutes ago:

        Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign CloudSSL CA - SHA256 - G3
            Not Before: Nov 15 11:18:20 2018 GMT
            Not After : Sep  7 16:10:08 2019 GMT
        Subject: C=US, ST=California, L=San Francisco, O=Fastly, Inc., CN=f2.shared.global.fastly.net

Can you try again?

1 Like

Just did. Same result. Did you try mix deps.clean --all and mix deps.get in one of your projects to make sure only I have this problem?

I didn’t try Mix, just had a look at the certificate and noticed the timestamp. It suggests Fastly just replaced the cert. It may take a while to propagate, though.

Is it possible your system clock is incorrect? Can you check that it is in within the window of the Validity that @voltone posted above?


Yep, that was it. For the first time in years my VM was having the wrong time. Fiddled a bit with Manjaro’s settings and found out that “Automatically adjust date and time via NTP” was turned off. Turned it on, clicked “Apply” and it synced. mix deps.get ran successfully afterwards.


1 Like

Would have been nice if Fastly’s CA would backdate certificates by a few minutes (like I do here https://hexdocs.pm/x509/X509.Certificate.Validity.html#days_from_now/2) or Fastly would wait a few minutes before pushing it into production…

1 Like

Good idea, I will suggest to them.

1 Like