Certificados, cadena y caducidad

Cuando el navegador recibe un certificado hace tres comprobaciones independientes. La primera, que el nombre que el usuario visitó figure entre los nombres alternativos (SAN) del certificado; los navegadores modernos no miran el campo CN. La segunda, que la fecha actual caiga dentro del período de validez. La tercera, que pueda construir una cadena de firmas desde ese certificado hasta una autoridad raíz que ya lleva instalada.

Un fallo en cualquiera de las tres produce el aviso de «conexión no privada», y cada una se arregla en un sitio distinto: el nombre, al emitir el certificado; la fecha, al renovar; la cadena, en lo que el servidor entrega.

Un servidor puede atender varios nombres con un solo certificado, siempre que todos estén en los nombres alternativos. Si un nombre se añade al servidor y nadie reemite el certificado, el navegador lo detecta en cada visita. Los reportes de los navegadores del propio cliente lo dicen con más claridad que cualquier teoría.

Abre certificado-tienda.txt para ver los nombres que cubre y errores-de-clientes.txt para ver dónde fallan los visitantes.

El certificado de un sitio lo firma una autoridad intermedia, y esa intermedia la firma una raíz. El servidor debe entregar la hoja y los intermedios (no la raíz, que el cliente ya tiene). Los navegadores de escritorio suelen completar por su cuenta un intermedio que falta, así que el problema pasa inadvertido en las pruebas del equipo y aparece donde el cliente no lo hace: una aplicación móvil, un programa que consume la API, otro servidor.

Es un buen ejemplo de por qué la revisión no se queda con «en mi navegador funciona». Abre cadena-api.txt y lee qué se entrega y qué se esperaba.

La caducidad no es una sorpresa: es una fecha escrita en el certificado. Se calcula contra la fecha de corte del informe, no contra el día en que se lee. Los certificados públicos cada vez duran menos: el foro de autoridades y navegadores (CA/Browser Forum) acordó, en la ballot SC-081v3, bajar el máximo de validez de los certificados nuevos de 398 días a 200 desde el 15 de marzo de 2026, a 100 desde el 15 de marzo de 2027 y a 47 desde el 15 de marzo de 2029. Con vidas tan cortas, renovar a mano deja de ser sostenible.

Abre inventario-certificados.txt: el corte es del 2026-10-12. Cuenta los días hasta el vencimiento del certificado de la tienda.

Tres certificados, tres situaciones: la API renueva sola por ACME (el protocolo que usan las autoridades como Let's Encrypt para emitir y renovar sin intervención humana); la tienda se renueva a mano y vence en pocas semanas; el panel está autofirmado y ya venció. El informe no solo señala lo que está mal: prioriza y recomienda algo que evite que se repita.

El patrón que se repite es el humano: lo que depende de que alguien se acuerde, vence. La recomendación de fondo no es una renovación más, es quitar la dependencia de la memoria.