SSLEOF error in Django via djangossl server using nginx and letsencrypt on https

I am running SSL on my domain via:

python3 runsslserver --certificate /etc/letsencrypt/live/domainname/cert.pem --key /etc/letsencrypt/live/domainname/privkey.pem domainname:443
Traceback (most recent call last):
  File "/usr/lib/python3.10/wsgiref/", line 138, in run
  File "/usr/local/lib/python3.10/dist-packages/django/core/servers/", line 173, in finish_response
  File "/usr/lib/python3.10/wsgiref/", line 184, in finish_response
  File "/usr/lib/python3.10/wsgiref/", line 293, in write
  File "/usr/lib/python3.10/wsgiref/", line 467, in _write
    result = self.stdout.write(data)
  File "/usr/lib/python3.10/", line 826, in write
  File "/usr/lib/python3.10/", line 1266, in sendall
    v = self.send(byte_view[count:])
  File "/usr/lib/python3.10/", line 1235, in send
    return self._sslobj.write(data)
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:2426)

EDIT: Was missing the last line.

This does not appear to be the complete traceback. I would expect there to be more of it.

Also, are you running this as root? Or are you running this as yourself?

(If you’re running this as root, this is really dangerous except in a well-controlled development environment.)

If you’re not running this as root, then you wouldn’t have permissions to the private key file.

If you’re running this behind nginx, why are you trying to use ssl at all in the Django layer? Nginx works extremely well as an ssl endpoint.

More importantly, why are you even trying to run runserver (or runsslserver) in a deployment environment?

I couldn’t configure nginx properly and used runsslserver as I was on a deadline.

I edited it with the the full traceback. What do you think is causing the error? I suspect this is SSL Timeout but I can’t seem to isolate it.

I am running this as root.

Do you suggest I use another user to run this.

Then I wouldn’t be able to use runsslserver with the --key and --certificate

Further, nginx.conf should be on root to access cert and key.

Shouldn’t that cause the same issue?

I also get GET requests from random malware -

Bad Request: /teorema505

what should I do to ensure the infra is secure?

Only if you’re exposing this site to the outside world and don’t want to increase the number of security vulnerabilities created by your system. (Now, if you don’t care what happens to this system, or to any system on the same subnet as this one, then it may not be a concern to you.)

You can copy the private key to another file owned by a group that your user is a member of.

Actually, nginx (and Apache, and a number of other similar systems) start as root, get access to whatever privileged resources are needed, and then change to the UID that it will serve users as.

That’s a huge topic - far more than what can be covered in a single post here. I’ve touched on a couple things about this specific topic at: Django URL's security.
Another good thing to do is to move the admin off of the “admin/” url path. Pick some other non-obvious name that fits into your general naming scheme, and assign the url to it.

Be aware that security is never something you’re “done” with. It requires on-going effort and dilligence. You will need to plan to spend time every week ensuring that the server is healthy.

I’m thinking a corrupted, malformed, or improper formatted file. I’d check it with something like nginx to verify that the file is good. If it is, then I’d probably try running sslserver with as much logging enabled as possible to see if additional information can be obtained.

Quoting directly from GitHub - teddziuba/django-sslserver: A SSL-enabled development server for Django

Please note that this should not be used for production setups. This app is intended for special use-cases. Most people should instead do a proper production deployment where a real webserver such as Apache or NGINX handles SSL.

If the authors of a project are saying that they don’t trust their software in a production environment, is it wise for you to do so?

If nothing else, gunicorn should be considered a viable alternative.