thepeoplesbourgeois
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
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
voltone
You are not generating a wildcard certificate by any chance, are you? Wildcard certificates can result in
:hostname_check_failederrors with Erlang:sslbased clients, depending on the ssl options set by the client…thepeoplesbourgeois
Unfortunately, that isn’t the issue
I used mix phx.gen.certwithout any arguments to generate the original cert, which should use a default value oflocalhost.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 withmix 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 -_-
voltone
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…
thepeoplesbourgeois
My mix.lock file has
:oauth2@2.0.0using:hackney@1.16.0for its authentication requests. No overwrites amok, as far as I can tellvoltone
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…
thepeoplesbourgeois
THANK YOU!!
I’m finally unstuck