¿Qué comprueba esta prueba?
El KernelHost SSL Checker recupera el certificado del servidor mediante un handshake TLS desde nuestro nodo de Fráncfort y muestra los campos más importantes, sin llamadas a terceros. Esto es lo que se comprueba y se muestra:
- Emitido para y por: Common Name (Subject CN), el Subject DN completo y el Issuer (la CA que firmó el certificado).
- Periodo de validez: Fecha de inicio y fin en UTC más los días restantes. Indicador de color: verde (>30 días), naranja (7 a 30 días), rojo (menos de 7 días o ya caducado).
- Subject Alternative Names (SANs): Lista completa de hostnames cubiertos por el certificado, incluidas las entradas wildcard.
- Coincidencia de hostname: Verifica que el dominio introducido está realmente cubierto por el Common Name o un SAN wildcard (RFC 6125).
- Clave y firma: Algoritmo de clave pública (RSA, ECDSA), tamaño de clave en bits o nombre de curva y algoritmo de firma.
- Fingerprints y número de serie: Fingerprint SHA-256 y SHA-1 del certificado codificado en DER más el número de serie en hexadecimal.
- Cadena completa: Todos los certificados que el servidor entregó durante el handshake, con subject, issuer y rol (leaf, intermediate, root).
Errores SSL frecuentes y qué significan
Los navegadores muestran a menudo errores crípticos como NET::ERR_CERT_DATE_INVALID o SSL_ERROR_BAD_CERT_DOMAIN. Aquí las causas raíz más frecuentes y cómo solucionarlas:
- Certificado caducado: La fecha notAfter está en el pasado. Los navegadores bloquean la página por completo. Solución: renovar el certificado. Con Let's Encrypt esto ocurre automáticamente cada 60 días con certbot o acme.sh.
- Hostname no coincide: El hostname no aparece ni en el Common Name ni en ningún SAN. Solución: al reemitir, añadir como SAN cada dominio y subdominio que se necesite.
- Autofirmado o CA desconocida: El Issuer no es una root CA de confianza. Los navegadores muestran NET::ERR_CERT_AUTHORITY_INVALID. Solución: obtener un certificado de una CA reconocida como Let's Encrypt, ZeroSSL, Sectigo o DigiCert.
- Cadena incompleta: El servidor solo entrega el certificado leaf sin los intermedios. Los navegadores móviles y dispositivos antiguos fallan. Solución: configurar la full chain (fullchain.pem) en su servidor web.
- Clave o firma débil: RSA por debajo de 2048 bits o firmas SHA-1 ya no se aceptan. Solución: reemitir con RSA 2048+ o ECDSA P-256.
- Mixed content y trampa HSTS: Si previamente envió un encabezado HSTS válido y luego caduca el certificado, los visitantes no pueden saltarse el aviso. Acción inmediata: renovar el certificado; en emergencia reducir el HSTS max-age.
Let's Encrypt vs. certificados comerciales
Let's Encrypt es una CA gratuita y automatizada gestionada por ISRG. Los certificados son técnicamente idénticos a los DV comerciales y reconocidos por todos los navegadores modernos.
¿Cuándo tiene sentido un certificado de pago? Realmente solo en casos especiales:
- Extended Validation (EV): Antes mostraba una barra verde, hoy apenas se ve. Solo merece la pena para bancos o plataformas de trading cuando la ley lo exige.
- Wildcard sin DNS challenge: Let's Encrypt solo soporta wildcards mediante DNS-01 challenge. Sin acceso API al DNS, ZeroSSL Premium o Sectigo son alternativas.
- Garantía y seguro: Las CAs comerciales ofrecen importes de seguro en caso de mis-issuance. En la práctica rara vez relevante, pero algunos marcos de compliance lo exigen.
KernelHost Webhosting y cPanel incluyen integración gratuita de Let's Encrypt de serie. Los certificados se renuevan cada 60 días vía AutoSSL sin que tenga que hacer nada. Los certificados wildcard mediante DNS challenge también son posibles desde que el dominio está alojado en el DNS de KernelHost.
TLS 1.2 vs. TLS 1.3
TLS 1.2 es el estándar desde 2008, TLS 1.3 se publicó como RFC 8446 en 2018 y se ha desplegado ampliamente desde 2020. Las versiones anteriores (SSL 3.0, TLS 1.0, TLS 1.1) son inseguras y deben deshabilitarse en la configuración del servidor.
Lo que TLS 1.3 hace mejor:
- Handshake más rápido: 1-RTT en lugar de 2-RTT, más 0-RTT opcional para resumption. Notablemente más rápido en páginas con mucho TLS.
- Conjunto de cipher más limpio: Solo 5 cipher suites AEAD permitidos. No más intercambio de claves RSA; siempre forward secrecy.
- Handshake cifrado: El propio certificado del servidor se transmite cifrado. Con ESNI/ECH incluso el SNI permanece privado.
- Retrocompatible: Los servidores pueden ofrecer TLS 1.2 y 1.3 en paralelo. Los navegadores negocian automáticamente la versión común más alta.
¿Qué significa un certificado caducado?
Un certificado SSL caducado significa concretamente: los navegadores muestran un aviso a pantalla completa y bloquean el sitio. En la mayoría de casos los visitantes no pueden continuar, especialmente con un encabezado HSTS activo.
Consecuencias para el operador:
- Pérdida de ranking en Google (HTTPS es un factor de ranking y se evalúan señales de confianza).
- Los servidores de correo (MX/SMTP con STARTTLS) rechazan conexiones entrantes; los correos rebotan o se entregan con retraso.
- Los clientes API y apps móviles con certificate pinning se rompen y pueden necesitar una actualización.
HSTS, CAA y OCSP stapling
Un certificado válido es solo el principio. Tres mecanismos extra elevan la seguridad TLS al nivel best practice:
- HSTS (HTTP Strict Transport Security): Encabezado que obliga a los navegadores a usar solo HTTPS de ahora en adelante. Recomendado: max-age=63072000; includeSubDomains; preload (dos años, todos los subdominios, lista preload). Cuidado al activar: una mala configuración no es reversible mientras corra max-age.
- CAA (Certification Authority Authorization): Registro DNS que define qué CAs pueden emitir certificados para su dominio. Ejemplo: 'kernelhost.com. CAA 0 issue "letsencrypt.org"' evita la mis-issuance por otras CAs.
- OCSP stapling: El servidor web entrega la respuesta de estado de revocación de la CA, en lugar de que cada navegador pregunte por separado a la CA. Más rápido para los visitantes y suave con la infraestructura CA. Apache: SSLUseStapling On, nginx: ssl_stapling on.
Privacidad
El KernelHost SSL Checker se ejecuta enteramente en nuestro nodo de Fráncfort sin llamadas a terceros:
- Sin reenvío de su entrada a APIs externas (ni SSL Labs, ni Hardenize, ni Cryptomon).
- Sin almacenamiento del dominio comprobado más allá del logging estándar de peticiones (log de servidor web, retención de 14 días).
- Filtro anti-SSRF que bloquea peticiones a rangos IP privados, loopback y link-local.
- Rate-limit por IP contra abusos. hCaptcha opcional al enviar.