socketify.py: HTTPS not working: RuntimeError: Failed to create connection

Describe the bug

Unable to run examples/https.py neither with certificate bundled with socketify nor with created by openssl command supplied within https.py.

To Reproduce

Setup env with docker run --rm -it python:3.9.13-slim-bullseye bash -l :

apt-get update
apt install libuv1 zlib1g
pip install socketify

add https.py script:

cat <<-EOF> https.py
from socketify import App, AppOptions

app = App(
    AppOptions(
        key_file_name="/usr/local/lib/python3.9/site-packages/socketify/uWebSockets/misc/key.pem",
        cert_file_name="/usr/local/lib/python3.9/site-packages/socketify/uWebSockets/misc/cert.pem",
        passphrase="1234",
        dh_params_file_name=None,
        ca_file_name=None,
        ssl_ciphers=None,
    )
)
app.get("/", lambda res, req: res.end("Hello World socketify from Python!"))
app.listen(
    3000,
    lambda config: print("Listening on port https://localhost:%d now\n" % config.port),
)
app.run()
EOF

run python ./https.py

Traceback (most recent call last):
  File "//./https.py", line 3, in <module>
    app = App(
  File "/usr/local/lib/python3.9/site-packages/socketify/socketify.py", line 2539, in __init__
    raise RuntimeError("Failed to create connection")
RuntimeError: Failed to create connection

Expected behavior

examples/https.py should work.

Extra context

# uname -a
Linux 875b757ff0e5 5.15.0-48-generic #54-Ubuntu SMP Fri Aug 26 13:26:29 UTC 2022 x86_64 GNU/Linux

Reproducible with venv and without.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 15 (9 by maintainers)

Most upvoted comments

Always welcome! I can imagine how such a great project can be excited and with more popularity many more issues will be reported. In the meantime - don’t forget to have enough rest! 😅

Thanks a mil @cirospaciari ! bow I confirm - the issue with AppOptions defaults, ability to omit them and to specify certs outside of the socketify package path is fixed according to my quick tests. rocket

I will need some time or help to investigate this because I basically working 12h to 16h per day, but its my priority for sure!

No worries at all - I believe this is a great and well-anticipated project that solves one problem well and across a lot of platforms with help of well designed low-level library us/uws. More people will come with help as time goes, especially given the traction your work found in bun framework. Very well done Ciro! And even though I can’t be useful on a lower level, I’ll do my best to report and test any of mine findings.

Thanks ❤️ I will do my best always, comment like this give me more motivation to do even better ❤️

Thanks a mil @cirospaciari ! 🙇 I confirm - the issue with AppOptions defaults, ability to omit them and to specify certs outside of the socketify package path is fixed according to my quick tests. 🚀

I will need some time or help to investigate this because I basically working 12h to 16h per day, but its my priority for sure!

No worries at all - I believe this is a great and well-anticipated project that solves one problem well and across a lot of platforms with help of well designed low-level library us/uws. More people will come with help as time goes, especially given the traction your work found in bun framework. Very well done Ciro! And even though I can’t be useful on a lower level, I’ll do my best to report and test any of mine findings.

🧐 I think we can keep this issue I will investigate this dependencies on media-type and also the dh_params_file_name, maybe is some compiler option or issue in uWebSockets/uSockets, I will change the title to investigate the behavior and check All options, o also need to add unit tests for all this cases

I also tried using dh_params_file_name option with a certificate I intend to use (all works with Nginx), but getting the same error:

  File "/opt/venv/lib/python3.9/site-packages/socketify/socketify.py", line 2539, in __init__
    raise RuntimeError("Failed to create connection")

If I use key and cert with dh_params_file_name=None server starts and replying fine.

Should I create another issue to fix dh_params_file_name option?

@bob-rove Thanks for reporting it! I will take a look at it soon.