Multiple SSL certificates on the same IP with nginx (and others)

Long story short: you can host multiple domains or sites and serve different SSL certificates on the same IP address.

Now, let's develop this long story:

1) You need nginx compiled with SNI support (and the SSL module with --with-http_ssl_module). More info on this subject here: http://en.wikipedia.org/wiki/Server_Name_Indication.
2) You need a version of OpenSSL greater than 0.9.8f (compiled with the --enable-tlsext option) or 0.9.8j which has it enabled by default.

Here you have different outputs with debian etch which has an older version of OpenSSL than 0.9.8f and debian squeeze which has 0.9.8o (at the moment)

root@etch# ./nginx -V
nginx version: nginx/0.7.65
built by gcc 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
TLS SNI support disabled

root@squeeze# ./nginx -V
nginx: nginx version: nginx/1.0.2
nginx: built by gcc 4.4.5 (Debian 4.4.5-8)
nginx: TLS SNI support enabled

The SSL handshake between the client and server is made before any HTTP data is transmitted, so the server has no way of knowing what certificate to serve, hence the default certificate is delivered.

To remedy this "problem" the TLSv1.1 Server Name Indication extension (SNI, RFC3546) was created, which allows the client to send the info about what host the client is interested in, and this results in the server knowing what certificate to deliver, and voila, we can host multiple SSL sites with their certificates on the same IP address.

Don't take my word for this, it's in the nginx documentation here:

http://nginx.org/en/docs/http/configuring_https_servers.html

And you can test your client (the browser most of the times) for SNI support at this URL:

https://alice.sni.velox.ch/

Of course, as usual, there's a catch. And a big one.

No user with Windows XP on any service pack (yes, even SP3 fully updated) using any version of IE or Safari will be able to use your new and shiny SNI server config because there's simply no support for it. You can, however, use Opera, Chrome or Firefox on Windows XP which has SNI support built in but as you can see, leaving out all IE users on Windows XP it's a significant amount of users to implement this in production and rely on it.

You have SNI support on IE (and Safari) starting on Vista and of course in Windows 7.

Another solution I've seen some people is implementing is using the subjectAltName field in the SSL certificate to add more domains, but this solution is limited because you can't put 5000 domains in there as the field has a limited length (don't know which the limit is btw), so I don't see this as a practical solution at all (to host 5000 domains, maybe for 2 or 3).

The only way of having everyone happy is to use separate IP's for every domain/certificate you host. Of course, I hate this solution, but it's the only one that works 100% of the times.

Sucks right ?

Cheers

PHP exec() and system() tied to /bin/sh on debian squeeze

In the past I relied on the exec() and system() functions to run some commands in PHP.
It came to a surprise when I updated my distro from etch to squeeze that the /bin/sh symlink was not pointing to bash anymore, but to dash which is a POSIX compliant shell and who knows what else (technical blah-blah).

Some commands I ran through exec() and system() failed and the reason is that bash doesn't share the same syntax and builtins as dash.

I was told on some IRC channels that reverting to bash should not break anything, just make slower the execution of startup scripts and the like (anyway I'll not die by waiting 2 seconds more for the box to be ready).

Just do a:

dpkg-reconfigure dash

and follow instructions, afterwards your /bin/sh symlink will point again to bash and your PHP exec() and system() calls will behave as before.

Enable and disable root password (Ubuntu/Debian and others)

Some say that using root all the time is wrong. I never had a problem because of that, but well, the distros have adapted to not allowing a root login by default (well, this is not exactly true but it's the default behavior).

So, you can enable again your root login by doing a:

sudo passwd root

And disable it again with a:

sudo passwd -l root

which locks the root account.

And if you have the root account locked, you can become root by typing:

sudo -i

Stupid, I know, but it's the better way (I was found myself doing a sudo bash and that is more or less, wrong).

Cheers