Consideraciones antes de usar certificados SSL en SHA-256

Nota: A partir del mes de noviembre del 2014 y la publicación de Chrome 39, este navegador generará una página de error al momento de tratar con un certificado SSL en SHA-1, eliminando rápidamente la posibilidad de usar de manera seria un certificado que sea inferior a SHA-256. Por lo tanto, el artículo siguiente, redactado hacen unos meses, quedaría bastante inútil.

Aunque muchas autoridades de certificación anunciaron que dentro de los próximos meses (algunos al inicio del 2015, otros al inicio del 2016) iban a rechazar los certificados en SHA-1, es importante tomar conciencia que no todo está listo para ofrecer un sitio web HTTPS con certificado SSL en SHA-1, y es que Windows XP (el cual fue abandonado por su creadora Microsoft, el 8 de Abril del 2014) no soporta SHA-2 (esto incluye a SHA-256), a menos que esté actualizado con el Service Pack 3.

Y esto, en América Latina (y probablemente en otras partes del mundo) sigue siendo un problema importante, dado que el uso de Windows XP, en Abril 2014, sigue siendo del 17% de todos los sistemas operativos con un navegador de escritorio. De estos, es difícil decir quienes no actualizaron al Service Pack 3, pero conociendo la conectividad a internet promedia, sería curioso que supere los 50%.

Probablemente, entonces, tengamos todavía algo de 8.5% de usuarios con un sistema operativo (independiente del navegador) que no soporte SHA-2.

Por ello, cuidado al momento de generar un nuevo certificado SSL. Piensen a hacer el balance correcto entre seguridad e inclusión.

Cuidado también al momento de revisar una computadora Windows XP con un problema de acceso a un sitio con SHA-2: no necesariamente sea el mismo problema. Puede que tenga el SP3, y entonces? Pues entonces es muy probable que el problema esté en el Firewall. En particular, últimamente observamos que una opción que tenía un título del tipo “Activar la verificación sistemática de certificados SSL”. Al desactivar esta opción, volvió a funcionar.

SSL certificates for multiple virtual hosts: problem on IE for Windows XP

Using a single server for multiple virtual hosts is something that comes naturally nowadays for any web server sysadmin.

Using SSL certificates is also common (particularly so since the infamous Blacksheep extension for Firefox as published a few years back).

However, the mixing of SSL and virtual hosts might not be as easy as you might think. At least for some of your users…

Some browsers in some old (but better than more recent, some might say) proprietary operating systems are resisting the trend.

Erick, on our team, investigated a strange side effect of enabling a second SSL certificate on one of our multiple-virtual-hosts servers recently. It so happens that, when enabling the second certificate, Internet Explorer on Windows XP starts shouting that the site is not safe, with a huge warning similar to the one you get with self-signed certificates (the screenshot is in Spanish here, sorry, but you get the idea).

SSL warning in IE under XP

You can read more about the problem with having several SSL certificates on a single server, and the solution thereof on the Apache Foundation’s wiki, but to be short, a fix has been developed under the name of SNI, as an extension to SSL. Most browsers support that extension but, quite unsurprisingly, Internet Explorer on Windows XP doesn’t.

Browsers support for SNI

So, if you have any Internet Explorer user under XP, well, let’s say that you will probably have to deploy a lot of efforts to give them security on your website.

From the top of my mind, you could use a special redirect just for this case (based on the User Agent, I suppose) so that these users can use your site without SSL, or to give them a first page of warning before you send them to the site, that will alert them that it is supposedly not secure, and where you could tell them how to accept the certificate (because honestly, without reading the page in detail, they will just freak out).

Of course, yet another solution is to make sure that all sites that use SSL are on different servers, but that’s probably just not an option.

But seriously… Internet Explorer, SERIOUSLY ???

Ref: Minimum RSA public key lengths

Just a reference to an interesting article on SSL and guidelines for the length of public keys in RSA before and after December 2013:

http://news.netcraft.com/archives/2012/09/10/minimum-rsa-public-key-lengths-guidelines-or-rules.html

Munin nginx_status fails on HTTPS

This must appear in one opportunity in 1000, but it happened to me, so I bet it might have just happened to you…

Munin is great, Nginx is great, and SSL is great, but when you mix all of them together, you might get some frustrating behaviour.

If you don’t know it already, you can test the results of a Munin plugin on Debian-based systems with the command

sudo munin-run [plugin]

For example, if your nginx_status graph in the Munin web interface is empty, you can try

sudo munin-run nginx_status

