Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My site was working but I let my cert expire thinking that it would renew automatically the way I set it up. It did not so I ran certbot after certbot I get an error that says my site isn't redirecting properly. It was working before. I shut down the server and redeployed the site from scratch in a new location on the server, now I'm back to the beginning. Please help.

My domain is:

I ran this command: sudo certbot --nginx -d -

It produced this output:
too late for that
My web server is (include version): AWS

The operating system my web server runs on is (include version): NAME="Amazon Linux"
ID_LIKE="centos rhel fedora"
PRETTY_NAME="Amazon Linux 2"

My hosting provider, if applicable, is: Amazon

I can login to a root shell on my machine (yes or no, or I don't know): no but I have a shell with sudo capability

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.11.0

My NGINX sites available

server {
        listen 80;
        return 307 https://$host$request_uri;
        location = /favicon.ico {access_log off; log_not_found off;}
        location /static/{
                root /var/www;
        location /{
                proxy_set_header Host $http_host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_pass http://unix:/var/log/gunicorn/cryptonik.sock;

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


server {
    if ($host = {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    if ($host = {
        return 301 https://$host$request_uri;
    } # managed by Certbot

        listen 80;
    return 404; # managed by Certbot

Hi @snswrld, and welcome to the LE community forum :slight_smile:

The first server block shown is listening to both (port 80 and port 443).
That is extremely difficult to do correctly.
[it should probably just be listening on port 443; As it has a certificate for that]

We would need more of that output to work with.
Can you show the logfile?
[usually: /etc/letsencrypt/letsencrypt.log]
[usually: /var/log/letsencrypt/letsencrypt.log]


It's in conflict with the block just beneath it :wink:


And the one beneath is the one being used:

curl -Ii
HTTP/1.1 301 Moved Permanently

301 NOT 307:


cat: /etc/letsencrypt/letsencrypt.log: No such file or directory

There is no logfile under /etc/letsencrypt

I got rid of listen 80; in the top server block. Should I change the 301 redirects to 307?

It's usually /var/log/letsencrypt/letsencrypt.log, @rg305 needs some coffee :wink:

Also 301 is fine: it means the location has permanently changed and not temporarily. You want permanently, as your HTTPS should be sort of the default.


2022-08-05 17:14:59,936:DEBUG:certbot.display.util:Notifying user: Congratu
lations! You have successfully enabled and
2022-08-05 17:14:59,936:DEBUG:certbot._internal.reporter:Reporting to user:
If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: Donate - Let's Encrypt
Donating to EFF: Support EFF's Work on Let's Encrypt | Electronic Frontier Foundation

You should remove that line from your https block. It is creating an infinite loop of redirects


OK commented out that line and now I get 502 bad gateway error

Is this even allowed, combining the http:// protocol with unix:? Doesn't make much sense to me, I don't think you can do "HTTP" using an Unix socket anyway. I stand corrected, Module ngx_http_proxy_module mentions this as a valid thing :roll_eyes: My bad.

In that case it might throw a 502 for many reasons, perhaps gunicorn isn't running. Please see the nginx and/or gunicorn log files for more info.

Although I think the /var/log/ tree is not the correct place for a socket.


Nevermind - lots of cross-posts
I wondered about http and unix too but apparently it is ok. The nginx docs say you need a colon after .sock but maybe just if a /uri/ is used? Not sure

or as a UNIX-domain socket path specified after the word “unix” and enclosed in colons:

proxy_pass http://unix:/tmp/backend.socket:/uri/;


I didn't think it was right but it's on the django site

I think it's a nginx thingy (and perhaps other specific services too). As I understand it, Unix sockets are generic sockets for inter-process communication on the same host. I don't think the "Unix socket" definition per se defines the content of that communication, so processes like nginx can decide to just use HTTP trough their Unix socket instead of a TCP/IP socket. And to configure such a thing, you get weird values as http://unix:/... apparently :stuck_out_tongue:

Anyway, please refer to the nginx and/or gunicorn log files to see what's going on with your 502 error.


You could try gunicorn status

sudo systemctl status gunicorn

Is it running without errors?


Ok gunicorn failed, so I am going to go track that error down now. I thank you for your help.


I'm going back to bed and restarting my entire day - LOL


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