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

Cursos presenciales de configuración de Apache, Lima, Perú

Frente a la maduración progresiva de los servicios digitales orientados a consumo masivo, por internet, de servicios brindados por empresas peruanas, hemos detectado un gran incremento, durante los últimos meses, del interés hacia la optimización de configuraciones web para la disminución del uso de recursos y la entrega rápida y a menor costo de productos o servicios a los consumidores, ya sea a través de dispositivos móviles (menor contenido, más necesidad de velocidad) como de dispositivos clásicos (mayor contenido sobre líneas más rápidas).

Por ello, BeezNest, consultora con especialización en optimización de sitios web y desarrollo de soluciones e-learning en internet, decidió plantear una propuesta de cursos adaptada a la demanda creciente, empezando por un curso sobre el elemento más básico y esencial de la optimización de servicios web: el servidor web.

Este mes de Marzo 2013, estamos planificando una serie de mini-talleres de 4 horas para aprender en más detalles lo que es Apache 2.2 y como configurarlo bien.

Cada curso tendrá un costo de S/.100 (US$35) por persona, y el programa está indicado a continuación. Para iniciar el curso, se requiere de un mínimo de 10 participantes.

El último curso será seguido de un examen (opcional) de 20 preguntas (de un valor de S/.100 también) que llevará a la certificación (o no) de las personas que han tomado el curso por parte del grupo BeezNest. También entregará una constancia a los participantes del conjunto completo de cursos (con la excepción del curso 1 que es opcional). NO se entregarán constancias para participaciones parciales (que no hayan asistido a todos los cursos). Los alumnos tendrán acceso al material del curso en línea en nuestro portal Chamilo de cursos por un plazo de un año.

Las personas que pasen (con éxito) el examen de certificación serán publicadas, con sus detalles de contacto, en la página correspondiente del sitio web de BeezNest, la cual será promocionada por el equipo de BeezNest frente a cualquier consulta por técnicos con habilidades de cofiguración de Apache.

Ciertos (pocos) elementos del curso usan ejemplos de PHP, pero serán fácilmente adaptables a otros lenguajes.

Curso 1: Introducción a la noción de servidores web (4h, S/.100)

• Que es un servidor web?
• Que servidores web existen en la actualidad?
• Que son los VirtualHosts y como usarlos?
• Que es Apache y como configurarlo de forma básica?

Curso 2: Configuración básica de Apache (4h, S/.100)

• La configuración por defecto de Apache: como modificarla
• Access y Error logs: formatos por defecto y custom-made
• Como declarar Virtual Hosts de la manera correcta
• Directiva <Directory>
• Directivas de configuración de PHP (mod_php)

Curso 3: MPMs, Rewrite y Aliases: como manipular y modificar las pedidas usuarios (4h, S/.100)

• Que son los MPMs y como afectan el rendimiento de mi sitio? MPM-event, MPM-prefork, MPM-worker
• ModRewrite: Redirigir y generar URLs amigables: introducción
• ModAlias: Incluir carpetas externas dentro de un sitio

Curso 4: Optimización de Apache: Haz que tu sitio vuela! (parte 1) (4h, S/.100)

• Entender los tipos de datos: medios estáticos, medios dinámicos y páginas dinámicas
• Entender el flujo de datos. HTTP, HTML, AJAX y PHP
• Sprites y agregación CSS/JS: Entender el peso de muchos archivos

Curso 5: Optimización de Apache: Haz que tu sitio vuela! (parte 2) (4h, S/.100)

• Content Delivery Networks (CDN): multiplicar las pedidas simultáneas para acelerar su sitio
• ModRPAF: Usar Apache con un reverse proxy
• ModExpires: aprovechar del caché del navegador del usuario para reducir el tráfico
• ModHeaders: cambiar las cabeceras de los archivos para customizaciones más finas

Para inscribirse, escribir a ventas@beeznest.com, con asunto: “Curso Apache Marzo 2013”.