The name of the plugin will auto-complete with the TAB key, with any plugin present in /etc/munin/plugins/

In my case, the command gave the following result:

total.value U
reading.value U
writing.value U
waiting.value U

“U” in the result above is the equivalent of “Undefined” or “Unavailable”. Translation: the plugin can’t get its data.

If you’ve got Munin running only for HTTPS (the rest is handled by Varnish, for example), then the first thing is to make sure that the plugin is effectively querying an HTTPS URL managed by Munin, and that the URL, even if tested on the same machine, is the one that matches your SSL certificate. For example: https://www.example.com/nginx_status if your domain is example.com and you have the certificate for that domain. Make sure you have a block like this in your /etc/munin/plugin-conf.d/munin-node file (you can add it at the end):

[nginx*]
env.url https://www.example.com/nginx_status

Then reload your munin configuration with

sudo /etc/init.d/munin-node restart

Second, you want to make sure the URL nginx_status is actually managed by Nginx. To do this, check the section “location / { … }” in your nginx config file (/etc/nginx/sites-available/default, for example) and make sure there is another location block like this one:

location /nginx_status {
  stub_status on;

  access_log off;

  allow 127.0.0.1;

  deny all;
}

(change – or copy over – the “allow” property if needed).
In particular, it happens that you need to put the public IP in an “allow” tag in order for munin to work.
This will ensure the URL https://www.example.com/nginx_status actually answers something like this:

Active connections: 1
server accepts handled requests
8723 8723 10497
Reading: 0 Writing: 1 Waiting: 0

… Which you can test with lynx or links2 from the same server: lynx https://www.example.com/nginx_status

Now (we’re not finished yet) you might have all this running, and still an empty munin graph.
This is the most tricky part, because it’s difficult to get to that conclusion without hacking the code a little bit.

Without you noticing, the munin plugin might now be failing because you don’t have the IO::Socket::SSL library installed on your computer. I only realized that by adding a die() call in the Perl script of the plugin when getting the answer from Nginx, to see that it was still in encrypted form and contained a message saying I should install this module in order to make SSL readable by Munin.
Well, once you know this, it’s fairly easy to do:

sudo apt-get install libio-socket-ssl-perl

sudo /etc/init.d/munin-node restart

You can try it out with munin-run:

$ sudo munin-run nginx_status
total.value 1
reading.value 0
writing.value 1
waiting.value 0

Done! If this helped you, please share it.

Renew expired self-signed SSL certificate

For some reason, it might be very difficult to find information on how to renew a self-signed certificate. This is a nice (and short) explanation: http://linux.togaware.com/survivor/Renew_SSL.html.

Please note that a .pem file is in fact (as you can guess from the small guide) a combined .key and .crt.

In short and only for the purpose of not loosing this reference (as has happened many times before with sites referenced on this blog), here is the procedure (just adapt to your case, i.e. replace togaware.com and all locality details with yours). The “Common name” requested by the openssl command is the domain name. Leave top level domain name without prefix for multiple domains certificates. Note that the filenames (togaware.com.key, etc) do not have any importance apart that the extension (.pem, .key, .crt) might be helpful later on when wondering which file does what:

  # cd /etc/apache2/ssl
  # openssl genrsa -out togaware.com.key 1024
  # chmod 600 togaware.com.key
  # openssl req -new -key togaware.com.key -out togaware.com.csr
    AU
    ACT
    Canberra
    Togaware
    Data Mining
    Kayon Toga
    Kayon.Toga@togaware.com
    (no challenge password)
  # openssl x509 -req -days 365 -in togaware.com.csr \
            -signkey togaware.com.key -out togaware.com.crt
  # mv apache.pem apache.pem.old
  # cp togaware.com.key apache.pem
  # cat togaware.com.crt >> apache.pem
  # chmod 600 apache.pem
  # service apache2 restart

If you are only replacing an old certificate, make sure you save the old file and generate the new files using the previous names. If you have several virtual hosts, this will save you a whole lot of time.

 

Easily avoid using your password in an SSH connexion: ssh-copy-id

On Linux systems, there used to be a mildly complicated but tedious way to allow you to SSH another computer using your public key, which involved finding and copying your public key on the other host, then connecting to the host and putting this key into ~/.ssh/authorized_keys.

Now there is a much simpler way to do that… Just launch the following command (with your own data), enter your password, and that’s it!

ssh-copy-id  yourusername@remote.host.address

I love administrative simplification!

Creating multi-domain SSL certificates

