Posts Tagged ‘ssl’

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

September 14, 2013 3 comments

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

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

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 ???

Categories: English, security, Techie Tags: , , , ,

Ref: Minimum RSA public key lengths

September 18, 2012 Leave a comment

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

Categories: English, Uncategorized Tags: ,

Munin nginx_status fails on HTTPS

September 3, 2012 3 comments

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: if your domain is 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):


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;


  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 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

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

December 27, 2011 Leave a comment

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:

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 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 (, 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 1024
  # chmod 600
  # openssl req -new -key -out
    Data Mining
    Kayon Toga
    (no challenge password)
  # openssl x509 -req -days 365 -in \
            -signkey -out
  # mv apache.pem apache.pem.old
  # cp apache.pem
  # cat >> 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.


Categories: English, Techie Tags: , ,

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!


I love administrative simplification!

Categories: English, Tech Crunch Tags: , ,

Creating multi-domain SSL certificates

February 10, 2009 2 comments

The post is in French, but is certainly worth the effort of translation for people looking on how to do this:

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

%d bloggers like this: