letsencrypt standalone certification not showing up on GET request - django

I was able to create certifications under the path /etc/letsencrypt/{{mywebdomain}}/ and set under my server where the ssl_cert and ssl_cert_key absolute pathfile locations for my nginx server.
When I run the command sudo nginx -t I receive a successful configuration output and the nginx server is running in the reverse proxy for Django without any problems. But when I access the root of my website on my chrome browser, I'm receiving the "http://website.com" instead of "https://website.com".
Please point me in the right direction if anyone was able to correctly encrypt their domain content with gunicorn-django-nginx configuration.
My website snippet conf:
upstream app_server {
unix:/home/me/Documents/masterdomain/src/portfolio_revamp.sock;
}
server {
client_max_body_size 4M;
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;
listen www.mysite.com:80;
server_name example.com www.example.com;
http://example.com;
ssl_certificate
/etc/letsencrypt/live/mysite.com/fullchain.pem;
ssl_certificate_key
/etc/letsencrypt/live/mysite.com/privkey.pem;
root /home/akeem/Documents/SpencerMaster/src;
index templates/home.html templates/main.html;
location / {
proxy_pass
http://unix:/home/me/Documents/masterdomain/src/portfolio_revamp.sock;
alias /home/me/Documents/master/templates/home.html;
}
location ~ /.well-known {
allow all;
}
location /static {
autoindex on;
alias /home/me/Documents/masterdomain/static;
}
location /media {
autoindex on;
alias /home/me/Documents/masterdomain/media;
}
}
I'm running a xenial ubuntu 16.04 server if that makes a difference.

I believe the issue is that you aren't redirecting to HTTPS - unless you specifically enter https://example.com, you'll be directed to the standard http://example.com.
I use this guide from DigitalOcean which recommends two server blocks. In your case it will look something like:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name mysite.com www.mysite.com;
return 301 https://$server_name$request_uri;
}
server {
client_max_body_size 4M;
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
No server_name required here
... Everything else ...
}

Related

AWS Amplify redirect change from post to get?

I'm trying to connect to my backend api, usually anything that is /intApi/<*> gets sends over to different api.domain.com. but for some reason the request changes from post to get.
+
I'm using nginx to do
listen 80;
listen [::]:80;
server_name api.domain.com www.api.domain.com;
location / {
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 http2 ssl;
server_name api.domain.com www.api.domain.com;
ssl_certificate /etc/nginx/ssl/live/api.domain.com/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/live/api.domain.com/privkey.pem;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://backendDocker:3500/;
}
location ~ /.well-known/acme-challenge/ {
root /usr/share/nginx/web/api;
}
}
To push it further and nginx output is either OPTIONS or GET instead of POST.
What am I doing wrong here? I tried 301/302 redirects. Same issue :/

Accessing via www. will show Nginx welcome page [+ Gunicorn + Django]

