I’m adding oauth2 authentication to an internal company Phoenix web app. Did initial testing with github and google and was at least able to get the basics working really quickly. But now that I’m using our company’s oauth server I ran into an immediate issue. I’m testing locally so I have a client key/secret associated with a localhost callback. Our oauth team provided me with the client key and secret. I implemented an OAuth2.Strategy. I redirect to the authorize URL, enter my credentials and I get my callback with a code at “http://localhost:4000/auth/callback”. I then attempt to do a token exchange and the the code bombs out in the OAuth2.Client.get_token!/4 function with a {:tls_alert, ‘handshake failure’}.
I’ll dig into this tomorrow but I was curious whether I could get hackney (which Oauth2 library is using) to output the exact request it does.
Looks like Hackney is unable to establish a TLS connection with the OAuth server’s token endpoint. The invalid_key_usage message suggests there is a problem with the server’s certificate.
You can try to connect to the server with OpenSSL to see if the connection succeeds (replace ‘elixirforum.com’ with your server’s hostname):
If OpenSSL also fails to connect, it might show an error message that might help the server’s administrator resolve the issue. You can also copy the PEM encoded certificates (one at a time, including the ‘BEGIN’ and ‘END’ lines) into the following command:
openssl x509 -text -noout
For the server’s end-certificate you should typically see the following key usages:
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
I’m developing on a Mac and it has an older version of openssl (OpenSSL 0.9.8zh) that gets an error. If I use the more modern version I install with homebrew then it succeeds. Is hackney (or ssl_verify_fun or some other Erlang library) trying to use the openssl installed on the system?
Erlang/OTP only uses OpenSSL for low-level crypto functions, not for the wire protocol or certificate handling. Your problem seems to be related to the latter, so I don’t think the OpenSSL version in use is the problem.
No idea. I’m hoping Oauth server guys will give me a clue. The complete error message from down in Erlang is:
“TLS client : In state certify at ssl_handshake.erl:1626 generated CLIENT ALERT: Fatal - Handshake Failure - {bad_cert,invalid_key_usage}”. Here’s the runtime_info on this box.
Looking through the :public_key source code, the only likely place that returns invalid_key_usage is when one of the CA certificates in the chain does not have the keyCertSign key usage. OpenSSL by default does not verify the trust chain, so I guess that’s why it didn’t show you any errors.
Try adding -CAfile cacerts.pem -verify 3 to the s_client command (update the filename to point to your CA trust store).
Still haven’t figured this out. Its something I’m doing wrong in my code I’d imagine. Using an Oauth playground just now with Oauth server guy on the phone worked fine.
It really doesn’t sound like an issue in your code, though it might just be possible to work around TLS interop issues with the specific server you’re trying to talk to, with the right certificate verification hooks. But for that we need to find the root cause. The server isn’t reachable from the public internet by any chance, is it?
@fmcgeough@voltone Anyone find a resolution to this? I’ve been facing the same issue–I get a valid response if I curl the same arguments that hackney does to the server (I’m using auth0), but hackney just gives me the same handshake failure error every time.I even tried reinstalling erlang and updating hackney, but no dice.
the issue I was dealing with was due to the strictness of the Erlang TLS implementation. The OAuth server was returning its own certificate twice. Other implementations ignore this. The Erlang one did not. Try the openssl command line tool to check on your cert chain. It might be the same issue.
I actually had checked openssl previously, but I didn’t pay enough attention to the actual certificate I was getting until you mentioned the implementation strictness. It turns out in my case that the new server was configured to return a self-signed cert by default, so I just need to pass in server_name_indication to hackney to get the correct certificate. Thanks for the assist!
