nginx
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
settings has the IP and domain name in ALLOWED_HOSTS
ALLOWED_HOSTS = ['45.33.116.204', 'domain.org']
https://www.domain gets
The connection has timed out
An error occurred during a connection to www.dev-m28t.org.
The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer’s network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the web.
IP
Starting development server at http://0.0.0.0:8000/
Quit the server with CONTROL-C.
So how do get it to start with https
Please post the nginx conf file for your application.
Both dev-m28t.org and www.dev-m28t.org resolve to 104.200.19.103 and 2600:3c00::f03c:93ff:fe61:1a26, so the DNS entry appears to be correct (if those are your addresses).
However, none of
wget http://104.200.19.103/
wget http://2600:3c00::f03c:93ff:fe61:1a26/
wget https://104.200.19.103/
wget https://2600:3c00::f03c:93ff:fe61:1a26/
wget http://dev-m28t.org/
wget https://dev-m28t.org/
wget http://www.dev-m28t.org/
wget https://www.dev-m28t.org/
manage to make a connection.
Therefore, the issue is not with your DNS. It’s either an nginx configuration issue or possibly a firewall issue.
Now, if your address is actually 45.33.116.204, an http request to that address responds with the default nginx home page.
And, requesting https://45.33.116.204 shows that the certificate on that address belongs to dev-m28t.org, issued yesterday.
So, I’m guessing your real IPv4 address is 45.33.116.204, in which case you don’t have your DNS entry configured correctly.
Continuing on, creating a local hosts file entry for this address allows me to connect, but now I’m getting an nginx 403 error. This implies that your Django service isn’t properly configured.
ok you are correct and I have updated it, old file :(. Now how do I do runserver to use 443?
You don’t.
You do not use runserver in production.
Quoting directly from the runserver docs:
DO NOT USE THIS SERVER IN A PRODUCTION SETTING.
For what to do, see the references identified at Deployed site not reachable by domain name - #6 by KenWhitesell for information on how to properly configure your project. I can’t be more specific here because the details may vary (slightly) based upon what Linux distro and wsgi container you are using. (You’ve identified one of the variables - you’re using nginx instead of Apache or one of the others.)
Ok so that is where wsgi or asgi come in
python3 manage.py check --deploy
?: (security.W004) You have not set a value for the SECURE_HSTS_SECONDS setting. If your entire site is served only over SSL, you may want to consider setting a value and enabling HTTP Strict Transport Security. Be sure to read the documentation first; enabling HSTS carelessly can cause serious, irreversible problems.
?: (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True. Unless your site should be available over both SSL and non-SSL connections, you may want to either set this setting True or configure a load balancer or reverse-proxy server to redirect all connections to HTTPS.
?: (security.W009) Your SECRET_KEY has less than 50 characters, less than 5 unique characters, or it's prefixed with 'django-insecure-' indicating that it was generated automatically by Django. Please generate a long and random value, otherwise many of Django's security-critical features will be vulnerable to attack.
?: (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a secure-only session cookie makes it more difficult for network traffic sniffers to hijack user sessions.
?: (security.W016) You have 'django.middleware.csrf.CsrfViewMiddleware' in your MIDDLEWARE, but you have not set CSRF_COOKIE_SECURE to True. Using a secure-only CSRF cookie makes it more difficult for network traffic sniffers to steal the CSRF token.
?: (security.W018) You should not have DEBUG set to True in deployment.
Down to this last warning
You have not set a value for the SECURE_HSTS_SECONDS setting. If your entire site is served only over SSL, you may want to consider setting a value and enabling HTTP Strict Transport Security. Be sure to read the documentation first; enabling HSTS carelessly can cause serious, irreversible problems.
Any thoughts as how to proceed?
I know how I’ve handled this situation. Whether or not what I’ve done is right for you isn’t something I can answer.
I use nginx as the ssl termination point. Nginx proxies the request through the uwsgi container to Django, but not as ssl.
I have nginx configured to forward the X-Forwarded-Proto header through to Django.
I then have the SECURE_PROXY_SSL_HEADER setting configured in Django to have Django read the X-Forwarded-Proto to treat the connection as being secured - even though Django itself isn’t involved in the ssl connection.
ok i went ahead and set it to 3600 and it passed the checks
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 3600
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_HSTS_PRELOAD = True
(env) root@localhost:~/m28t/m28t_app/m28t# python manage.py check --deploy
System check identified no issues (0 silenced).
I am trying to figure out where to go from here, also using sqllite as the database.
Now you need to configure some wsgi or asgi webserver.
For wsgi you can use gunicorn.
For asgi you can use uvicorn.
There are other options, it’s up to you to choose one.
