OAuth /callback failure on bad self-signed cert.... in dev

Hey all,

I’m building an app in Phoenix and have hit a snag with implementing OAuth signup/login. To follow OAuth 2 security requirements, I need to go through https, which I can do in dev by generating a self-signed certificate and setting its pathname in config/dev.exs. The OAuth provider I’m connecting accepts the request and callback URLs and hands off the login credential to my app at https://<ngrok-generated-domain>/auth/:provider/callback but when my client arrives there, the app sends back a failure response with status code 400.

The interesting thing is that the failure is coming from erlang code, with this message appearing in the log:

[info] TLS :client: In state :wait_cert_cr at ssl_handshake.erl:1952 generated CLIENT ALERT: Fatal - Handshake Failure
 - {:bad_cert, :hostname_check_failed}

This happens even when I specify the hostname allowed in mix phx.gen.cert to be the domain that’s generated when I start running ngrok. I’ve looked for any kind of similar problem in StackOverflow and general Google results, and had found one post somewhere for an issue an Erlang developer encountered, where the solution was to set some sort of generic flag for the VM to ignore certain CA certificate issues (or some severity level of certificate issues? I was fuzzy on the overall details of the flag, and I can’t find the page again now).

This error just started occurring recently – on a prior version of Erlang/OTP, I made it through to the success path for the handshake. I’m working around this issue by reverting back to that version of the OTP, but I was wondering if anybody else had encountered this issue, and could help me to resolve it on later minor/patch versions of OTP.

Thank you in advance!
The People’s Bourgeois

1 Like

You are not generating a wildcard certificate by any chance, are you? Wildcard certificates can result in :hostname_check_failed errors with Erlang :ssl based clients, depending on the ssl options set by the client…

Unfortunately, that isn’t the issue :confused: I used mix phx.gen.cert without any arguments to generate the original cert, which should use a default value of localhost.

I thought the problem could be coming from the fact that the OAuth validation was taking me back to an ngrok address, so I tried regenerating the certificate with mix phx.gen.cert localhost <generated-hash-value>.ngrok.com, but that still produced the same error. I’m about to delete the cert files and try again with the ngrok domain as the first argument to phx.gen.cert, but I’m unsure of how much more successful that’ll go.

WHOOPS, looks like I should’ve been paying some attention to what ngrok is using for its CA certificate, because yup, a wildcard cert is the exact kind of cert they are indeed using for their subdomains, yes. 100%

I would post a screenshot of the cert, but I’m apparently too new to do so -_-

1 Like

Ok, so what HTTPS client are you (or the OAuth client library) using? If it’s Hackney you’re going to have to make sure you have at least 0.16.0. Things might get a bit more complicated if someone is trying to override ssl settings…

My mix.lock file has :oauth2@2.0.0 using :hackney@1.16.0 for its authentication requests. No overwrites amok, as far as I can tell :sweat_smile:

Ah, yeah, I meant 1.16.0.

It seems that the fix that was included in 1.16.0 doesn’t always work: see benoitc/hackney#664. If that’s your issue, upgrade to 1.17.0…

THANK YOU!!

I’m finally unstuck :weary:

2 Likes