Durante todo este año 2016 se lleva hablando de la seguridad en internet y de la necesidad de asegurar los sitios web con certificados SSL/TLS puesto que Google anunció que daría prioridad en sus resultados a los sitios seguros.
La posibilidad de conseguir certificados gratuitos ha hecho que muchos blogs los hayan incorporado a sus servidores.
Aprovechando el mes de Agosto y después de leer bastante y hacer varias pruebas durante los fines de semana, he instalado el certificado ssl de Let’s Encrypt en el vps que tengo contratado con Digital Ocean, en el que uso LEMP (Linux, Nginx, MySQL, Php) con Ubuntu Server 14.04, y de esa forma ofrecer una conexión segura en el blog.
Y a pesar de que se que me voy a repetir y que ya otros lo han explicado, y que en este momento se recomienda utilizar Certbot,
como para nginx no me quedaba claro que fuese a funcionar y no soy programador, he instalado el certificado ssl de Let’s Encrypt utilizando un método mas antiguo pero que me permitía realizar los pasos uno a uno e ir comprobando que todo funcionaba y aun así tuve mis problemas por errores a la hora de configurar el fichero de nginx.
Por si alguien quiere utilizar la información, indicar que los datos introducidos son los que yo tengo configurados en mi servidor.
Solamente hay un dato que no es real que es el que está escrito en azul, en el que he sustituido el valor real por midominio, veamos pues los pasos con los que he
Instalado el certificado ssl de Let’s Encrypt en el blog
En primer lugar instalar git
sudo apt-get -y install git bc
Luego clonar el directorio de git
sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
Comprobar que el fichero de configuración de nginx que en mi caso se encuentra en:
/etc/nginx/sites-available/
y se llama midominio.conf, incluye dentro del bloque server:
location ~ /.well-known { allow all; }
También aprovecharemos para comprobar la ruta en la que tenemos instalados los ficheros de nuestro WordPress. Está en el bloque server y comenzará por root, en mi caso la linea está formada por:
root /var/www/midominio/html/;
y de ella debemos guardar el valor /var/www/midominio/html/ que vamos a necesitar para utilizar mas adelante. Si hacemos algún cambio debemos salvarlo reiniciando el servicio nginx con el comando:
sudo service nginx reload
o
sudo systemctl reload nginx
en las versiones mas recientes que incorporan systemctl
Esto nos va ha permitir usar el plugin webroot. En el comando tenemos que especificar la ruta donde tenemos instalado let’s encrypt y donde están los ficheros de nuestra web, que hemos obtenido antes en la linea root del fichero de configuración de nginix para nuestro dominio. Esto permite que la web pueda conectarse ver nuestro fichero y copiar los certificados en nuestro servidor.
sudo /opt/letsencrypt/letsencrypt-auto certonly -a webroot --webroot-path=/var/www/midominio/html/ -d midominio.com -d www.midominio.com
Al ejecutarse se nos abrirá una pantalla en la que se nos pedirá que contestemos alguna pregunta y también nos pedirá una dirección de correo para enviar las novedades. Finaliza con una pantalla en la que nos indica donde se ha descargado el certificado y si queremos realizar una donación al proyecto. Comprobamos que se han descargado nuestros certificados con el comando:
sudo ls -l /etc/letsencrypt/live/midominio.com
y nos debe salir un resultado similar al siguiente:
lrwxrwxrwx 1 root root 33 Aug 29 01:33 cert.pem -> ../../archive/midominio.com/cert1.pem lrwxrwxrwx 1 root root 34 Aug 29 01:33 chain.pem -> ../../archive/midominio.com/chain1.pem lrwxrwxrwx 1 root root 38 Aug 29 01:33 fullchain.pem -> ../../archive/midominio.com/fullchain1.pem lrwxrwxrwx 1 root root 36 Aug 29 01:33 privkey.pem -> ../../archive/midominio.com/privkey1.pem
Para incrementar la seguridad, podemos generar un grupo Diffie-Hellman de 2048 con el comando:
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
Como tenemos que cambiar el puerto 80 que utiliza el protocolo http por el puerto seguro 443 que utiliza el protocolo https debemos comprobar que tenemos abierto nuestro firewall para ese puerto con el comando:
sudo ufw allow 443/tcp
Ahora volvemos a editar con nano el fichero de configuración de nginx para nuestro sitio:
sudo nano /etc/nginx/sites-available/midominio.conf
Y cambiamos el puerto en el que escucha el servidor del 80 al 443 sustituyendo:
listen 80; listen [::]:80;
por:
listen 443 ssl; listen [::]:443 ssl; server_name midominio.com www.midominio.com; ssl_certificate /etc/letsencrypt/live/midominio.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/midominio.com/privkey.pem;
en el que hemos añadido el nombre del servidor y la ruta a nuestros certificados de Letsencrypt. Para hacerlo mas seguro podemos añadir a continuación las siguientes líneas:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_dhparam /etc/ssl/certs/dhparam.pem; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_stapling on; ssl_stapling_verify on; add_header Strict-Transport-Security max-age=15768000;
Dirigir el trafico http a https
La parte que mas problemas me ha causado ha sido la redirección de las antiguas direcciones con http a las nuevas con https, por errores en la edición del fichero de configuración de nginx.
Para que esto funcione es necesario añadir fuera de los corchetes del server que escucha en el puerto 443 otro server que escuche en el puerto 80 con una redirección 301 al nuevo dominio.
En mi caso tuve problemas porque no me fije que el corchete de cierre se encontraba al final del fichero y cuando añadía la sección nueva se producía un error.
server { listen 80; server_name midominio.com www.midominio.com; return 301 https://$host$request_uri; }
Una vez realizados los cambios salvamos el fichero y comprobamos que no tenemos ningún error con el comando:
sudo nginx -t
que nos debe dar una salida:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
Ahora recargamos el servicio de nginx con los cambios realizados con el comando
sudo service nginx reload
o
sudo systemctl reload nginx
en las versiones mas recientes que incorporan systemctl
Renovación de certificados automática
A continuación he automatizado la renovación de los certificados ya que solamente duran 90 días, para ello he utilizado cron, de tal manera que con el comando:
sudo crontab -e
he añadido dos lineas que lo que hacen es pedir una renovación todos los lunes a las 3 y media de la madrugada que es una hora de poco trafico en el blog
30 3 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/le-renew.log 35 3 * * 1 /etc/init.d/nginx reload
Por último ya en el propio wordpress he instalado el plugin Really Simple SSL que hace que el contenido inseguro se repare reemplazando todas las urls http:// por https://, excepto enlaces a otros dominios. Se hace de manera dinámica, así que no se hacen cambios en la base de datos (excepto en el siteurl y homeurl).
Comprobar el cambio a https
Ahora podemos comprobar la calidad de nuestro certificado en la web: https://www.ssllabs.com/ssltest/analyze.html?d=midominio.com.
Encontrar elementos no seguros que provocan candado naranja
Si en alguna de las direcciones de nuestro blog sale un candado naranja en lugar del candado verde, hay que comprobar que elementos tenemos en la página que no sean seguros.
Para comprobarlo podemos usar el explorador Chrome/Chromium.
Pulsando sobre el símbolo donde debería estar el candado verde se nos abre una pestaña y al pulsar sobre detalles una ventana en la parte derecha del explorador.
En ella al pulsar sobre la pestaña console nos aparece información sobre los elementos que no son seguros, para poder eliminarlos o poder sustituirlos por url seguras.
Lo siguiente que hay que hacer es conectarse a Google Search Console y crear una nueva propiedad para el blog que incluya la nueva url con la s: https://midominio.com, y https://www.midominio.com.
También en el fichero robots.txt debemos cambiar la dirección del sitemap a https.
Lo siguiente que hay que hacer es conectarse a Google Search Console y crear una nueva propiedad para el blog que incluya la nueva url con la s: https://midominio.com, y https://www.midominio.com. También en el fichero robots.txt debemos cambiar la dirección del sitemap a https.
Cualquier problema de acceso a las páginas del blog que los lectores podáis encontrar agradecería que me lo indicarais en los comentarios para poder solucionarlo. Y si se me ha colado algún error en el proceso por favor indicarlo también en los comentarios
Todo esto no hubiese sido posible realizarlo sin la información recabada en el blog LinuxGNUblog, basado en el blog de Digital Ocean, Y en la ayuda de Google para cambio de url, y en la información del blog Apañados, para encontrar los elementos no seguros.
Hola colega,
Gracias a tus consejos he arreglado un problemilla con algunos artículos en los que no funcionaba correctamente el https. Al final resulta que los botones de compartir apuntaban a URL con http, en vez de https.
Un saludo!!
Oye David que honor que un lego como yo te haya podido ayudar. Yo tengo pendiente arreglar el botón de Diaspora.
Hola,
Sólo un apunte, revisa la línea:
ssl_ciphers ‘ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-A$
Falta al final ‘;
Saludos
Gracias David, ya está corregido.
Se había quedado la linea a medias, por ese motivo faltaba la terminación.