… que hay que implementar cuando se quiere utilizar el proyecto para obtener certificados digitales para nuestros servicios.

Hasta ahora estaba utilizando el cliente oficial del proyecto Let’s Encrypt pero estoy cambiando hacia una versión más ligera, basada en Bash, llamada letsencrypt.sh. Hace menos cosas por ti que el cliente oficial pero tiene una síntaxis más sencilla, y aunque ahora tengo que ser consciente de cosas como el protocolo ACME, me proporciona mayor control en su instalación.

El protocolo ACME se utiliza cuando se solicita o se renueva un certificado digital y sirve para verificar que el dominio te pertenece. Existen dos mecanismos para ello, siendo el primero -y el más empleado por los clientes actuales- el que utiliza el protocolo HTTP. Consiste en solicitar a tu servidor un archivo concreto bajo la ruta

.well-known/acme-challenge

del dominio para el que se crea o renueva el certificado. Parece que también es posible servir dicho archivo bajo conexiones seguras (SSL) pero se recomienda que el acceso vía HTTP exista y esté disponible.

La otra verificación estriba en el DNS y aún no tengo información suficiente como para hacerla bien, pero es más cómoda porque no se debe tocar nada en el servido.

En el caso de tener varios dominios se puede definir en el servidor web de un acceso global a dicha localización y que éste se configure en todos los servidores virtuales.

En mi caso estoy empleando la versión 2.4 de Apache bajo Debian por lo que creo un archivo en

/etc/apache2/conf-available/letsencrypt.conf

con el siguiente contenido:

Alias /.well-known/acme-challenge /var/www/letsencrypt

<Directory /var/www/letsencrypt>
        Options None
        AllowOverride None
        Require all granted
</Directory>

Además de crear el directorio

/var/www/letsencrypt

con los permisos habituales del usuario

www-data 

con

$ sudo install -d -o www-data -g www-data -m 0755 /var/www/letsencrypt

Tras reiniciar el servidor Apache para que lea la nueva configuración podemos efectuar una prueba sencilla para ver si funciona con todos los dominios empleando

curl 

y creando un archivo simple de nombre arbitrario.

$ sudo a2enconf letsencrypt
Enabling conf letsencrypt.
To activate the new configuration, you need to run:
  service apache2 reload
$ sudo service apache2 reload 
$ sudo date > /var/www/letsencrypt/flag
$ sudo curl --insecure https://astillas.net/.well-known/acme-challenge/flag
jue abr  7 13:32:20 CEST 2016
$ sudo rm /var/www/letsencrypt/flag

Una vez que ésto está funcionando podemos pasar a la siguiente fase de la que hablaré en otro artículo.

Actualización

He comprobado que el mecanismo falla en varias situaciones. Casi todos mis servidores virtuales fuerzan una redirección hacia la versión segura empleando la siguiente construcción

<VirtualHost *:80>
        ServerName  git.astillas.net

        # redirect to https when available (thanks omen@descolada.dartmouth.edu)
        RewriteEngine on
        RewriteCond %{HTTPS} !^on$ [NC]
        RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI}  [L]
</VirtualHost>

Y suele funcionar correctamente una vez allí excepto en el caso de emplear el módulo mod_proxy como frontal para un servidor interno. La solución encontrada en los foros de serverfault era añadir como condición para la redirección que el URL no fuese el del protocolo ACME:

 RewriteEngine on
 RewriteCond %{HTTPS} !^on$ [NC]
 RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
 RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI}  [L]