Verificación de certificado SSL: en línea, en el navegador y con OpenSSL
Una verificación de certificado SSL te dice si los navegadores confían en tu HTTPS: si el certificado ha caducado, si el nombre coincide con el dominio, si la cadena está completa y quién lo emitió. La forma más rápida de comprobar SSL en línea es ingresar el dominio en el verificador de certificados SSL: el resultado tarda unos segundos. Sin un certificado que funcione, los navegadores marcan el sitio como no seguro y algunos visitantes se van antes de que cargue la página.
Cómo comprobar un certificado SSL en línea, paso a paso
- Abre el verificador de certificados SSL e ingresa un dominio:
example.com. También funciona con una URL completa: la herramienta extrae el nombre de host. Un puerto no estándar va después de dos puntos:example.com:8443. - La herramienta se conecta con la misma rigurosidad que un navegador, verificando la cadena de confianza y el nombre de host. Si la verificación estricta falla, se conecta una segunda vez sin ella, para poder mostrarte el certificado y explicarte qué está mal.
- Mira el banner de la parte superior: cuántos días quedan. Si faltan menos de 30 días verás una advertencia amarilla; un banner rojo significa que los navegadores no confían en el certificado, con los motivos listados debajo: caducado, emitido para otro nombre, autofirmado o una cadena que no se verifica. El mensaje de OpenSSL del intento estricto se muestra debajo de la lista.
- Revisa las tarjetas de detalle: Common Name, emisor, fechas de "válido desde" y "válido hasta", tipo y tamaño de clave (RSA de menos de 2048 bits se marca como débil), algoritmo de firma y los Subject Alternative Names (SAN): todos los nombres de host que sirves, incluido www, deben estar en esa lista.
- Repite la comprobación para
www.example.comy tus subdominios. Cada nombre puede tener su propio certificado, y el que falla suele ser el host que nadie visita.
Para ser claros con los límites: esta es una comprobación puntual de un solo nombre de host. No enumera las versiones de TLS ni los cifrados que acepta tu servidor, no busca contenido mixto en las páginas y no vigila la fecha de caducidad por ti. Las versiones de protocolo se pueden probar con los comandos de openssl que verás abajo o con el escáner Shield.
Cómo ver un certificado en tu navegador
- Chrome, Edge y otros navegadores Chromium: haz clic en el icono a la izquierda de la dirección, luego en "La conexión es segura" → "El certificado es válido". El visor muestra a quién se emitió el certificado, quién lo emitió, el periodo de validez y la cadena.
- Firefox: candado → "Conexión segura" → "Más información" → "Ver certificado".
- Safari: candado en la barra de direcciones → "Mostrar certificado".
El navegador es práctico para ver rápidamente la fecha de caducidad y el emisor, pero no es un veredicto definitivo: los navegadores guardan en caché los certificados intermedios y pueden "completar" una cadena rota que un rastreador o una app móvil rechazarán.
Cómo comprobar SSL desde la línea de comandos (openssl)
openssl viene incluido en macOS y Linux; en Windows lo obtienes, por ejemplo, con Git for Windows. El comando básico se conecta al servidor e imprime la cadena y el resultado de la verificación:
openssl s_client -connect example.com:443 -servername example.com </dev/null-servername envía el nombre de host (SNI). Sin él, un servidor que aloja varios sitios puede devolver el certificado de otro dominio y terminas persiguiendo un error que no existe. En la salida, busca Verify return code: 0 (ok) significa que la cadena está bien; 21 (unable to verify the first certificate) normalmente significa que el servidor no envía el intermedio; 10 (certificate has expired): caducado; 18 (self-signed certificate): autofirmado.
Para obtener las fechas, el sujeto y el emisor en una sola línea:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -checkend 1209600notBefore y notAfter son el inicio y el fin de la validez, -ext subjectAltName lista los nombres (OpenSSL 1.1.1 y posteriores), y -checkend 1209600 te dice si el certificado caduca en los próximos 14 días (1 209 600 segundos): una línea práctica para un cron job de monitoreo.
Para comprobar si el servidor aún acepta un protocolo antiguo, intenta conectarte usando solo esa versión: openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null. Si el handshake se completa, TLS 1.1 está habilitado en el servidor. Una salvedad: las versiones recientes de OpenSSL pueden rechazar versiones antiguas en el lado del cliente, y en ese caso un fallo no te dice nada sobre el servidor. Usa -tls1_2 y -tls1_3 para las versiones actuales.
Qué revisar en el informe
| Parámetro | Qué debe haber |
|---|---|
| Vigencia | Más de dos semanas de antelación; los certificados gratuitos duran unos tres meses y se renuevan automáticamente |
| Nombre en el certificado | Coincide con el dominio, incluida la variante con www |
| Cadena de confianza | Completa: sin el certificado intermedio, algunos clientes mostrarán un error |
| Protocolos | TLS 1.2 y 1.3; es mejor desactivar las versiones obsoletas |
| Emisor | Autoridad de certificación conocida, no un certificado autofirmado |
Qué hacer en caso de errores
- Caducado. Renueva el certificado y comprueba que la renovación automática realmente funciona.
- El nombre no coincide. Añade los dominios necesarios al certificado o configura uno aparte.
- Cadena incompleta. Sube el certificado intermedio al servidor.
- Contenido mixto. Cambia los enlaces a imágenes, estilos y scripts de http a https; de lo contrario, el navegador mostrará advertencias incluso con un certificado válido.
Errores de SSL: cómo se ven y cómo solucionarlos
| Problema | Qué ves | Solución |
|---|---|---|
| Certificado caducado | Chrome: NET::ERR_CERT_DATE_INVALID; openssl: certificate has expired | Vuelve a emitirlo y comprueba que la renovación automática funcione. Un caso frecuente: el archivo nuevo ya está en el disco, pero el servidor web no se recargó y sigue sirviendo el anterior. |
| El nombre no coincide | NET::ERR_CERT_COMMON_NAME_INVALID | Emite un certificado con todos los nombres de host en el SAN, por ejemplo, example.com y www.example.com. Un wildcard *.example.com cubre un nivel de subdominios, pero no example.com en sí ni a.b.example.com. |
| Cadena incompleta | Funciona en algunos navegadores y en otros muestra NET::ERR_CERT_AUTHORITY_INVALID; openssl: unable to verify the first certificate | Instala la cadena completa: el certificado del sitio más los intermedios. Con Let's Encrypt en nginx, apunta a fullchain.pem, no a cert.pem. |
| Certificado autofirmado | NET::ERR_CERT_AUTHORITY_INVALID; openssl: self-signed certificate | Reemplázalo por un certificado de una CA de confianza. Opciones gratuitas: Let's Encrypt o el certificado que emite tu hosting o CDN. |
| Solo TLS obsoleto | Normalmente ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Habilita TLS 1.2 y 1.3, desactiva SSL 3.0, TLS 1.0 y 1.1, y actualiza el servidor web y OpenSSL. |
| Reloj incorrecto | Un error de fecha en un certificado que en realidad es válido | Revisa el reloj del dispositivo del visitante o del servidor: la vigencia se compara con la fecha actual. |
Cuánto duran los certificados SSL
La vigencia máxima de los certificados TLS de confianza pública la establece el CA/Browser Forum, el organismo que reúne a autoridades de certificación y fabricantes de navegadores. Durante años el límite fue de 398 días. En abril de 2025 el foro aprobó la votación SC-081, que lo reduce por etapas, y la primera etapa ya está en vigor:
| Certificado emitido | Vigencia máxima |
|---|---|
| a partir del 15 de marzo de 2026 | 200 días |
| a partir del 15 de marzo de 2027 | 100 días |
| a partir del 15 de marzo de 2029 | 47 días |
El límite se aplica según la fecha de emisión: un certificado emitido antes sigue vigente hasta su fecha de vencimiento original. Los detalles están en la votación SC-081 en el sitio del CA/Browser Forum. Los certificados gratuitos de Let's Encrypt ya son de corta duración: según las preguntas frecuentes de Let's Encrypt duran 90 días (los certificados de 6 días son opcionales), y los de 90 días deben renovarse cada 60 días. La conclusión: renovar a mano una vez al año ya es cosa del pasado, la renovación debe automatizarse.
Renovación automática de Let's Encrypt: cómo comprobar que funciona
sudo certbot certificates
sudo certbot renew --dry-run
systemctl list-timers | grep certbotcertbot certificatesmuestra todos los certificados del servidor con su fecha de vencimiento.certbot renew --dry-runensaya la renovación en el servidor de pruebas (staging) de Let's Encrypt sin tocar los certificados en producción. Si el ensayo falla, la renovación real también fallará.- La renovación la activa un temporizador de systemd o una tarea de cron; con el paquete snap el temporizador es
snap.certbot.renew.timer. Si no existe ninguno de los dos, no hay renovación automática. - Para que el servidor web use el nuevo certificado, recárgalo después de la renovación:
--deploy-hook "systemctl reload nginx". - Motivos habituales por los que falla la renovación:
/.well-known/acme-challenge/está bloqueado por una redirección, una contraseña o una regla del firewall; o el dominio se movió a otro servidor o CDN mientras certbot sigue funcionando en el anterior.
Si tu hosting o CDN emite el certificado, la renovación normalmente corre por su cuenta, pero solo mientras el dominio apunte a ellos. Después de cualquier cambio de DNS, vuelve a revisar el certificado.
Monitoreo de certificados
- Alertas con anticipación. Usa un monitoreo externo o un script de cron con
openssl x509 -checkend: recibe la alerta al menos dos semanas antes del vencimiento. - Revisa de nuevo tras la renovación. Pasa el dominio por el verificador SSL: nuevas fechas, cadena completa, todos los nombres en el SAN.
- Registros de Certificate Transparency. Cada certificado público queda registrado en logs abiertos; al buscar tu dominio (por ejemplo en crt.sh) verás qué certificados se emitieron para él, incluidos subdominios olvidados y emisiones inesperadas.
- Auditorías periódicas. Shield es una revisión de seguridad de pago (una sola vez con cargo a tu saldo o con una suscripción de monitoreo); su grupo "TLS y certificado" cubre la validez y el vencimiento del certificado, TLS 1.0/1.1 obsoletos, la redirección de HTTP a HTTPS y HSTS.
Certificado gratuito o de pago
Para comprobar la validez no hay diferencia: tanto el navegador como el bot revisan la validez, no el precio. Los certificados gratuitos se emiten automáticamente y se renuevan solos, lo cual es suficiente para la gran mayoría de los sitios. Los certificados de pago tienen sentido cuando se necesita una verificación ampliada de la organización, un seguro o soporte para escenarios poco comunes. Lo principal es que la renovación automática funcione de verdad: un certificado caro vencido es peor que uno gratuito renovado a tiempo.
Qué relación tiene con la promoción
Https es un requisito básico: un sitio sin él pierde confianza y visitantes. Además, un error de certificado dificulta nuestras revisiones: la página puede quedar inaccesible para el rastreo. Un panorama completo de la seguridad lo ofrece Shield, y de los encabezados de seguridad hablamos en el artículo sobre encabezados de seguridad.
