Posts tagged ‘NGINX’

Configuring GoDaddy SSL Certificates on Nginx

There are a number of articles out there on how to install security certificates from GoDaddy on an Nginx server, but the GoDaddy process seems to have changed since those articles were published, so I thought I would jot down the process I had to follow in the hopes that someone else finds it useful.

First, it’s worth mentioning that GoDaddy has pretty cheap SSL certificates. They aren’t the greatest, they just verify the domain, but they are pretty useful for Facebook apps, which is especially important given Facebook’s recent drive to have more users access Facebook via https. This article was immensely helpful in getting me started in the right direction, but it left out 2 important steps that kept the certificate from being properly recognized.

You’ll need to break from the instructions in that article after step 2.3. When you select ‘other’ from the webserver dropdown on GoDaddy, your zip will not include the intermediary cert (whether it’s a Starfield or GoDaddy cert). You’ll need this intermediary cert, so head on over to GoDaddy’s cert repo and download either the gd_intermediate.crt (or sf_intermediate.crt if it’s a Starfield cert) and upload to your server.

Instead of running

1
cat www.mysite.com.crt gd_bundle.crt > mysite_combined.crt

Run the following (replacing your domain name and intermediate cert name as necessary):

1
cat www.mysite.com.crt gd_intermediate.crt gd_bundle.crt > mysite_combined.crt

From there, the previously cited article should get you the rest of the way… BUT, there’s one more issue. When you try restarting Nginx, you’ll likely see an error. The intermediary cert is missing a line break, so you’ll need to open up the combined cert and change this:

1
-----END CERTIFICATE----------BEGIN CERTIFICATE-----

To this:

1
2
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----

Password protect folders with NGINX

As a follow up to the earlier post regarding unexplained NGINX 404 errors as a condition of a poorly written location block, I thought it might be worth sharing another bad bit of code I have seen in a number of NGINX config files in the wild.  This topic is a bit more serious though as it involves password protecting folders rather than random 404s. It’s pretty common to have a location block that defines a webroot, an index, establishes password protection for the folder, and sets fastcgi params for dynamic page requests like so:

1
2
3
4
5
6
7
location = / {
    root   /var/www/nginx-default;
    index index.php;
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/htpass;
}
include php.conf;

Note, the “include php.conf;” line above is just a quick way we keep our virtual host files clean. The php.conf file contains our location ~ \.php$ block.

The code above is not secure. This location block will only be applied to requests matching “/” exactly (notice the “=” sign). If you access a page or resource directly, you circumvent the authentication entirely! So a request to www.somedomain.com will prompt you for a password, but www.somedomain.com/index.php will let you access index.php.

After a quick jump over to the Nginx wiki we see that using “^~” will allow us to apply a case insensitive regular expression to our location block. This means we are now protecting all contents within the desired folder as well. The wiki also says that a match will result in immediate termination, so be sure to define an additional dynamic page block within your containing location block if necessary (like if you need to run php files within the protected folder for, say, PHPMyAdmin). Notice our included php.conf file has been added within the location block to account for this.

1
2
3
4
5
6
7
8
location ^~ / {
    root   /var/www/nginx-default;
    index index.php;
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/htpass;
    include php.conf;
}
include php.conf;

I personally find the Nginx wiki very readable and very informative. It’s worth taking the 10 minutes to work out solutions from there rather than copy-pasting from blogs. There are some great convention and pitfall articles in there as well. Hope to get to a post outlining our configuration based on some time spent at the wiki.

NGINX 404 errors

Somewhere out in the wild there’s an NGINX config file that a lot of people are copying (ourselves included though we don’t remember where we found it!), and it’s likely causing some hard to track down 404 errors.

Fortunately we saw it crop up on one of our first NGINX dev boxes.

Within the location block, it’s pretty common to setup another location block that automatically disables logging and sets 30 day expires headers on static assets.  This is best handled like so:

1
2
3
4
location ~* .(jpg|jpeg|gif|css|png|js|ico|eot|svg|ttf|woff)$ {
    access_log        off;
    expires           30d;
}

The problem is that we originally had hastily grabbed this location block from a tutorial

1
2
3
4
location ~* ^.+(jpg|jpeg|gif|css|png|js|ico|eot|svg|ttf|woff)$ {
    access_log        off;
    expires           30d;
}

The difference is subtle, but the latter codeblock improperly matches for ANY url ending in those strings. We have a number of hashed URLs to validate certain requests, and since they are randomly generated, we occasionally saw 404 errors from these requests. It wasn’t until we noticed that one of the random strings ended in “js” that we thought to look at this block.