The post is in French, but is certainly worth the effort of translation for people looking on how to do this:
http://howto.landure.fr/gnu-linux/debian-4-0-etch/creer-un-certificat-ssl-multi-domaines

If enough people ask for a good translation, I’ll consider doing that here.

How to configure HTTPS on Apache 2

Introduction

Setting up several VirtualHost’s on an Apache2 server is easy.

Setting up several VirtualHost’s on an Apache 2 server, some of them using SSL (HTTPS) is considerably less easy. The main problem is the documentation, not really easy to find, with examples of such configurations.

Here, we will intend to give all the steps to get there, remaining at a minimal level of complexity.

If you want more details, I suggest you have a look at this nice article by Artur Maj. This is where most of the inspiration comes from for the current article, together with real tests on a Debian Etch server. Thanks to his article, We will allow ourselves to skip the HTTPS, SSL and TLS definitions and prerequisites. We will consider that you have already installed SSL on your server installation, but haven’t enabled it with VirtualHost’s just yet.

Generating a key

To get things started, you will need a key. This key will be used by the VirtualHost you will define, only if you ask it to.
To generate the key, create an ssl directory in your /etc/apache2/ directory (on a Debian Etch, that is)
Then move inside that directory (cd ssl) and do the following:

mkdir crt
mkdir key
openssl req -new -x509 -days 365 -keyout key/vhost1.key -out crt/vhost1.crt -nodes -subj  ‘/O=VirtualHost Website Company name/OU=Virtual Host Website department/CN=www.virtualhostdomain.com’

This operation will create two files, crt/vhost1.crt and key/vhost1.key, that you will use in your VirtualHost definition to enable SSL encryption using that key.

Changing the VirtualHost config

Now move on to your Apache sites configuration. In most cases, you should have something like an /etc/apache2/sites-available/ and an /etc/apache2/sites-enabled directory. As sites-enabled should only contain links to sites-available, we are only interested in sites-available. So go there.

Now you should have one default file there, as well as one file that defines the configuration of the VirtualHost you would like to setup to use HTTPS.

Open the default config file. It should start with something like

NameVirtualHost *:80

or

NameVirtualHost *

Either way, change it to:

NameVirtualHost *:80
NameVirtualHost *:443

Now you have just told your webserver to accept both requests on port 443 and 80. *if* you restart your webserver at this point, you should get a warning message saying that no host is using the port 443. This is normal for me: I never really got around how to configure the whole thing correctly to avoid it throwing warnings at reload, but it is definitely not a big problem. Now let’s proceed to the config of the VirtualHost itself.

Open your VirtualHost config file. You should have something along the lines of:

<VirtualHost *>
ServerAdmin webmaster@yourdomain.com
DocumentRoot /var/www/vhost1
ServerName vhost1.yourdomain.com
DirectoryIndex index.php
ErrorLog /var/log/apache2/vhost1-error.log
CustomLog /var/log/apache2/vhost1-access.log combined
<Location />
Options Indexes FollowSymLinks
AllowOverride All
</Location>
…
</VirtualHost>

Together with the new config, this should look like that:

<VirtualHost *:80>
ServerAdmin webmaster@yourdomain.com
DocumentRoot /var/www/vhost1
ServerName vhost1.yourdomain.com
DirectoryIndex index.php
ErrorLog /var/log/apache2/vhost1-error.log
<Location />
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R]
</Location>
</VirtualHost>
<VirtualHost *:443>
ServerAdmin webmaster@yourdomain.com
DocumentRoot /var/www/vhost1
ServerName vhost1.yourdomain.com
DirectoryIndex index.php
ErrorLog /var/log/apache2/vhost1-error.log
CustomLog /var/log/apache2/vhost1-access.log combined
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/crt/vhost1.crt
SSLCertificateKeyFile /etc/apache2/ssl/key/vhost1.key
<Location />
SSLRequireSSL On
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +StdEnvVars +StrictRequire
</Location>
…
</VirtualHost>

Now if you restart your web server, you should be able to make it work straight away.

Note that if you do that on a fresh server, you might receive a “Configtest failed” error message. This is most likely to be due to the Rewrite or SSL modules not being enabled. Just enable them:

sudo a2enmod rewrite

sudo a2enmod ssl

sudo /etc/init.d/apache2 restart

 

2012-10-15 edit: as indicated by Gerard H. Pille in the comments to this article, Apache needs to be configured to answer on port 443 as well. This is generally a default setting in Debian/Ubuntu, but if you need to enable it, just locate the “Listen 80” in your Apache configuration directory and add a “Listen 443” on the next line. Restart Apache, and you should be done with it.