The problem is that the same app with the same deps versions at the same time worked fine on my dev computer (almost the same environment as on the server) and on a collegue’s Mac so it should have been something server specific (the app is compiled from source on deploy).
What I did:
updated Erlang, Elixir and all other packages
bumped hackney and its deps
bumped httpoison and its deps
removed Erlang and Elixir, cleaned up, rebooted and installed them again
Something above might have fixed the situation though weird as it sounds it started working a little after I made the last change.
From what I could google, this could have been a problem with Erlang’s certificate but I’m not sure. If it was a temporary problem with the remote API server it should have thrown errors in every environment, otherwise it would make the most sense to me.
What I want now is to understand what happened to somehow avoid it in the future, so I am asking for collective mind’s help
Could someone please explain what exactly does the {bad_cert,unable_to_match_altnames} error mean?
If anyone had a similar problem and can share some experience that would also be helpful.
That really sounds like either a bad certificate or a MITM attack… The altnames are the valid hostnames that the certificate is for, I do not ‘think’ that’d be related to older Erlang’s SSL deprecations, that really seems like either a bad cert or MITM… o.O
Depends on your internet provider, and their provider, and so on. ^.^
It really might have just been a temporary bad certificate though, especially if it is working now. This is definitely why it is important to check the certificates for validity.
If you get different results depending on whether your client resides on DO or on your own dev machine, and you want to check if you’re getting a different cert depending on where you are, try running the following OpenSSL command:
You can compare the subjects and issuers, and perhaps a few of the hex bytes of the actual certificates. Or you can copy & paste a certificate from the output (including the BEGIN and END markers) into this command:
openssl x509 -text -noout
The first certificate output by the s_client command should be the server cert, so you should see the hostname(s) in the Subject or the Subject Alternative Name fields.
If the certificate seems legit, but HTTPoison (Hackney) chokes on it, I’d love to have a look at it. I don’t have any problems connecting to api.telegram.org from here, but you might hit a different Telegram server or CDN edge node depending on geographical location.
That actually sounds more likely than a MitM attempt: some transient DNS issues that caused connections to hit a wrong server, which was also serving HTTPS but for a different domain. In that case the SSL handshake issues were just SSL doing its job: verifying that we reached the intended server.
Didn’t think about looking into certs then (mostly because I was confused by the unable_to_match_altnames message), will do if it happens the next time.
When I think about it it actually makes sense that I got different Telegram’s API’s from here and DO server (both are in Germany, but still) - because of a MITM attack as suggested by @OvermindDL1 or because of a legit temporary problem. That would explain a lot.
I don’t know if it helps but I’ve just checked my own bot and it seems it had a lot :nxdomain errors from 13:06:03.361 to 16:22:27.759 utc.
It does help, thank you, @idi527 the time frame is very similar.
Out bot runs 24/7 for about a year and does a lot (so we’d notice if something like that happened before), so that would be the first such problem. Guess I’ll be better prepared next time it happens
Marking the issue as resolved since it’s as resolved as it gets. Many thanks for all your answers, the explanation makes sense and I have my peace of mind now