thepeoplesbourgeois
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
Marked As Solved
voltone
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…
Also Liked
thepeoplesbourgeois
thepeoplesbourgeois
Unfortunately, that isn’t the issue
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 -_-
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