Sobre BeezNest

BeezNest es un grupo empresarial fundado en el 2002 y presente en Europa (sede Bélgica) y América Latina (sede Perú) con especialización en soluciones e-learning y optimización de infraestructura. BeezNest es la empresa atrás del software libre Chamilo LMS, que cuenta con 3 millones de usuarios libres a través del mundo, que usan este sistema para aumentar la disponibilidad de recursos y servicios educativos de calidad. BeezNest también se encarga de optimizar grandes sitios web en infraestructuras dedicadas seguras, y vigilar parques de servidores contra ataques, sobrecargas y vulnerabilidades.

Contacto: info@beeznest.com

Apache Rewrite Cheatsheet

This is the life-saver cheatsheet you need if you’re ever going to want to understand complex rewrite rules like the ones generated by the Boost module in Drupal:

http://www.askapache.com/htaccess/mod_rewrite-variables-cheatsheet.html

In particular, in  RewriteRule .* – [S=5], the [S=5] rule means “skip the next 5 lines”. It can represent a considerable efficiency boost! Same thing can be said for [L] (last rule)

A set of nice examples is also available on the same site: http://www.askapache.com/htaccess/modrewrite-tips-tricks.html

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.

 

Debunking error (OS 10054) core_output_filter: writing data to the network

One of our customers has Apache logs (Xampp-based) full of this line:

[Tue Mar 02 16:21:41 2010] [info] [client 172.20.99.16] (OS 10054)Une connexion existante a dû être fermée par l’hôte distant.  : core_output_filter: writing data to the network

Sometimes (OS10053) is used as a variant, but the Apache error seems to be the same (core_output_filter: writing data to the network)

Apparently, the error is widespread and only occurs on Windows operating system (that’s where OS10054 error code comes from) and a few useful references for this are:

• http://httpd.apache.org/docs/2.0/faq/error.html#error.acceptex (recommending to set EnableSendfile Apache’s directive to Off)
• http://msdn.microsoft.com/en-us/library/ms740668%28v=VS.85%29.aspx (explaining the OS error is when a socket connection is not closed properly)
• the problem does not seem to come from the programming language nor the application itself, as you can guess through http://bugs.php.net/32176

The same application running on a Linux box does not generate any core_output_filter error.

Howto setup a 301 redirect

A few links to setup 301 Permanent Redirect (302 follows the same logic but is for Temporary Redirect) in Apache:

http://www.askdavetaylor.com/how_do_i_add_a_301_redirect_to_my_apache_httpdconf.html

http://www.webconfs.com/how-to-redirect-a-webpage.php

http://www.stepforth.com/resources/web-marketing-knowledgebase/non-www-redirect

One thing worth attention is the SEO-friendly redirection of non-www traffic to www. This means that if you load, say, http://example.com, you will be redirected to http://www.example.com. This avoids having two different sites registered in search engines, and allows for everybody to use the same unique URL to really use your service.

This is done through a series of little things. First off, you need to install and enable mod_rewrite. On a Debian/Ubuntu system, this would be done by

sudo a2enmod rewrite

Then you need to define both URLs in your virtual host. Something like this:

ServerName http://www.example.com

ServerAlias example.com

Then you need to make sure rewrite is enabled for this vhost, and define the rule to rewrite the url (taken from an example on canonical hostnames in the Apache documentation):

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.chamiluda\.org [NC]
RewriteRule ^/(.*) http://www.chamiluda.org/$1 [L,R]

This should be the right syntax to do it. The rest of your virtual host config can keep working as usual.

Como hacer para que tu URL funcione sin el www.

Simple. Por ejemplo en el caso de http://www.get-e-course.com, si quieres que http://get-e-course.com responda también, en la configuración de tu VirtualHost de Apache, agrega la línea:
ServerAlias get-e-course.com

y recarga la config de Apache:

sudo /etc/init.d/apache2/reload

