I'm running my Django application on Digital Ocean with Ubuntu 16.04/Nginx/Gunicorn. I issued a (SSL?) certificate by running the following command:
sudo certbot --authenticator webroot --webroot-path /home/user/app --installer nginx -d aaa.com -d www.aaa.com
however I now want to change my domain from aaa.com to bbb.com. How do I keep my certificate for my new domain? When I ran the command to issue the certificate, I assume it created various files such as the directory .well-known - and also added code in my Nginx conf. So do I simply run the same command again, with the new domain in?
sudo certbot --authenticator webroot --webroot-path /home/user/app --installer nginx -d bbb.com -d www.bbb.com
or do I just change the current code and replace it with the new domain? E.g. my Nginx conf looks like this:
ssl_certificate /etc/letsencrypt/live/aaa.com/fullchain.pem; #
managed by Ce$
ssl_certificate_key /etc/letsencrypt/live/aaa.com/privkey.pem; # managed by $
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
I've already changed:
server {
listen 80;
server_name 172.128.67.232 bbb.com www.bbb.com;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/user/app;
}
to my new domain bbb.com.
Advice appreciated.
You can not "move" a certificate that was issued for domain aaa.com and use it for domain bbb.com.
Cleanest way to handle this would be to remove all references to the old aaa.com cert and the old https setup and then run the certbot .. command to have domain bbb.com set up.
Related
I have two servers QA and Prod. QA works great. The answers of this title is popular and I see few on SO itself. Let me explain why mine is different but first, here's QA's nginx config:
server {
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
# ssl on;
ssl_certificate /etc/nginx/ssl/cert.crt;
ssl_certificate_key /etc/nginx/ssl/ssl.key;
# https://ma.ttias.be/deploying-laravel-websockets-with-nginx-reverse-proxy-and-supervisord/
ssl_session_timeout 3m;
ssl_session_cache shared:SSL:30m;
ssl_protocols TLSv1.1 TLSv1.2;
# Diffie-Hellman performance improvements
ssl_ecdh_curve secp384r1;
root /var/www/api/html/dist/public;
index index.php index.html index.htm index.nginx-debian.html;
server_name <PUB_IP> <SOME-DOMAINS>;
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
fastcgi_param DOCUMENT_ROOT $realpath_root;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
}
[..]
}
Mine is different because on QA, I do not have a separate server block for port 80 and 443; it's works as is. For Prod, I'm getting
400 the plain http request was sent to https port
This triggers from our React server, a separate server used as the client (web).
PUB_IP: AWS Public IP address
SOME-DOMAINS: Examples: qa.website.com www.website.com
I'm not a devOps, I'm just a full stack web developer that sometimes deal with server installs (basic). Question, should PUB_ID be on the server_name line? I've never seen docs with that being there.
Both QA and Prod has the same nginx config, minus the IP addresses etc and only QA works. Ok, let's still make the change on Prod:
# Redirect traffic on port 80 to use HTTPS
# Per: https://aws.amazon.com/blogs/compute/deploying-an-nginx-based-http-https-load-balancer-with-amazon-lightsail/
server {
listen 80;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
#ssl on;
ssl_certificate /etc/nginx/ssl/cert.crt;
ssl_certificate_key /etc/nginx/ssl/ssl.key;
[..]
Restart nginx and getting that same error. How weird? Changes QA to use the above and all is well so something is wrong with Prod. QA was configured before Prod so I may missied a step installing some packages?
Please advice.
Note: Godaddy wild-card ssl certs are valid. I'm using nginx version 1.14.0. Visiting PUB_ID directly (https), web page does not load. Visit without https, it works (when removing ssl http2 from server listen).
I use Nginx as Reverse Proxy for a Django project with Gunicorn.
After following this tutorial from Digital Ocean How To Set Up an ASGI Django App I was able to visit my project through the server IP adress in a browser with http.
In the next step I followed the How To Secure Nginx with Let's Encrypt tutorial from Digital Ocean. Now the site was available with http:// and https:// in front of the IP adress.
To redirect the user automatically to https I used code from this tutorial.5 Steps to deploy Django
The outcome is the following file in /etc/nginx/sites-available:
# Force http to https
server {
listen 80;
server_name EXAMPLE_IP_ADRESS;
return 301 https://EXAMPLE_IP_ADRESS$request_uri;
}
server {
listen 80; # manged by Certbot
server_name EXAMPLE_IP_ADRESS;
# serve static files
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/user/projectdir;
}
location / {
include proxy_params;
proxy_pass http://unix:/run/gunicorn.sock;
}
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}
The redirect to https is working fine, so I assume the changes I made according to the last tutorial are okay.
After the tests with the EXAMPLE_IP_ADRESS as server_name went well I have changed the server_name to my domain in the form www.example.com
When I type the domain in the browser the only result is the Nginx Welcome page. So the connection to the server is successfull but Nginx is loading the wrong server block.
After searching for hours I came across this Question. Here the answer of ThorSummoner worked for me. The comment by mauris under this answer to unlink the default file in the sites-enabled was the command I needed.
unlink sites-enabled/default
(I posted this Q&A because I searched hours for the solution and hope this is reducing the search time for others having a Django project too with the same problem)
I'm trying to configure Certbot (Letsencrypt) with Nginx.
I get this error :
- The following errors were reported by the server:
Domain: koomancomputing.com
Type: unauthorized
Detail: Invalid response from
http://koomancomputing.com/.well-known/acme-challenge/xvDuo8MqaKvUhdDMjE3FFbnP1fqbp9R66ah5_uLdaZk
[2600:3c03::f03c:92ff:fefb:794b]: "<html>\r\n<head><title>404 Not
Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404
Not Found</h1></center>\r\n<hr><center>"
Domain: www.koomancomputing.com
Type: unauthorized
Detail: Invalid response from
http://www.koomancomputing.com/.well-known/acme-challenge/T8GQaufb9qhKIRAva-_3IPfdu6qsDeN5wQPafS0mKNA
[2600:3c03::f03c:92ff:fefb:794b]: "<html>\r\n<head><title>404 Not
Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404
Not Found</h1></center>\r\n<hr><center>"
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
in /etc/nginx/sites-available/koomancomputing :
server {
listen 80;
server_name koomancomputing.com www.koomancomputing.com;
location = /favicon.ico { access_log off; log_not_found off; }
location /staticfiles/ {
root /home/kwaku/koomancomputing;
}
location /media/ {
root /home/kwaku/koomancomputing;
}
location / {
include proxy_params;
proxy_pass http://unix:/run/gunicorn.sock;
}
}
my DNS A/AAAA records :
I didn't know what to do, so I did a search and find django-letsencrypt app, but I don't know hot to use :
Your domain has a proper AAAA record configured to your server over IPv6, and certbot chose that to validate your server.
However, your server block as configured under nginx only listens to port 80 on IPv4 for your domain. When certbot requests Let's Encrypt to access your challenge and issue a certificate, nginx isn't configured to properly respond with the challenge on IPv6. It often in this case returns other things (such as a 404 in your case, or a default site).
You can resolve this by modifying the first two lines to also listen on all IPv6 addresses for your server:
server {
listen 80;
listen [::]:80;
# other configuration
}
After editing, restart nginx and run certbot again.
Your Nginx server is responding with a 404 error because it does not define a route to /.well-known needed by certbot to verify challenges. You need to modify the Nginx config file to tell it how to respond to certbot's challenges.
Certbot can update the Nginx config file for you.
First, make sure your config file is enabled. Run sudo service nginx reload and check for the presence of a file called /etc/nginx/sites-enabled/koomancomputing.
Then, run certbot --nginx -d koomancomputing.com -d www.koomancomputing.com
The --nginx flag tells certbot to find an Nginx config file with a matching server name and update that file with SSL info.
server {
listen 80;
listen [::]:80;
# other configuration
}
Works for both IPV4 and IPV6 after adding this restart nginx.
For me, it worked after I removed and installed the latest certbot version using snapd.
I use cloudflare proxy option and it failed for certbot 0.31.0.
After installing certbot 1.27 and configuring the cert newly, it works fine even proxy toggle is on in cloudflare.
I am setting up a domain for my Django/Gunicorn/Nginx server. It works fine with IP address instead of domain name in server_name but when I add domain name it redirects to default Ubuntu Nginx page. My Nginx file looks like this (please note that I replaced my domain with example.com):
Path : /etc/nginx/sites-available/projectname
server {
listen 80;
server_name example.com;
return 301 $scheme://www.example.com$request_uri;
}
server {
listen 80;
server_name www.example.com;
client_max_body_size 4G;
location = /favicon.ico {access_log off; log_not_found off;}
location /static/ {
root /path/to/static/dir;
}
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://unix:/path/to/gunicorn.sock;
}
}
I have run the command sudo nginx -t and sudo service nginx restart but no effect. Please let me know if I am doing anything wrong.
1- see main nginx.conf how include all config files. if it is including site-enabled path then go to path and see is a shortcut to config file of this site under site available?
or if all sites are enabled in nginx config file include directly available
include /etc/nginx/sites-available/*;
2-mix two server define code once and with rule forward non www to with www
3-if not work check dns config problem and see result from inside of server via putty not from outside of server with browser to see it is nginx problem or dns config problem.
note: changing dns name servers taken some hours to work and effect on clients.
I have django, nginx, and gunicorn installed on a web server.
Nginx listens on port 80
Gunicorn runs django project on port 8000
This works fine. If I go to www.mysite.com:8000/myapp/ the django application comes up OK. But what if I want users to go to www.mysite.com/myapp/ to view the django application? I don't think getting rid of Nginx is the answer, and I'm hoping I missed some configuration tweak i can apply to make this work.
Any advice is appreciated.
You can use the following configuration, so you can access your website normally on port 80:
this is your nginx configuration file, sudo vim /etc/nginx/sites-available/django
upstream app_server {
server 127.0.0.1:9000 fail_timeout=0;
}
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
client_max_body_size 250M;
server_name _;
keepalive_timeout 15;
# Your Django project's media files - amend as required
location /media {
alias /home/xxx/yourdjangoproject/media;
}
# your Django project's static files - amend as required
location /static {
alias /home/xxx/yourdjangoproject/static;
}
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server;
}
}
and configure gunicorn as
description "Gunicorn daemon for Django project"
start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]
# If the process quits unexpectadly trigger a respawn
respawn
setuid yourdjangousernameonlinux
setgid yourdjangousernameonlinux
chdir /home/xxx/yourdjangoproject
exec gunicorn \
--name=yourdjangoproject \
--pythonpath=yourdjangoproject \
--bind=0.0.0.0:9000 \
--config /etc/gunicorn.d/gunicorn.py \
yourdjangoproject.wsgi:application
No, getting rid of nginx is definitely not the answer. The answer is to follow the very nice documentation to configure nginx as a reverse proxy to gunicorn.