Oauth2 bad_cert invalid_key_usage

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 ‘forum.elixirforum.com’ with your server’s hostname):

openssl s_client -connect forum.elixirforum.com:443 -showcerts

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.

Elixir version:     1.6.5
OTP version:        20
ERTS version:       9.1
Compiled for:       x86_64-apple-darwin15.6.0

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.

openssl s_client -connect your_server:443 -verify 3 -CAfile cacerts.pem

replace your_server with whatever your server name is. If the chain shows the same cert twice then its 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!