HTTP 500 on subdomain

Hi there,
I really need to learn more about encryption and server admin and meanwhile I am making noob mistakes.

My domain is: pequity.app
My web server is (include version): Nginx(1.14.0) + Gunicorn(20.0.4)

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

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): 0.31.0


I successfully installed a cert for the www and non www versions using python - certbot - nginx (on 26.01.2020)
I have a Django - Vue app.
The Vue frontend is served by Nginx and the Django backend by Gunicorn + Nginx.
I am still developping the app and wanted to setup SSL on the server.
It’s a multi-tenants app and I added a test subdomain.
I found out about Let’s encrypt wildcard certs and decided it would be a better choice for me.
So I wasn’t sure how to go about this: do I delete the cert I issued a week ago?
Anyway, I just issued a wildcard cert and I ended up with 2 certs and all their files.
I issued the cert delete command, deleted the previous certs.
Then I renamed the letsencrypt dir to letsencryptold because it still had a dpharma file and some conf file and some dirs.
Now, if I go to the non-www version, click on the SSl icon, I can see it uses my second cert, the wildcard one.
The www version uses the first cert, although I have no idea where this one or his ghost lives (thought I nuked everything I could)
If I go to test.pequity.app (my test subdomain), I get a http 500 error.
Now the questions:

  1. Do I need to revoke a cert to completely get rid of it?
  2. Will my wildcard cert cover the www version too?
  3. is my DNS zone looking ok?

  1. I add my tenants using Django shell. I setup a test tenant subdomain as test.pequity.app. Can this be more of a Django caused error or a SSL one?

  2. Is it better to use CNAME to point www to non-www than to add 2 distinct A records? Will my cert work if I deleted that A record and used CNAME instead?

  3. I created 2 server blocks that look very much the same, except for the name part. Is there something wrong in here?
    server {
    listen 80;
    listen [::]:80;
    root /var/www/pequity.app/html/frontend/dist/;
    index index.html index.htm index.nginx-debian.html;
    server_name test.pequity.app www.test.pequity.app;

    location = /favicon.ico {
    access_log off; log_not_found off;
    }

     location / {
     try_files $uri $uri/ /index.html;
     include proxy_params;
     	proxy_pass http://unix:/run/gunicorn.sock;
     }
    

    location /static {
    alias /var/www/pequity.app/html/backend/static;
    }

    location /media {
    alias /var/www/pequity.app/html/backend/media;
    }

    location ^~ /api/ { # Define routes to be directed to backend as proxy
    include proxy_params;
    proxy_redirect off;
    proxy_pass http://0.0.0.0:8000;
    }

    location ^~ /admin {
    include proxy_params;
    proxy_redirect off;
    proxy_pass http://0.0.0.0:8000;
    }

    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/pequity.app/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/pequity.app/privkey.pem;
    #include /etc/letsencrypt/options-ssl-nginx.conf;
    #ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
    }
    Ending my saga here, hope I can get some clues.
    Cheers,
    Io

2 Likes

I can help, but only with about 50% of the questions. The more complex stuff requires more technically skilled people…

Will my wildcard cert cover the www version too?

Yes, but it won’t cover subdomains with www.(not that anyone should type a URL that way anyway). For example, abc.pequity.app is covered AND www.pequity.app is covered, but not www.abc.pequity.app

is my DNS zone looking ok?

I think so, but running ‘certbot certificates’ and posting the output here will confirm it. (this is my goto command because it reveals any issues / setup issues)

Is it better to use CNAME to point www to non-www than to add 2 distinct A records? Will my cert work if I deleted that A record and used CNAME instead?

From a web-standard perspective, I am unsure, but from SEO, a redirect from www. to [not www]. is the proper way. You want one copy of any page, not 2. Google will see www. and [not www]. as separate pages even if the exact same file is pointed to… :frowning:

A 301 redirect is a fairly good place to start from my understanding.

Hope some of these answers help, I am sure rg or one of the more experienced members can help you when they get time - just stay active on here so you can catch them while they are on!!!

Best of luck.

2 Likes

Can you chase down the error log for your web server? Different versions of Linux keep it in different places; you might need to start from the web-server’s configuration file to find where it is kept.

At any rate, the 500 error says that the web server (or a script it was running) had a fatal internal error. There should be some info in the error log saying more about this, and you will need to dig that out in order to diagnose the problem further.

Good luck.

4 Likes

Thank you for your replies @LuB & @dk_means!

not that anyone should type a URL that way anyway
I know, but need to cover this case.
Here’s certbot certificates:

