Localización y resolución de problemas de Let's Encrypt/Certbot: Errores comunes y soluciones

Al igual que con cualquier problema con errores en la configuración DNS o HTTPS, encontrar la causa raíz puede llevar un tiempo.

Sin embargo, los problemas más comunes surgen cuando es necesario cambiar los registros DNS o habilitar el soporte de certificados SSL/HTTPS para un servidor web a través de un proveedor de certificados como Let's Encrypt.

En este artículo, repasaremos los problemas más comunes a los que te puedes enfrentar en la configuración de su servidor y las formas de solucionarlos.

Navegando por el mundo de los registros DNS

El dominio es una parte integral de la navegación web. Sin dominios, sería difícil encontrar e identificar sitios web.

• Los registros DNS (Domain Name System) son en lo que consiste el DNS. Conservan la información sobre un dominio y le permiten a usted, el propietario del dominio, controlar los datos que conservan los registros DNS (puede señalar qué contenido conserva bajo un dominio). Si tiene varios dominios, tendrá registros DNS distintos para cada uno de ellos.
• Un registro es uno de los registros DNS más comunes, que significa una dirección IP de su servidor. Un tipo de registro DNS permite navegar por un sitio web a través del dominio. Así, incluso si la dirección IP del sitio web es desconocida, se puede navegar por un sitio web a través de los registros A. Los registros A también pueden utilizarse para una lista de agujeros negros en el DNS; con ella, puede bloquear contenidos no deseados, como el correo basura.
• Los registros DNS AAAA permiten asignar direcciones IPv6 a hosts (ordenadores o dispositivos) en la web. IPv6 es un protocolo de comunicación que permite localizar e identificar ordenadores a través de la web. Los registros AAAA forman parte de IPv6 y permiten asignar una dirección a un host o un host a una dirección específica. Los administradores de red utilizan ampliamente este tipo de registro DNS para vincular sus dispositivos con direcciones personalizadas. AAAA es similar a los registros A. Sin embargo, ofrece datos más recientes sobre las direcciones. Por lo tanto, si un sitio web ya utiliza el protocolo IPv6, debe utilizar registros DNS AAAA.
• Los registros Nameserver se utilizan para identificar a qué servidor DNS pertenece su dominio. Indica a los usuarios a qué DNS deben acceder para encontrar una dirección IP para su dominio.
• Los registros .CHAME crean un directorio alternativo para su dominio, de modo que cuando, por ejemplo, un usuario escriba su nombre de dominio en el orden equivocado, aún pueda redirigirlo a su sitio web.
• Los registros de intercambio de correo contienen datos sobre los servidores de correo para recibir los mensajes enviados a su dominio; también dirigen a los usuarios a los registros DNS A o AAAA para que apunten a una dirección donde esté alojado su servidor de correo.
• Por último, los registros TXT permiten añadir información adicional sobre su dominio en DNS.

Los registros DNS son esenciales para conectar un dominio a un servidor de alojamiento, garantizando así que su sitio web esté en funcionamiento.

Existen opciones para crear, editar o eliminar registros DNS. A continuación, veremos qué significa.

Dominando el arte de actualizar o migración de registros DNS

Así, los registros DNS pueden actualizarse y migrarse. Ambos procesos llevan cierto tiempo, dependiendo de los registros que desee cambiar. Cuando actualizas los registros DNS de un dominio, los cambios pueden tardar hasta 48 horas en aplicarse.

Este periodo de espera se denomina propagación DNS. La propagación DNS se produce cuando los nodos ISP (Internet Service Provider) actualizan su base de datos con la nueva información DNS relativa a su dominio.

Algunos usuarios son redirigidos a su antiguo servidor durante la propagación DNS, mientras que otros pueden acceder a su sitio web en un nuevo servidor si decide migrar sus registros DNS.