Nginx + Ubuntu 18.04 + Django 2.2.10
Accessing directly via "www.examples.com" will show nginx welcome page, but accessing anything else--"examples.com", "https://examples.com", "https://www.examples.com"--will work as expected.
On DigitalOcean, I have two A-type records [www.examples.com, examples.com] directing to the IP address--I believe they are correctly set up.
On my Django project, I have ALLOWED_HOSTS = ['localhost', 'examples.com', '137.68.49.136', 'www.examples.com'] set.
Here is my /etc/nginx/sites-available/project:
server {
server_name examples.com www.examples.com;
charset UTF-8;
error_log /home/jay/eco/nginx-error.log;
location = /favicon.ico { access_log off; log_not_found off; }
location /static {
alias /home/jay/eco/static;
}
location /media/ {
alias /home/jay/eco/media/;
}
location / {
include proxy_params;
proxy_pass http://unix:/run/gunicorn.sock;
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/examples.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/examples.com/privkey.pem; # managed by Certb$
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = examples.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name examples.com;
return 404; # managed by Certbot
}
I believed this was everything but apparently not. What am I missing?
You have two server blocks, the first processes requests using the https protocol and the second processes requests using the http protocol. There is also a default server block in some other file, which responds with the Nginx welcome page.
The second server block in your question only processes requests for http://example.com. You need to add www.example.com to the server_name directive, and update the logic so that both domain names are redirected to the https service.
For example:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
See this document for details.

Problem when reconfiguring Nginx for SSL with self-signed certificate

I have a VPS on Digital Ocean with Ubuntu 18.04, Nginx, Gunicorn, Django, and a test web application, all configured (ufw) to work with http: 80. Everything works perfectly. Tutorial
Now I modify the file /sites-available/LibrosWeb to allow SSL traffic with a self-signed certificate, since I do not have a domain. Tutorial. Result "Error 502 Bad Gateway".
This is the initial code that works well with http: 80:
server{
#Configuracion http
listen 80;
listen [::]:80;
server_name 15.15.15.15;
location = /favicon.ico { access_log off; log_not_found off; }
location /robots.txt {
alias /var/www/LibrosWeb/robots.txt ;
}
location /static/ {
root /home/gela/LibrosWeb;
}
location / {
include proxy_params;
proxy_pass http://unix:/run/gunicorn.sock;
}
}
And this is the code to allow SSL (error 502):
server{
#Configuracion SSL
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name 15.15.15.15;
include snippets/self-signed.conf;
include snippets/ssl-params.conf;
location = /favicon.ico { access_log off; log_not_found off; }
location /robots.txt {
alias /var/www/LibrosWeb/robots.txt ;
}
location /static/ {
root /home/gela/LibrosWeb;
}
location / {
include proxy_params;
proxy_pass https://unix:/run/gunicorn.sock;
}
}
server{
#Configuracion http
listen 80;
listen [::]:80;
server_name 15.15.15.15;
return 302 https://15.15.15.15$request_uri;
}
UFW configured as:
80,443/tcp (Nginx Full) ALLOW IN Anywhere
80,443/tcp (Nginx Full (v6)) ALLOW IN Anywhere (v6)
The files /etc/nginx/snippets/self-signed.conf and /etc/nginx/snippets/ssl-params.conf are the same as those in the tutorial.
I've been testing configurations for two days and the most I could get is that I work halfway, that is, I can show the default page of django but not the one of my application, if I put the code like this:
server{
#Configuracion http
listen 80;
listen [::]:80;
server_name 15.15.15.15;
return 302 https://15.15.15.15$request_uri;
location = /favicon.ico { access_log off; log_not_found off; }
location /robots.txt {
alias /var/www/LibrosWeb/robots.txt ;
}
location /static/ {
root /home/gela/LibrosWeb;
}
}
server{
#Configuracion SSL
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name 15.15.15.15;
include snippets/self-signed.conf;
include snippets/ssl-params.conf;
location / {
include proxy_params;
proxy_pass https://unix:/run/gunicorn.sock;
}
}
What is wrong, or what is missing?
I think my days of suffering are over. After reading hundreds of logs, I found the problem. An update of Whitenoise to 4.0 where you must change the shape of the configuration, caused that with my old configuration the gunicorn service will throw errors. The rest is all right.
http://whitenoise.evans.io/en/stable/django.html#django-middleware
Thanks for the help.
Good day.

Nginx redirect (non-www to www) not working with Certbot

I have a website running with a Python/Django/uWSGI/Nginx setup. I also use Certbot to enable https on my site. My redirects from non-www to www (e.g. "example.com" to "www.example.com") result in a "Bad Request (400)" message even though I couldn't spot any deviations from the Nginx/Certbot documentation. Here is the relevant part of my sites-available Nginx code:
server {
listen 80;
server_name example.com www.example.com;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/myname/example;
}
location / {
include uwsgi_params;
uwsgi_pass unix:/run/uwsgi/activities.sock;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; #managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; #managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
if ($scheme != "https") {
return 301 https://$host$request_uri;
} # managed by Certbot
}
I found a similar StackOverflow answer (Nginx: redirect non-www to www on https) but none of the solutions worked for me. I have SSL certificates for both example.com and www.example.com. I also tried creating a separate 443 ssl server block for example.com based on the comments in that answer but it didn't work either. My sites-available and sites-enabled code is the same.
What am I doing wrong?
It seems that server_name when translated to the $host variable selects the first in the list of server_name. Let me know if that works. I can't quite test this currently.
Try swapping server_name to server_name www.example.com example.com; as well as changing return 301 https://$host$request_uri; to return 301 https://$server_name$request_uri;
server {
server_name www.example.com example.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
# SSL CERT STUFF.
server_name example.com;
return 301 https://www.$server_name$request_uri;
}
server {
listen 443 ssl;
# SSL CERT STUFF.
server_name www.example.com;
# LOCATION STUFF
}
This is not an efficient configuration for Nginx request processing. It's messy, your if condition gets evaluated on every request and I don't see where your non www to www is even meant to happen.
I'd split http and https:
server {
listen 80 default_server;
return 301 https://www.example.com$request_uri;
}
Thats all non https traffic taken care of in a single redirect. Now for the https:
server {
listen 443 default_server ssl;
server_name www.example.com;
root # should be outside location blocks ideally
......
}
The default server directive means this server will handle any requests which do not have a matching server configuration. If you don't want that then add example.com after www.example.com, not before it. Any requests ending up here will display the first entry in the client browser bar.
Based on your comments you might need to add a separate block for the other domain to avoid an SSL certificate mismatch. Try this:
server {
listen 443 ssl;
server_name example.com;
ssl_certificate .....;
ssl_certificate_key .....;
return https://www.example.com$request_uri;
}
Although the OP has accept one of the answers as the solution, I just want to point out that it may not be the best practice.
The correct way is to use $host instead of $server_name (as per Mitchell Walls' example) or hardcoded www.exmple.com (as per miknik's example). Both results an extra 443 server directive that is not necessary and messy.
server {
listen 80 default_server;
server_name www.example.com example.com;
root /var/www/html; # define your root directory here
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
# SSL CERT STUFF.
#server_name www.example.com; you don't need to specify again here
# LOCATION STUFF
}
There is a difference between $host and $server_name:
$host contains "in this order of precedence: host name from the request line, or host name from the 'Host' request header field, or the server name matching a request".
$server_name contains the server_name of the virtual host which processed the request, as it was defined in the nginx configuration. If a server contains multiple server_names, only the first one will be present in this variable.

Website goes unresponsive after directing to https in nginx server

I have a web application in django framework and I have setup an nginx server to serve the site. I have also setup SSL into the site. The site works fine with both http and https.
Now I want to direct all http requests to https so my users always use the secure version.
Here is my nginx config:
server {
listen 80;
listen 443 ssl;
server_name site.com www.site.com;
ssl_certificate /path/to/SSL;
ssl_certificate_key /path/to/SSL/key;
location = /favicon.ico { access_log off; log_not_found off; }
location /site_media/static/ {
alias /home/user/folder/static/dist/;
}
location / {
include uwsgi_params;
uwsgi_pass unix:/tmp/site.sock;
}
}
Now when I insert a 301 redirect to https and restart the server, the site goes unresponsive.
return 301 https://$server_name$request_uri;
into my
server { ... }
Any idea how to fix this issue, any suggestions would be highly appreciated.
Placing an unprotected return statement into the server block will attempt to redirect both the http and https sites, resulting in a loop. You could place the return statement inside an if block and detect when the protocol is not https, or the more common solution is split the configuration across two server blocks, for example:
server {
listen 80;
server_name site.com www.site.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name site.com www.site.com;
ssl_certificate /path/to/SSL;
ssl_certificate_key /path/to/SSL/key;
location = /favicon.ico { access_log off; log_not_found off; }
location /site_media/static/ {
alias /home/user/folder/static/dist/;
}
location / {
include uwsgi_params;
uwsgi_pass unix:/tmp/site.sock;
}
}