fmcgeough

Oauth2 bad_cert invalid_key_usage

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.

10 comments

/phoenix #debugging #oauth2

0 2274 10

2018-07-18 23:41:19 UTC

First Post!

voltone

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

Post #1

Most Liked

fmcgeough

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.

Post #9

voltone

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?

Post #7

Last Post!

sredev

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!

Post #10