Listo.

Esto siendo dicho, se considera mala práctica en términos de SEO usar dos rutas distintas, porque un indexador podría considerarlas como dos sitios distintos.
Por lo tanto, se recomienda usar el bloque siguiente *antes* del bloque <VirtualHost> normal:

<VirtualHost *:80>
ServerName get-e-course.com
RedirectMatch 301 (.*) http://www.get-e-course.com$1
</VirtualHost>


Webalizer installation and use on Debian

This is a simple guide on how to install Webalizer on a Debian system equipped with Apache. This should work for every version of every three elements (Debian, Apache and Webalizer) all together.

Webalizer is a statistics application which analyses the Apache logs (in /var/log/apache) and makes a graphical output in web format, using the libgd libraries.

Please note that we, at BeezNest, tend now to prefer AWStats to Webalizer because we feel it is better in every aspect.

To install Webalizer:

# apt-get install webalizer

The version tested asks for libgd2 to be installed. The configuration of Webalizer is pretty easy for a totally clean system. You are just asked two questions:

• where will Webalizer keep its data? (default: /var/www/webalizer)
• what title will the output page display? (defaults to something common)

When installed, a simple execution of webalizer will generate the Webalizer files. To make this generation automatic, you’ll need to add a cron script in /etc/cron.daily for example.

If for any reason your log files are not kind of /var/log/apache/access.log, the execution of Webalizer will stop before doing the export and you will get the following error:

• No valid records found!

you should edit /etc/webalizer.conf and change the corresponding settings to your log file, then try again to start webalizer.

Now you can access your stats by reaching the web server directory in which you asked Webalizer to store its data (default: http://www.yoursite.ext/webalizer/)

There are many additional statistical options you can set. To know about them, a very good start is to read the comments in /etc/webalizer.conf

This article was first written in November 2003 for
the BeezNest technical website (http://glasnost.beeznest.org/articles/95)

PHP

“PHP (recursive acronym for “PHP: Hypertext Preprocessor”) is a widely-used Open Source general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.” See www.php.net.

Using PHP is a matter of precision. ASP can be used to reach the same objectives but ASP has proven to us to be less interesting (see some of the reasons below, one of them being the licensing scheme). Where ASP mostly relies on Microsoft web servers technologies, PHP gives the customer the choice of the web server (we advise using Apache, though) and the OS his server will be running on (we advise using Debian Linux for security, stability and licensing reasons). Also, PHP gives the opportunity to anybody to participate in the language evolution by reporting problems (very rare situation), programming new functions librairies or object code or writing documentation on his use of the code (no licence problems).

PHP is cleanly structured and, although it doesn’t rely on object-oriented design, it is currently moving to a more OO structure and has been enabling the programmer to use OO syntax within his projects for a long time.

Within only a few years time, PHP has spread greatly and wisely amongst the world’s web servers as a reliable, fast moving and strong solution (see Netcraft or Zend for more information on PHP’s worldwide use).

Also, as PHP is a free redistributable technology, more and more public IT schools are teaching PHP programmation instead of ASP. This means more PHP programmers will be ready to help soon, avoiding to be stuck with one programmer you can’t see anymore :-) But it also means PHP has a brilliant future and is probably going to spread a lot more in the upcoming years. This will avoid the Cobol problem of having a dead language to maintain with costly programmers.

PHP is widely used in our web developments because it enables a clear, easy to modify and secure development without the hassle of a licence or without knowledge prerequisites others than programming techniques and Web Development logic.

There is plenty of documentation available for free on the net and in plenty of books in many languages.

By developing with PHP, we ensure the customer that he won’t depend on us if he wants to change his code. We study the needs, help him get to the solution going and then leave him gently with a functional and easily modifiable set of scripts, with an offer, but no obligation, of asking us for additional developments or support.

This article was first written in November 2003 for
the BeezNest technical website (http://glasnost.beeznest.org/articles/92)

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.