BAD REQUEST 404 - nginx/Ubuntu (https/http?)


#1

Steps Taken / Output produced:

  1. Set up a sample blog app from a tutorial in django
  2. Using a droplet from digital ocean, I successfully hosted this django project online.(without a domain name, just using the IP address)
  3. Got a domain name from namecheap and linked it with digital ocean (followed every tutorial and crossreferenced things to make sure they were right)
    3B) This is where it goes downhill… I forgot to check if the website was working with the new domain name ‘ericlbaker.me’ before I started setting up a free SSL from “LetsEncrypt” to get everything to redirect to ‘https’.
  4. Using the certbot full auto configuration, I set up the certificate associated with my test website. No errors.
  5. I try to go to my website, typing the domain name with ‘http’ https’ and ‘www’ variations, all of which redirect (as they should) to ‘https://ericlbaker.me’ or ‘https://www.ericlbaker.me’. However, I no longer see my web app as I did before. Only a 404 BAD REQUEST. I even tried accessing with various ports that I tried to run it from on the digital ocean console.
  6. I check the certificate on “SSLLabs.com” and everything seems to be okay until I go into the details. Under “HTTP REQUESTS” section it says ‘https://ericlbaker.me/ (HTTP/1.1 400 Bad Request)’.
  7. I began adding ipv6 configurations as well but stopped because I wanted to sort this stuff out first.

I am not sure what else to try because I have spent 2 days in a row in front of my computer going through various tutorials and I feel at this point I may start editing things that just dig a deeper hole for myself. Thanks for your time!!


My web server is (include version): nginx /1.14.0

The operating system my web server runs on is (include version): Ubuntu 18.04

My hosting provider, if applicable, is: Digital Ocean

I can login to a root shell on my machine (yes or no, or I don’t know): yes


#2

Hi @Elb5465

your Ssl-certificates are ok. Both domains:

CN=ericlbaker.me
13.12.2018
13.03.2019
ericlbaker.me, www.ericlbaker.me - 2 entries

You have “only” a bad request. Checked with my own online tool https://check-your-website.server-daten.de/?q=ericlbaker.me :

Domainname Http-Status redirect Sec. G
http://ericlbaker.me/
157.230.2.111 301 https://ericlbaker.me/ 0.197 A
http://www.ericlbaker.me/
157.230.2.111 301 https://www.ericlbaker.me/ 0.200 A
https://ericlbaker.me/
157.230.2.111 400 2.320 M
Bad Request
https://www.ericlbaker.me/
157.230.2.111 400 2.096 M
Bad Request

So opening a connection -> works.

Creating a SSL connection -> works

But then your webserver doesn’t process the request.

Check your nginx error log. There you should find some ideas.


#3

Thanks for the quick response @JuergenAuer!

I just checked the error log for nginx and there seem to be a lot of errors of various levels. It seems to not connect to the link provided upstream with ‘gunicorn’ in it. I saw in a digital ocean tutorial they instead used the name of the website there in the ‘proxy_pass’ instead of what was included automatically (‘unix:/home/django/gunicorn.socket’). I am still not sure what I should do because I don’t want to keep blindly changing configuration files and really wreck the project.

