HTTPS and the Red Padlock

I had some troubles when I switched over to nginx

I decided to switch over to using NGINX. The main reason was curiosity, but another reason was because I had already replaced the NodeJS backend with clojure (in order to learn the language and its packages).

I had previously used a node proxy to kind of reverse proxy for the internal node app that ran the back end. One important feature I had never gotten around to was redirecting http:// to https:// I knew NGINX could do that so I decided, what the heck.

After getting it set up with a basic configuration like so:

server {

    listen 443;

    ssl_certificate           /etc/nginx/www_4d4ms_com.crt;
    ssl_certificate_key       /etc/nginx/www_4d4ms_com.key;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

After doing some basic testing, I called it a night thinking all was well.

The next day while checking on the site I discovered that chrome was complaining about an invalid certificated

After some investigation, I discovered that with the node proxy server, I was specifying each certificate in the chain explicitly:

var proxy = httpProxy.createProxyServer(),
options = {
    key: fs.readFileSync('www_4d4ms_com.key'),
    cert: fs.readFileSync('www_4d4ms_com.crt'),
    ca: [fs.readFileSync('COMODORSADomainValidationSecureServerCA.crt'),

But in nginx (at least the way I had done it) I was only specifying my own certificate and not the rest of the chain. It turns out you can cat the certificates together and specify that bundle.

$ cat www_4d4ms_com.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > 4d4ms-ssl-bundle.crt

    ssl_certificate           /etc/nginx/4d4ms-ssl-bundle.crt;
    ssl_certificate_key       /etc/nginx/www_4d4ms_com.key;

Afterwards you can evaluate your setup using ssllabs

One additional thing that I haven't addressed yet is mixed content warning. I serve media via [Amazon Cloudfront]() which I haven't bothered to figure out ssl for. You'll see a warning on any of my pages that serve media that:

"Your connection to this site is private, but someone on the network might be able to change the look of the page."

Update 4/14/2017 The text might now read:

"Attackers might be able to see the images you’re looking at on this site and trick you by modifying them."

But that is a task for another night (and another blog post)