La duración de la propagación DNS está influenciada por el TTL (Time-To-Live), su ISP, y la ubicación, y por lo tanto, es difícil de predecir en general. Sin embargo, puede utilizar comprobadores DNS en línea para ver si los datos del registro DNS se han propagado a través de varios servidores seleccionados aleatoriamente en todo el mundo. Con la ayuda de un comprobador de DNS, podrá ver si su sitio web se ha propagado de acuerdo con los cambios realizados en todos los servidores del mundo.

En algunos casos, su ISP puede actualizar más lentamente que su servidor remoto. Para comprobar si éste es el origen del error, puede utilizar el comando "nslookup" para ver si los resultados de la actualización local coinciden con los de los resolvedores DNS globales. Si no hay errores con este aspecto, pero sus resultados siguen sin coincidir, el error podría residir en un valor más largo del TTL.

El valor TTL debe indicarse junto a los registros A y puede personalizarse. Si desea aplicar los cambios a los registros DNS más rápidamente, puede reducir el valor TTL; esto podría ayudar a eliminar el error.

Descifrando errores del navegador y desentrañando fallos de configuración HTTPS

Veamos lo básico.

El protocolo HTTPS utiliza el cifrado para la comunicación segura entre navegadores y servidores web. La "S" de HTTPS significa "seguro" y se rige por el cifrado TLS o SSL. Muchos problemas de rendimiento se han evitado gracias a LetsEncrypt y sus certificados SSL/HTTPS accesibles.

Un sitio web que no puede proporcionar una conexión segura normalmente tiene errores con la configuración HTTPS, no necesariamente HTTPS en sí. En cualquier caso, si los errores no se resuelven, los usuarios verán notificaciones de error al intentar acceder a su sitio web.

Si tienes una aplicación para una pasarela HTTPS como Nginx Reverse Proxy, y la pasarela tiene una configuración incorrecta, pueden aparecer errores como 502 "Bad Gateway" error.

Del mismo modo, si no está utilizando un certificado HTTPS comercial, sino un certificado LetsEncrypt en su lugar, podrían producirse errores debido a la necesidad de que los certificados de LetsEncrypt se renueven después de algún tiempo. En este caso, recibirá una notificación de error que dice "Su conexión no es privada", con un error descrito como "NET::ERR_CERT_DATE_INVALID". Esto significa que debe actualizar su certificado LetsEncrypt.

Normalmente, con la configuración inicial de LetsEncrypt, usted tiene la opción de renovar automáticamente su certificado. Alternativamente, LetsEncrypt enviará una notificación a su correo electrónico diciendo que su certificado está a punto de expirar. Si, por alguna razón, ambas formas no funcionan, puede renovar su certificado manualmente a través de "sudo certbot renew --nginx -d example.com -d www.example.com".

Deberá reiniciar su servidor web para eliminar el error asociado a un certificado caducado. Si quiere que esta operación se ejecute automáticamente, puede utilizar el comando "systemctl restart nginx" después de renovar manualmente su certificado.

Resolución del problema de los contenidos mixtos

El error de contenido mixto aparece cuando el sitio web al que intenta acceder un usuario carga simultáneamente los protocolos HTTPS y HTTP. HTTPS y HTTP son protocolos inherentemente diferentes. Así, cuando se cambia a HTTPS pero no se transfieren todos los datos a HTTPS, y HTTP gobierna parte del contenido, aparecerá un error de contenido mixto.

La mayoría de los navegadores mostrarán una notificación de error del tipo "Su conexión a este sitio no es totalmente segura".

En cualquier caso, la mayoría de los errores de contenido mixto en un navegador aparecen justo después de que un usuario migra de HTTP a HTTPS. Sin embargo, puede haber fuentes adicionales de este problema, incluyendo:

• Su contenido gráfico (vídeo o imágenes) no está en HTTPS.
• Ha añadido un plugin o un nuevo servicio a su sitio que no coincide con HTTPS.

Puede ser difícil encontrar la causa raíz de un error de navegador hasta que empiece a solucionar el problema.