" [notice] 6822#6822: signal process started
2018/12/13 13:56:55 [notice] 6867#6867: signal process started
2018/12/13 13:58:17 [crit] 6868#6868: *191 SSL_do_handshake() failed (SSL: error:1417D18C:SSL routines:tls_process_client_hello:version too low) while SSL handshaking, client: 2600:c02:1020:4202::ac10:8266, server: [::]:443
2018/12/13 14:00:12 [crit] 6868#6868: *448 SSL_do_handshake() failed (SSL: error:1417D18C:SSL routines:tls_process_client_hello:version too low) while SSL handshaking, client: 64.41.200.102, server: 0.0.0.0:443
2018/12/13 14:20:18 [emerg] 7034#7034: bind() to 0.0.0.0:443 failed (98: Address already in use)
2018/12/13 14:20:18 [emerg] 7034#7034: bind() to 0.0.0.0:443 failed (98: Address already in use)
2018/12/13 14:20:18 [emerg] 7034#7034: bind() to 0.0.0.0:443 failed (98: Address already in use)
2018/12/13 14:20:18 [emerg] 7034#7034: bind() to 0.0.0.0:443 failed (98: Address already in use)
2018/12/13 14:20:18 [emerg] 7034#7034: bind() to 0.0.0.0:443 failed (98: Address already in use)
2018/12/13 14:20:18 [emerg] 7034#7034: still could not bind()
2018/12/13 14:27:58 [notice] 7143#7143: signal process started
2018/12/13 14:27:58 [error] 7143#7143: invalid PID number “” in “/run/nginx.pid”
2018/12/13 14:28:03 [notice] 7147#7147: signal process started
2018/12/13 14:28:05 [notice] 7149#7149: signal process started
2018/12/13 14:28:23 [notice] 7151#7151: signal process started
2018/12/13 15:24:39 [crit] 7152#7152: *55 SSL_do_handshake() failed (SSL: error:1417D18C:SSL routines:tls_process_client_hello:version too low) while SSL handshaking, client: 2600:c02:1020:4202::ac10:8267, server: [::]:443
2018/12/13 15:26:35 [crit] 7152#7152: *322 SSL_do_handshake() failed (SSL: error:1417D18C:SSL routines:tls_process_client_hello:version too low) while SSL handshaking, client: 64.41.200.103, server: 0.0.0.0:443
2018/12/13 15:30:09 [crit] 7152#7152: *614 SSL_do_handshake() failed (SSL: error:1417D18C:SSL routines:tls_process_client_hello:version too low) while SSL handshaking, client: 2600:c02:1020:4202::ac10:8265, server: [::]:443
2018/12/13 15:30:51 [crit] 7152#7152: *735 SSL_do_handshake() failed (SSL: error:1417D18C:SSL routines:tls_process_client_hello:version too low) while SSL handshaking, client: 2600:c02:1020:4202::ac10:8268, server: [::]:443
2018/12/13 15:32:04 [crit] 7152#7152: *1073 SSL_do_handshake() failed (SSL: error:1417D18C:SSL routines:tls_process_client_hello:version too low) while SSL handshaking, client: 64.41.200.101, server: 0.0.0.0:443
2018/12/13 15:32:46 [crit] 7152#7152: *1246 SSL_do_handshake() failed (SSL: error:1417D18C:SSL routines:tls_process_client_hello:version too low) while SSL handshaking, client: 64.41.200.104, server: 0.0.0.0:443"

These are the logs from today - the other ones had to many links and it would not allow me to include them.


#4

**I just redid the certification to try to stop the redirects to https but they still happen when I don’t specify the port, however, when I try ‘ericlbaker.me:3333’ it works just as I had hoped, but with no https… The goal now is to actually get it working with https, which I guess will have to be manually configured since the certbot auto configure commands didn’t seem to do the trick. I tried running 'sudo $(which python) manage.py runserver 157.230.2.111:3333 and it works but when I use ‘443’ or ‘80’ just as a test, it says that they both are in use already. Do you know why? @JuergenAuer **


#5

If you test your site with Ssllabs, you will have a lot of SSL-Handshake-errors. Because Ssllabs tries a lot of things, this is completely irrelevant.

Check your last entries.

Then create an own 400 by using your browser.

Then check your log again.


#6

PS:

I don’t know if there are additional things. But your certificate works. It’s “only” a wrong webserver configuration.


#7

I get what you’re saying - Could you be more specific as to what you mean by webserver configuration? Do you mean on digital ocean, in my ‘.conf’ files, in nginx, certbot, etc.?


#8

Please do that:

Then you see your error.


#9

Using Google, this may be your problem. Exact the same thing.

It’s a special django option you must set. But I don’t use django.


#10

I am not even sure what you mean by create your own 400, but I have checked the log and there doesn’t seem to be anything different appearing.


#11

I really appreciate all your help - After reading through this link I realized that when the project was created, I also made a virtual environment which had a copy of the project in it somehow and this is what I have been trying to run. The problem I face now is that on the digital ocean platform there doesn’t seem to be a legitimate option to upgrade and use current versions of python and django in production, however, those don’t have much to do with this forum so I will find that on my own. Thanks again!


#12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.