TLS sin magia: certificado, SNI, cadena y expiración
Qué mira tu cliente cuando valida HTTPS: nombre del sitio, certificado, cadena de confianza, fechas y errores comunes.
Antes de empezar necesitás
- Haber hecho el lab de una request no es magia
- Tener curl y openssl disponibles
Al terminar vas a poder
- Leer issuer, subject, SAN y fechas de un certificado
- Entender por qué SNI importa en hosts compartidos
- Distinguir certificado vencido, nombre incorrecto y CA no confiable
- Dejar evidencia sin capturar secretos
HTTPS no significa “seguro” por magia. Significa que el cliente pudo negociar TLS y validar un certificado para el nombre que quería visitar. Si entendés esa validación, los errores dejan de ser misteriosos.
Mirá el certificado
openssl s_client abre la conexión TLS y te muestra la cadena. -servername manda SNI: el nombre que el cliente quiere validar.
openssl s_client -servername example.com -connect example.com:443 </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -datesCampos clave:
subject para quién fue emitido
issuer quién lo emitió
notBefore desde cuándo vale
notAfter hasta cuándo vale
SAN nombres válidos del certificadoCurl como diagnóstico rápido
curl -Iv https://example.comBuscá líneas de TLS, issuer y expire date. Si falla, no saltes directo a -k: primero entendé qué validación falló.
Errores comunes
certificado vencido fecha actual > notAfter
nombre incorrecto dominio no aparece en SAN
CA no confiable cadena no llega a una raíz confiable
SNI ausente o incorrecto el servidor entrega otro certificadoLo que practicás en este lab
Llevátelo a tu repo si querés, pero no es obligatorio: es tu aprendizaje.
- Salida de openssl s_client redactada a los campos importantes
- Tabla con subject, issuer, SAN y expiración
- Writeup: qué error esperarías si el nombre no coincide
Reto
Elegí un dominio público, inspeccioná su certificado y escribí qué nombre valida el navegador, quién lo emitió y cuándo vence.
Resolvelo y escribí dos líneas explicando qué pasó. Con eso lo fijás.