Figuring out how to serve many SSL certificates, part 2.

I’ve been pretty happy over the last couple days with our A+ score at SSL Labs. I almost got discouraged this morning when it was discovered that LinkedIn wasn’t able to pull in the data from our HTTPS links properly when sharing articles.

Their bot, `LinkedInBot/1.0 (compatible; Mozilla/5.0; Jakarta Commons-HttpClient/3.1 +http://www.linkedin.com)`, uses an end of life HTTP client that happens to also be Java based. One of our warnings in the handshake simulation area was that clients using Java Runtime Environment 6u45 did not support 2048 DH params, something that we were using. I’m not entirely sure if LinkedIn has their JRE updated to 6u45, but I’m guessing that anything below that has the same issue.

I generated a new 1024 bit dhparams file to solve the immediate issue and reloaded nginx without changing any other configs. LinkedIn can now ingest our HTTPS links and we still have an A+ score. 🙂

Figuring out how to serve many SSL certificates, part 1.

In the process of figuring out how to configure SSL certificates for hundreds (maybe thousands) of domains in a single nginx configuration without a wildcard certificate, I decided it would be cool to use `server_name` as a variable in the nginx configuration:

`ssl_certificate /etc/nginx/ssl/$server_name.crt;`

Unfortunately, per this aptly named request on Server Fault—nginx use $server_name on ssl_certificate path—that’s not allowed.

Nginx docs explain it more:

Variables are evaluated in the run-time during the processing of each request, so they are rather costly compared to plain static configuration.

So with that, I’m going to have to generate a bunch of `server {}` blocks that point to the correct certificate and key files before including a common config. I can’t find any examples of this yet, so I’m still wondering if there’s a better way.

Clear nginx Cache in Vagrant

Fooled you. You think that cache is the problem, but it’s not.

Scenario 1… You installed Vagrant with VirtualBox on your local machine and have a sweet nginx setup going as your development environment. You made a few changes to a CSS file and the new style is not reflecting on the page. You try saving the file again in your text editor, no go. You look at the file on the server, it’s cool. You restart the nginx service, still no change. You restart the services for php5-fpm and memcached, maybe even mysql… no go.

Something has captured this file in cache and is not letting go!

Scenario 2… Same setup. You made a few changes to a JS file and the script doesn’t seem to be working. Must be a caching issue. You try saving the file again, look at the file on the server, restart nginx, restart everything. Finally look at the console in your browser and see some kind of random error.

Sooner or later, with one of these files, you open it up and see these:

�����������������

What the what? It’s an encoding issue? Not a caching issue? Or it’s a… wait, what?

Hopefully you haven’t spent too much time trying to figure this out before stumbling on a site like this one that tells you the only change necessary is a simple line in your nginx config file.

sendfile off;

Find the spot in your assorted nginx config files that says ‘sendfile on’ and change it to ‘sendfile off’.

Sendfile is used to ‘copy data between one file descriptor and another‘ and apparently has some real trouble when run in a virtual machine environment, or at least when run through Virtualbox. Turning this config off in nginx causes the static file to be served via a different method and your changes will be reflected immediately and without question – or black question mark diamond thing.

Hope that saves you a minute.

For further reading, consider those that have stumbled on the same problem before.

Or, even better – more detail about sendfile itself and other common nginx pitfalls: