HTTPS, Let's Encrypt y Cloudflare - perfeccion-ar/infraestructura-clasica-y-avanzada GitHub Wiki

Artículos relacionados

• https://github.com/perfeccion-ar/infraestructura-clasica-y-avanzada/wiki/LXD,-Virtualhosts-y-Docker
• https://github.com/perfeccion-ar/infraestructura-clasica-y-avanzada/wiki/Nginx-Proxy-Manager-GUI-con-servicios-bajo-Docker
• https://github.com/perfeccion-ar/infraestructura-clasica-y-avanzada/wiki/P%C3%A1gina-propia-en-Wordpress,-con-Apache2,-MySQL,-PHP-y-phpMyAdmin-(Stack-LAMP)

En los tres artículos implementamos un servidor web, en el puerto 80, configuramos un virtualhost con algún dominio, servimos una página web o reenviamos a un container (LXD o Docker) que termina por entregar el resto de la información.

Sin embargo, un problema subyace: estamos sirviendo por el puerto 80 solo http. Esto es un problema, porque navegadores modernos advertirán a los usuarios que nuestro tráfico no es confiable. Y nuestros sitios no serán SEO compatible, con lo cual Google nos penalizará en los resultados.

Hay varias formas de entregar información cifrada de tipo SSL por el puerto 443 (https). Pero para ello necesitamos certificados digitales firmados.

Normalmente los certificados SSL se pagan. Se adquieren por un tiempo en distintos proveedores, y se renuevan. Toda empresa sería los contrata así. No son baratos y hay que desconfiar de las ofertas, porque pueden variar de año a año. Son más caros cuando se los contrata con wildcards (*), es decir, que cubran *.midominio.com

La configuración es bastante sencilla: tras pagarlos, se bajan, y se los menciona en un segundo apartado referido a "que hacer" cuando la petición llega por 443.

La siguiente configuración se ejemplifica con Apache, aunque con Nginx es muy similar. Esencialmente, todo el tráfico al puerto 80, se lo reenvía (Redirect) a https. Luego la sección 443 (https) detalla donde están los archivos con los certificados, y termina de indicar donde están los archivos de la página web (/var/www/...)

<VirtualHost *:80>
       ServerName sucursalvirtual.ticonline.com.ar
       ServerAdmin [email protected]
       Redirect permanent / https://sucursalvirtual.ticonline.com.ar/
</VirtualHost>

<VirtualHost *:443>
       ServerName sucursalvirtual.ticonline.com.ar
       DocumentRoot /var/www/html/sucursalvirtual-tic/public/

       <Directory "/var/www/html/sucursalvirtual-tic/public/">
               Options Indexes FollowSymLinks MultiViews
               AllowOverride All
               Order allow,deny
               allow from all
               Options -Indexes
       </Directory>

       CustomLog /var/log/apache2/sucursalvirtual.ticonline.com.ar-access.log combined
       ErrorLog /var/log/apache2/sucursalvirtual.ticonline.com.ar-error.log
       LogLevel warn


       SSLEngine On

       # Ver deploy en https://help.rapidsslonline.com/support/solutions/articles/22000218775-apache-open-ssl
       # Probar con apachectl configtest

       SSLCertificateFile /etc/ssl/ticonline/ticonline.com.ar.crt
       SSLCertificateKeyFile /etc/ssl/ticonline/ticonline.com.ar.key

       # Normalmente no necesario:
       SSLCertificateChainFile /etc/ssl/ticonline/intermedia.cer

</VirtualHost>

En el ejemplo anterior, los certificados fueron adquiridos a la empresa RapidSSL. Sin embargo, la autoridad de certificación LetsEncrypt nos puede dar certificados gratis. No es lo más honorable para una empresa seria (por ejemplo, que se dedique a las finanzas), pero funcionan bien.

