Certificado SSL gratis: cómo funciona

Casi todos los sitios funcionan hoy con HTTPS, y gran parte de esos certificados vienen de Let's Encrypt. Existe para que cifrar la conexión entre navegador y servidor no dependa de pagar a una autoridad certificadora ni de llenar formularios. La clave es la automatización: después de la configuración inicial, un programa pide, demuestra y renueva el certificado sin que toques nada.

Si aún no sabes qué hace un certificado TLS, empieza por qué es SSL/TLS.

¿Qué es Let's Encrypt?#

Let's Encrypt es una autoridad certificadora (CA) pública, operada por la Internet Security Research Group (ISRG), una organización sin fines de lucro. Los certificados que emite son reconocidos por los navegadores y sistemas operativos comunes, así que el visitante no ve ninguna advertencia.

El certificado es de tipo DV (Domain Validation): solo certifica que quien lo pidió controla el dominio. No verifica la identidad de la empresa detrás del sitio. Para la mayoría de los sitios, bots con panel web y APIs, es suficiente.

Let's Encrypt no cobra por los certificados. La operación se sostiene con donaciones y patrocinios, y el costo por certificado es bajo porque todo está automatizado, sin atención al cliente ni verificación manual.

Cuando usas Let's Encrypt a través de un proveedor de hosting o de un panel, el certificado sigue sin costo, pero el proveedor puede cobrar una tarifa por su trabajo administrativo. Lee el plan antes de suponer que todo sale gratis. Para comparar con certificados de pago, mira cuánto cuesta un certificado SSL.

¿Cómo funciona el protocolo ACME?#

ACME (Automatic Certificate Management Environment) es el protocolo que usa Let's Encrypt. El flujo tiene cuatro pasos:

1. Solicitud. El cliente ACME (Certbot, acme.sh, Caddy, Traefik y otros) genera un par de claves y pide un certificado para un dominio.
2. Desafío. La CA responde con un desafío: una tarea que solo puede cumplir quien controla el dominio.
3. Prueba. El cliente cumple el desafío publicando un archivo o un registro DNS.
4. Emisión. La CA verifica la prueba, firma el certificado y el cliente lo instala.

Como el cliente repite este flujo solo, la renovación no depende de acordarte de una fecha en el calendario.

¿Qué tipos de desafío existen?#

Let's Encrypt acepta tres desafíos. Los dos más usados son HTTP-01 y DNS-01.

HTTP-01 es el más simple: el cliente coloca un archivo en tu servidor web y la CA lo consulta por el puerto 80. Si tienes varios servidores detrás del mismo dominio, el archivo debe estar en todos. Los proveedores de internet que bloquean el puerto 80 impiden este método.

DNS-01 es el único que emite certificados wildcard (*.ejemplo.com). También funciona con servidores que no son accesibles desde internet. La contrapartida es automatizar la creación del registro TXT, lo que exige que tu proveedor de DNS tenga una API. Guardar esa credencial en el servidor web es un riesgo de seguridad, así que usa una clave con permisos limitados. Si los registros DNS aún son nuevos para ti, lee qué son los registros DNS.

TLS-ALPN-01 tiene soporte limitado entre los clientes y sirve para proxies inversos que terminan el TLS.

¿Cómo emitir un certificado con Certbot?#

Requisitos: un dominio apuntando a la IP del servidor, el puerto 80 abierto y acceso sudo. Las instrucciones de instalación por sistema están en certbot.eff.org. En un servidor Ubuntu o Debian:

sudo apt install certbot
sudo certbot certonly --standalone -d ejemplo.com -d www.ejemplo.com

El modo --standalone levanta un servidor temporal en el puerto 80, así que detén antes cualquier servicio que lo esté usando. Los archivos quedan en /etc/letsencrypt/live/ejemplo.com/: fullchain.pem (certificado y cadena) y privkey.pem (clave privada, nunca la compartas).

Para un certificado wildcard, usa DNS-01. El modo manual de abajo sirve solo para probar y no renueva solo; en producción, usa el plugin de tu proveedor de DNS:

sudo certbot certonly --manual --preferred-challenges dns -d "*.ejemplo.com"

¿Cómo verificar y renovar?#

Lista los certificados instalados y su fecha de vencimiento:

sudo certbot certificates

Prueba la renovación sin emitir nada de verdad:

sudo certbot renew --dry-run

Para comprobar qué está entregando realmente el servidor:

echo | openssl s_client -connect ejemplo.com:443 -servername ejemplo.com 2>/dev/null | openssl x509 -noout -dates -issuer

La salida muestra notBefore, notAfter y el emisor.

Let's Encrypt recomienda renovar bastante antes del vencimiento, en un horario aleatorio, para no generar picos de tráfico en la CA. Como la validez es cada vez más corta, un intervalo fijo en días deja de bastar: usa clientes con soporte de ARI (ACME Renewal Information) o renueva tras unos dos tercios de la vigencia.

La mayoría de las instalaciones de Certbot ya traen renovación automática, con un timer de systemd o una entrada de cron, pero depende del método de instalación. Confírmalo con systemctl list-timers | grep certbot o buscando certbot renew en /etc/cron.*/*. Los certificados emitidos con --manual no se renuevan solos.

¿Por qué los certificados son cada vez más cortos?#

Durante años, el valor por defecto de Let's Encrypt fue de 90 días. En diciembre de 2025 anunció un cronograma que reduce esa validez por etapas, primero en el perfil opcional tlsserver y después en el perfil por defecto, classic. Las fechas y los plazos de cada etapa están en el anuncio oficial. Existe además el perfil shortlived, con certificados de pocos días, que exige renovar con mucha frecuencia.

Los certificados cortos limitan el daño de una clave filtrada, pero solo funcionan bien con renovación automática. Si renuevas a mano, esa es la razón para automatizar. Otro cambio: Let's Encrypt dio de baja el OCSP en 2025, y los certificados ya no traen URL de OCSP.

¿Qué errores aparecen con más frecuencia?#

• Falla de validación HTTP-01: el dominio no apunta al servidor, el puerto 80 está bloqueado por un firewall o una redirección rompe la ruta /.well-known/acme-challenge/.
• Límites de tasa (rate limits): hay topes para fallos de validación por dominio y por cuenta, para certificados idénticos y para certificados por dominio registrado, entre otros. Los valores actuales están en la página de rate limits. Prueba con --dry-run antes de emitir de verdad.
• La renovación deja de funcionar: el timer se desactivó, el puerto 80 lo usa ahora otro servicio o la credencial de la API de DNS venció.
• El navegador indica certificado inválido: suele ser la cadena incompleta (usa fullchain.pem, no cert.pem) o el certificado vencido. Mira errores de certificado SSL.

Cómo hacerlo en Square Cloud#

En Square Cloud no necesitas emitir ni renovar certificados: el TLS es automático en todos los planes, con un certificado DV que se renueva solo, y el HTTP se redirige a HTTPS. Toda aplicación web recibe un subdominio *.squareweb.app con HTTPS, sin configuración.

Para usar un dominio propio, desde el plan Standard, creas en tu registrador los registros DNS que muestra el panel y sigues la validación en tiempo real. El TLS del dominio propio también es automático, y el dominio sigue registrado a tu nombre en tu registrador.

Para el paso a paso con dominio propio, mira cómo usar un dominio personalizado y la página de dominios.