Los pasos más importantes en la solución de errores de navegador de contenido mixto son la instalación de certificados SSL y la transferencia de HTTP a HTTPS en todo el sitio.

Por ejemplo, si está utilizando un proxy Nginx y una aplicación para su servidor web, puede añadir configuración adicional de certificados SSL a una sección de ubicación.

Si no está utilizando un proxy Nginx y una aplicación para su servidor web, compruebe si el contenido HTTP está disponible a través de HTTPS. Puedes sustituir "http" por "https" al principio de la URL de su contenido. A continuación, puede actualizar las URL en su base de datos.

Ejecutando el script Certbot de Let's Encrypt

El script Certbot de LetsEncrypt puede tener errores internos por varias razones.

A veces, el script de Certbot no responde, lo que puede provocar que se agote la sesión y que el cortafuegos elimine el tráfico.

Si el problema es con el firewall, recibirás la siguiente notificación: "certbot --nginx -d ejemplo.com -d www.example.com".

Si este es el caso, asegúrate de que puedes abrir los puertos 80 y 443 antes de ejecutar Certbot, y de que no hay ningún cortafuegos bloqueándolos. Si estás utilizando un cortafuegos sin complicaciones con Nginx, prueba la configuración "Nginx full" a través de "sudo ufw allow 'Nginx Full'".

Después de cambiar la configuración dentro de su firewall, reinicie Certbot. Si al reiniciar Certbot obtiene "demasiadas autorizaciones fallidas recientemente", tendrá que esperar algún tiempo para acceder a Certbot.

Si se presentan otros errores de Certbot que no tengan que ver con DNS o conexión, considera reinstalar Certbot.

Resolución de problemas HTTPS cuando no hay errores visibles

Ahora, si ha reinstalado Certbot y se ha asegurado de que el DNS funciona correctamente, pero parte del contenido de su sitio web sigue en HTTP, podría haber un problema con la configuración del servidor web.

Certbot normalmente intenta actualizar los archivos de configuración del servidor web automáticamente (esto se suele hacer especificando "nginx" en la ventana de comandos). Pero si la configuración de su servidor web es compleja, la operación automatizada de Certbot puede no ser suficiente, y es necesario resolver el problema manualmente.

Para que Certbot configure automáticamente SSL, necesita saber el "server_name" en el proxy Nginx que coincide con el dominio del certificado. Normalmente, un server_name debe estar al final de "/etc/nginx/sites-available/...".

Puede encontrar el nombre de su servidor usando "nano" en Certbot, y debería verse así: "$ sudo nano /etc/nginx/sites-available/example.com", siendo example.com el nombre de su servidor web.

Si el nombre de su servidor no está allí, debe ponerlo allí, guardar el archivo y verificar los cambios a través de "sudo nginx -t". A continuación, vuelva a cargar Nginx. Una vez hecho esto, Certbot sabrá qué archivo de configuración debe actualizar.

Si aún encuentra errores, debe configurar manualmente su servidor web a HTTPS.

La configuración HTTPS de Nginx tendrá "listen 443 ssl" y una ruta y una clave para el certificado SSL.

En el proceso de configuración del proxy Nginx, recomendamos guardar los cambios de Ngnix a través de "sudo nginx -t". Después de guardar los cambios, reinicie el proxy Nginx.

Más allá de los obstáculos de Let's Encrypt/Certbot

Los posibles errores pueden parecer intimidantes si carece de experiencia en el uso de SSL o DNS.

Pero aunque LetsEncrypt tiene éxito y es relativamente fácil de configurar cuando se ejecuta sin errores, puede que necesites algunos conocimientos de solución de problemas para ahorrar tiempo y estrés innecesario.

Es por eso que repasamos algunos de los errores más comunes con LetsEncrypt y Certbot para que puedas gestionar los problemas que surjan de manera eficiente.

Esperamos haberle ayudado.