Tras adquirirlos, el cambio que se realiza en las líneas anteriores serían las siguientes

    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/sucursalvirtual.ticonline.com.ar/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/sucursalvirtual.ticonline.com.ar/privkey.pem

Sin embargo, raramente los administradores de sistema configuran a mano el virtualhost de esta forma. Ello, porque los certificados Let's Encrypt se debe rotar cada tres meses, y en ese caso, el nombre del archivo cambia.

Normalmente se utiliza un programa accesorio llamado certbot, que se encarga de dar el alta, y actualizar los certificados automáticamente. Incluso, certbot nos ayuda a configurar nuestro archivo Virtualhost.

La instalación del certbot es bastante sencilla. En su sitio se provee los pasos necesarios para todos los ambientes: https://certbot.eff.org/instructions

Por ejemplo, en un Ubuntu, se corre la instalación, y luego se corre

sudo certbot --apache

Este comando descubrirá todos los virtualhost que tengamos en /etc/apache2/sites-available/ y nos agregará las líneas necesarias. Al finalizar, recomendará poner en un crontab una tarea que los renueve (si hace falta) todos los días, al estilo

30 02 * * * /usr/bin/certbot certonly --force-renew --apache -d escueladeasadores.com.ar -d www.escueladeasadores.com.ar -d mendozahostel.com.ar -d eim.esc.edu.ar -d site.eim.esc.edu.ar

Este comando ajustará las líneas anteriores, si hace falta.

Cuando se usa Docker, a veces conviene usar algunos proyectos automatizados que ya traen al certbot. Los más conocidos son JWilder Proxy, y Nginx-Proxy Manager.

De este último tenemos documentación, e incluso un video, en https://github.com/perfeccion-ar/infraestructura-clasica-y-avanzada/wiki/Nginx-Proxy-Manager-GUI-con-servicios-bajo-Docker

Cloudflare también puede proveernos certificados gratis. Sin embargo, con esta compañía normalmente se aprovecha su servicio gratuito de Proxy y de defensa contra ataques DoS. Esencialmente, dejamos que Cloudflare maneje el DNS, que se ponga adelante en las peticiones http 80, que entregue certificado y gestione el https 443, que haga de caché, y que solo vaya a nuestro servidor (en adelante "endpoint") solo cuando haga falta.

A continuación se muestran las pantallas relevantes que se ajustan para un escenario simple como el descrito:

1. Damos de alta un dominio en Cloudflare. Por ejemplo "capacitacionesamerica.com.ar"
2. Vamos al menú Registros
3. Tomamos nota de los servidores NS que nos han asignado. Esos DNS los ponemos en el registrar donde hemos reservado el diminio. En el caso de dominios .ar, se hace en www.nic.ar. Es decir, los "delegamos".
4. Esperamos la propagación de los DNS y agregamos tantos registros A como archivos virtualhosts tengamos esperando en nuestro web server.

5, 6, y 7. Ejemplos, tanto el dominio capacitacionesamerica.com.ar, como los subdominios cursos.capacitacionesamerica.com.ar y www.capacitacionesamerica.com.ar, van todos a la ip (registro A) 37.27.49.225, donde tenemos nuestro server.

Si presta atención, verá que hemos activado el modo proxy.

Vamos ahora al SSL. En esta pantalla puede ver que hemos activado el modo "Flexible". La descripción es correcta: "Habilitar el cifrado solo entre sus visitantes y Cloudflare. Esto evitará las advertencias de seguridad del navegador, pero todas las conexiones entre Cloudflare y su origen se realizan a través de HTTP."

Podemos agregar una capa extra de seguridad, bajando y configurando los certificados de Cloudflare también en nuestro servidor web, de modo que también el tráfico interno con entre nuestro web server y Cloudflare quede cifrado. Pero a menos que sea necesario para cumplir alguna regulación muy estricta, solo generará un overhead innecesario en nuestro servidor.

Si todo anda bien, ahora haciendo click en el candado, podremos ver como https funciona correctamente: