Un certificado SSL/TLS es un documento digital que demuestra la identidad de un sitio web y permite que tu navegador establezca con él una conexión HTTPS cifrada. Vincula un nombre de dominio con una clave pública y está firmado por una autoridad de certificación (CA) en la que los navegadores ya confían.
Siempre que ves https:// y un candado o un indicador parecido en la barra de direcciones, hace una fracción de segundo que se ha comprobado un certificado. Los certificados cumplen dos funciones a la vez: autentican al servidor, para que sepas que hablas con el verdadero example.com y no con un impostor, y permiten el cifrado, para que nadie en la ruta de red pueda leer ni alterar lo que envías.
SSL o TLS: ¿cuál es la diferencia?
SSL (Secure Sockets Layer) fue el protocolo original, desarrollado por Netscape en la década de 1990. Lo sucedió TLS (Transport Layer Security), y todas las versiones de SSL se consideran hoy inseguras y están oficialmente obsoletas. TLS 1.0 y 1.1 también quedaron obsoletos, en la RFC 8996 (2021), por lo que las conexiones modernas usan TLS 1.2 o TLS 1.3.
Sin embargo, el nombre «certificado SSL» se quedó. El certificado en sí no está ligado a una versión del protocolo; el mismo certificado funciona con cualquier versión de TLS. «Certificado SSL», «certificado TLS» y «certificado HTTPS» significan lo mismo.
Cómo funciona el handshake de TLS
Antes de intercambiar ningún dato de una página web, el navegador y el servidor realizan un handshake (negociación inicial). De forma simplificada, un handshake de TLS 1.3 es así:
- Client hello. El navegador se conecta, normalmente por el puerto 443, e indica qué versiones de TLS y qué conjuntos de cifrado admite. Incluye el nombre de host que quiere (mediante la extensión Server Name Indication, para que una misma dirección IP pueda alojar muchos sitios) y su parte de un intercambio de claves.
- Server hello. El servidor elige los parámetros, envía su propia parte de la clave y presenta su certificado junto con una firma que demuestra que posee la clave privada correspondiente.
- Verificación. El navegador comprueba que el certificado cubre el nombre de host, que está dentro de sus fechas de validez y que su cadena llega hasta una CA raíz de confianza.
- Claves de sesión. Ambas partes derivan las mismas claves de sesión simétricas a partir del intercambio de claves. Todo el tráfico posterior se cifra con ellas.
La clave privada nunca sale del servidor. La criptografía de clave pública se usa solo para autenticar y acordar las claves; el grueso de los datos se cifra con cifrados simétricos rápidos, como AES-GCM o ChaCha20-Poly1305. TLS 1.3 completa todo esto en un solo viaje de ida y vuelta, frente a los dos de TLS 1.2.
Qué contiene un certificado
Un certificado sigue el estándar X.509 y contiene, entre otros campos:
- Nombres alternativos del sujeto (SAN): los nombres de host para los que es válido el certificado. Los navegadores comprueban esta lista, no el antiguo campo Common Name.
- Clave pública: la clave pública RSA o ECDSA del servidor.
- Emisor: la CA que firmó el certificado.
- Periodo de validez: las fechas «Not Before» y «Not After».
- Número de serie y firma: un identificador único y la firma del emisor sobre todo lo anterior.
Certificados SAN y wildcard
Un solo certificado puede cubrir muchos nombres si se enumeran como SAN, por ejemplo example.com, www.example.com y shop.example.com. Un wildcard como *.example.com cubre cualquier etiqueta única en ese nivel, así que coincide con www.example.com y api.example.com, pero no con example.com en sí ni con nombres más profundos como a.b.example.com. Por eso los certificados wildcard suelen incluir el dominio sin subdominio como un SAN adicional.
Certificados DV, OV y EV
Los certificados se diferencian en lo a fondo que la CA comprobó al solicitante antes de emitirlos:
| Tipo | Qué se verifica | Uso habitual |
|---|---|---|
| Validación de dominio (DV) | Solo que el solicitante controla el dominio, mediante un registro DNS, un archivo en el sitio web o un correo electrónico | La mayoría de los sitios web; se emite automáticamente en segundos |
| Validación de organización (OV) | El control del dominio más la existencia legal de la organización | Empresas que quieren que el nombre de la compañía figure en los detalles del certificado |
| Validación extendida (EV) | Una comprobación más estricta y estandarizada de la entidad legal | Algunos bancos y grandes empresas |
Los tres ofrecen exactamente la misma fortaleza de cifrado. La diferencia está solo en la información de identidad. Los principales navegadores dejaron de mostrar un nombre de empresa especial en verde para los certificados EV hacia 2019, así que para la mayoría de los sitios un certificado DV es la opción práctica.
La cadena de confianza
Tu sistema operativo y tu navegador incluyen un almacén raíz: una lista de certificados de CA raíz en los que confían. Las CA raíz rara vez firman directamente los certificados de los sitios web. En su lugar, firman certificados intermedios, que a su vez firman el certificado hoja (el del servidor):
Root CA (en el almacén de confianza del navegador)
└── Intermediate CA (enviado por el servidor)
└── www.example.com (certificado hoja, enviado por el servidor)El servidor debe enviar su certificado hoja y los intermedios. El navegador verifica entonces cada firma hasta llegar a una raíz en la que ya confía. Este esquema permite mantener las claves raíz fuera de línea y bien protegidas. Para protegerse de emisiones indebidas, los certificados de confianza pública también se registran en los registros públicos de Certificate Transparency, y los propietarios de dominios pueden restringir qué CA pueden emitir certificados para ellos con un registro DNS CAA, que describimos en nuestra guía sobre los tipos de registros DNS.
Let's Encrypt y la vigencia de los certificados
Let's Encrypt, una CA sin ánimo de lucro, popularizó los certificados DV gratuitos. Sus certificados son válidos durante 90 días y están pensados para renovarse automáticamente mediante el protocolo ACME, con clientes como Certbot o funciones integradas en muchos servidores web y paneles de alojamiento. La mayoría de los proveedores de hosting y de las CDN emiten y renuevan ya los certificados sin ningún paso manual.
La vigencia de los certificados se está acortando en todo el sector. Según la votación SC-081 del CA/Browser Forum, la validez máxima de los certificados TLS de confianza pública se reduce por etapas, empezando por 200 días desde marzo de 2026 y bajando más en los años siguientes. El calendario exacto aún puede cambiar, pero la dirección está clara: automatiza la renovación, porque renovar los certificados a mano será cada vez menos práctico.
Errores de certificado habituales y cómo corregirlos
Certificado caducado
Los navegadores muestran errores como NET::ERR_CERT_DATE_INVALID. Renueva el certificado y recarga el servidor web. Después averigua por qué falló la renovación automática, algo que suele deberse a un cortafuegos que bloquea la validación, a un cambio de DNS o a una tarea cron rota. Un reloj incorrecto en el dispositivo del visitante puede causar el mismo error, así que comprueba la fecha si solo se queja un dispositivo.
Nombre que no coincide
Errores como ERR_CERT_COMMON_NAME_INVALID significan que el nombre de host de la barra de direcciones no está en la lista SAN del certificado; por ejemplo, un certificado para www.example.com que se sirve para example.com. Vuelve a emitir el certificado para que incluya todos los nombres de host que sirves, o redirige a los visitantes a un nombre cubierto.
Cadena incompleta
Si el servidor envía solo el certificado hoja sin sus intermedios, algunos navegadores lo solucionan descargando o guardando en caché la pieza que falta, mientras que otros, junto con muchas herramientas de línea de comandos y aplicaciones, fallan. Configura el servidor con el archivo de cadena completa (a menudo llamado fullchain.pem).
Certificado autofirmado o emisor no fiable
NET::ERR_CERT_AUTHORITY_INVALID significa que la cadena no lleva a una raíz de confianza, normalmente porque el certificado es autofirmado o procede de una CA privada. Eso está bien para pruebas internas, pero no para un sitio público; sustitúyelo por un certificado de una CA pública. El mismo error puede aparecer cuando un antivirus o un proxy corporativo interceptan el HTTPS.
Contenido mixto
El certificado es válido, pero la página carga scripts o imágenes por http:// sin cifrar. Cambia esas URL a HTTPS y valora añadir una cabecera HSTS para que los navegadores usen siempre HTTPS.
openssl s_client -connect example.com:443 -servername example.com muestra la cadena completa que envía el servidor.Preguntas frecuentes
¿HTTPS significa que un sitio web es seguro?
No. HTTPS significa que tu conexión con el sitio está cifrada y que el sitio controla el dominio que se muestra. Los sitios de phishing pueden tener, y tienen, certificados DV válidos. Comprueba siempre el nombre de dominio en sí.
¿Son los certificados gratuitos menos seguros que los de pago?
No. Un certificado DV gratuito de Let's Encrypt ofrece el mismo cifrado que uno de pago. Los certificados de pago pueden añadir validación de identidad (OV/EV), garantías o soporte, pero no un cifrado más fuerte.
¿Cuánto dura un certificado SSL?
Los certificados de Let's Encrypt duran 90 días. Las demás CA públicas están sujetas al máximo del CA/Browser Forum, que se va acortando por etapas desde los 200 días de 2026. La renovación automática es el enfoque más seguro.
¿Qué puerto usa HTTPS?
HTTPS usa por defecto el puerto TCP 443, mientras que HTTP sin cifrar usa el 80. Consulta nuestra guía sobre los puertos de red más comunes para saber más.
Comentarios
Inicia sesión para valorar esta herramienta.
Comparte un consejo, haz una pregunta o cuenta cómo te funcionó la herramienta.
Aún no hay comentarios. Sé el primero en contar cómo te fue.