Saving debug log to /var/log/letsencrypt/letsencrypt.log 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Found the following certs:
Certificate Name: pequity.app
    Domains: *.pequity.app pequity.app
    Expiry Date: 2020-05-03 10:44:39+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/pequity.app/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/pequity.app/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

A 301 redirect is a fairly good place to start from my understanding.

Is it enough to add a CNAME for the www to point to the non-www, or do I need to do the redirect in my nginx server block too?
Here’s my nginx error.log:

2020/02/04 08:33:42 [crit] 26185#26185: *5118 SSL_do_handshake() 
failed (SSL: error:1420918C:SS

Maybe it’s worth mentioning I noticed something weird: before setting up my SSL cert, before even setting up my domain, while accessing the ip I got redirected to SSL and got a “site not secure” error.
Anyway, I am trying to dig further.
Here’s my netstat -antp:

L.E.
I tried to restart server using Django’s server this time and the backend is served on the test.pequity.app subdomain.
Obviously it’s an Nginx problem, I’ll debug further… :smiley:

2 Likes

Here’s my Nginx error log, if it helps:

020/02/04 08:33:42 [crit] 26185#26185: *5118 SSL_do_handshake() 
failed (SSL: error:1420918C:SSL 
routines:tls_early_post_process_client_hello:version too low) while SSL 
handshaking, client: 208.93.153.177, server: 0.0.0.0:443
2020/02/04 14:38:15 [notice] 32149#32149: signal process started
1 Like

This thread may be helpful. It appears that the client request included only SSL versions that are disabled in your SSL configuration, probably for good reasons.

2 Likes

The part that puzzles me is I can access the backend, but the frontend gives me the 500 error.
Code is the same for both main domain and subdomain…
To make things more interesting I tried again to run it with gunicorn and the backend works.
So if I go to test.pequity.app - I get 500
If I go to any django link (test.pequity.app/anydjangolink) - it works…

2 Likes

My experience is with Apache, not NGINX, but this sounds very much like a URL rewrite going amok. To sharpen the test, I verified that the bare URL (test.pequity.app) fails with a 500 error whether I use HTTP or HTTPS. But if I make the URL more explicit (test.pequity.app/index.html), the server returns a 404 error.

So there must be something wrong at a pretty basic level with the way your NGINX is handling URL expansion when there is no page in the URL.

3 Likes

When I first installed the normal cert for www and non-www, using the nginx flag, I got 2 files inside letsencrypt dir: dhparam.pem and ssl nginx conf smth.
When I installed the wildcard cert, I understood I needed to setup nginx myself. Do I need to generate those files myself? The only thing I did was edit the server blocks inside the sites-available.

Ok, I think I am on to something:
In my sites-available server blocks, I had this line:
proxy_pass http://unix:/run/gunicorn.sock;
I checked everything inside /run/
There’s no gunicorn.sock in there, so I just copied this config from some gunicorn django vue tutorial.
I removed that line from my server blocks.
Reloaded Nginx, now I am using Django’s server just to test if it works.
Again, the backend urls show fine. I get the default nginx page when I go to the test.domain adress.

1 Like

Ok, the problem was in my nginx configuration. I learned more about it, fixed my location paths, some permissions were also wrong and now it works.
Just need to add a few more headers and correct static files paths and everything will be fine.
Thanks again for your insights :hatching_chick:

2 Likes

Let me address the CNAME & 301 redirect for the www to non-www. If someone accesses the https://www. site directly, then they will get a Certificate error page. One workaround is to throw a redirect to http://(non-www) which should have a redirect to https://(non-www). However, I’ve seen mixed results. You’re better off just generating a cert for the www. versions of your subdomain. I personally don’t put any entries or routes for the www. versions of my subdomains.

2 Likes

Hmmm, thank you so much for chiming in :smiley:
Yeah, I was wondering how to solve that. If I’d generated a cert to cover that case, would it be wildcard cert?
Cause I’ll need to cover quite a few sub domains at some point.
Would it be smth like www.*.domain.com?
I’ve seen this type of regex is not allowed in the nginx config files.

1 Like

I haven’t seen any CAs actually support that format. It would have to be a single-domain www.sub.domain.tld cert for each one you need. There is no workaround for that.

2 Likes

Got it, makes sense :smiley:
I will think about it cause right now it’s all in a very early stage.

1 Like

Oh also, technically you can generate a multi-domain cert if you want to cover all the www.sub on a single cert, it would just be a super long command with all of them added in (LE supports up to 100 domains on a single cert).

2 Likes

Good to know, will do, thank you.

1 Like

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