According to curl the certificate has expired for at least https://api.amplitude.com/. There was an issue over the weekend with an expired root certificate from Comodo/Sectigo CA for https://openexchangerates.org as well. Perhaps these sites are using the same certificate chain. Have you checked their support site?

kip@Kips-iMac-Pro cldr_dates_times % curl "https://api.amplitude.com/"
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

There are high chance your guess is correct.
Though on my system curl, firefox, chrome all think there are no issues (both OSX and Ubuntu)

Thanks!

That interesting - my curl output is from MacOS.

curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport) LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2

Using https://www.sslshopper.com/ssl-checker.html#hostname=https://api.amplitude.com/ has the details and its indeed the Comodo and AdTrust certificates that have expired on May 30, 2020.

At this point I assume some clients are correctly validating the certificate chain and some are not.

image1144×634 62.6 KB

# OSX
curl --version                                                                                                    ┆master
curl 7.62.0 (x86_64-apple-darwin18.2.0) libcurl/7.62.0 SecureTransport zlib/1.2.11

Ubuntu 20.04 - no issues
Ubuntu 18.04 - no issues
Ubuntu 16.04 - server certificate verification failed

Also, tried providing fresh cacert.pem from curl - Extract CA Certs from Mozilla to httption/hackney - no changes in behavior, same error

It is unknown how good/actual sslshopper is.

Check my SSL Certificate | Is your SSL certificate valid and installed ? says there are no issues
Check SSL Certificate - GeoCerts says all good
etc

Totally fair and I’m definitely not a domain expert. I’m just going on the expiration dates on the certificates. So yes, I’m assuming they are correctly decoding the certificate metadata - and perhaps I shouldn’t.

This is where one usually invokes @voltone as the eventual source of truth

I ran the check on https://ssllabs.com which I think is well respected. It shows the intermediate and root certificates sent by the server as expired.

However, it also shows that there are three paths to establishing trust, one that includes the expired certificates and two that do not. As I understand it from some reading, the :ssl app is unable to resolve alternative trust paths and therefore will fail to validate the peer in more situations than other clients. (I know that is not precise, mostly because I only understand a very small amount of this topic).

It also suggests why you are seeing different outcomes from different clients.

This basically means the root of the issue is how :ssl operates and therefore it should affect a lot of people, not just me. Also, it’s surprising given this thing exists for a dozen (or two) years already

Well to be fair, the server’s certificate chain is invalid and should be fixed.

And in addition, :ssl definitely has limitations and is a salutary example of why rolling your own is something I imagine the Erlang developers would probably avoid if they got to do it over again

Actually Im being imprecise again. The function to verify peer is something a user provides - perhaps there is an enhanced validation function already out there in the cosmos.