martes, 25 de junio de 2019

Implementar Let's Encrypt en nuestro servidor

Let's Encrypt es un servicio que nos va a permitir disponer de SSL en nuestro servidor. Los certificados serán generados por Let's Encrypt, no serán propios de nuestra organización por ejemplo. Es ideal para pequeñas webs, pues es sencillo de implementar y de gestionar.


Lo que vamos a ver en este artículo es cómo implementar Let's Encrypt en nuestro servidor y además con una sopresa, no para un servidor Apache, sino para Nginx. No suele ser habitual en mí, como sabéis soy de Apache, pero como SysAdmin, a veces toca administrar entornos que no son de nuestro gusto del todo. So, Let's go.

Si queréis descargar y medio instalar Let's Encrypt en vuestro Debian 9 (y para Apache) podéis utilizar de guía este artículo. Una vez instalado, vamos a ver cómo lo gestionamos.

En primer lugar, es muy posible que si tenemos funcionando nuestro Apache o Nginx, tengamos que pararlo. Esto para nosotros es simple.

systemctl stop nginx (o Apache si utilizamos Apache).

Cuando tengamos el servicio detenido, podremos lanzar el certbot, que es nuestro "script" que nos va a instalar todo el tema de certificados.

certbot certonly -d dominio.com -d www.dominio.com

certonly será la opción que utilicemos cuando, por ejemplo, utilicemos Nginx, ya que Apache (tanto a favor de Apache) tiene su propio plugin ( --apache).

Cuando lo lancemos, por terminal nos pedirá en qué modo lo queremos instalar para conocer el modo de los renewal. Nos solicitará si lo queremos en modo webroot o standalone ¿Cómo lo sabemos? Pues imaginad que ya tenemos en ese servidor, otro dominio, por ejemplo porque entramos a una empresa nuevos y ya tienen su infraestructura montada y lo que se está haciendo es añadir un servidor web nuevo. Vamos a ver cómo se ha hecho en el pasado.

/etc/letsencrypt/renewal/dominio2.com.conf

Miramos en el archivo anterior, que equivale a otro dominio dentro del mismo servidor. Veremos, entre otras cosas, algo como esto:

[renewalparams]
authenticator = standalone
installer = None


Ese authenticator es el que nos da la clave. Vemos que el modo es standalone, por lo que ya tenemos la respuesta, seleccionamos nuestro modo.



Tras seleccionarlo, esperamos unos segundos y para saber que se ha hecho correctamente, solamente deberíamos mostrarnos por pantalla el siguiente mensaje.

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/dominio2.com/fullchain.pem. Your
   cert will expire on 2019-09-17. To obtain a new or tweaked version
   of this certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot
   renew"
- If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Ya tenemos los certificados, lo único que nos queda por hacer es decirle a Nginx dónde debe buscar para encontrar los certificados SSL.

cd /etc/nginx/sites-available
cp -pv default dominio.conf

Dentro de /etc/nginx/sites-available podemos copiar el archivo default y copiarlo a otro que haga referencia a nuestro nuevo dominio. Con esto tendremos una plantilla básica, por lo que solamente tendremos que retocar algunas cosas.

vim dominio.conf

ssl_certificate /etc/letsencrypt/live/dominio.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/dominio.com/privkey.pem;


Estas son las líneas, junto al servername que tendremos que modificar. Tendremos que indicarle a Nginx dónde va a poder encontrar los certificados. Por lo general están bajo /etc/letsencrypt/live y la carpeta con el nombre de nuestro dominio, de todas formas en el mensaje que nos devuelve el certbot ya nos alerta e informa sobre la ubicación de estos certificados.

cd ../sites-enabled
ln -s ../sites-available/dominio.conf dominio.conf

Y aquí está algo que tiene Apache y que Nginx no tiene. No es algo muy grande, pero facilita la vida. En Apache, tras toda esta configuración, solamente nos quedaría  hacer un a2ensite dominio.conf y nuestro sitio quedaría habilitado. En Nginx no, en Nginx tenemos que crear un enlace simbólico. No pasa nada porque estamos acostumbrados, pero son esos detalles (entre otros) por los que me decanto por Apache.

Cuando tengamos el enlace simbólico creado, solamente nos quedará levantar de nuevo el servicio de Nginx.

systemctl start nginx

No deberíamos tener ningún problema, sino, journalctl -xe y miramos los logs. Pero si todo se ha hecho bien, no debería darnos problemas y si visitamos nuestro sitio bajo HTTPS lo veremos habilitado.

Lo que nos quedaría sería estar pendientes de cuando nuestro certificado va a caducar, algo que podemos hacer desde la propia web.


Ya observamos que nos dice que ha sido verificado por Let's Encrypt y que caduca el 17 de septiembre de 2019. A partir de aquí ya es responsabilidad nuestra que una semana antes nos pongamos un aviso en nuestro propio sistema, móvil o lo que sea, pero no podemos permitir que se caduque el mismo día que lo vayamos a renovar. Esa es la diferencia entre un buen sysadmin y uno un poco menos bueno.

¿Hackeamos el Mundo?



No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...