Certificado SSL caducado: lo que ven tus visitantes

Un certificado caducado no produce una advertencia discreta. Produce una página entera, generalmente roja, que explica que la conexión no es privada y que puede que unos atacantes intenten robar su información. La mayoría de los visitantes no la cruzan. Muchos concluyen que el sitio ha sido pirateado.

Mientras tanto, su servidor está perfectamente. Sirve las páginas exactamente igual que ayer, responde en unos milisegundos, y ninguno de sus registros señala nada.

El mensaje exacto le dice cuál de los cuatro problemas tiene

Antes de tocar nada, lea el código de error mostrado bajo el mensaje. Los navegadores lo esconden tras un enlace «avanzado», y es él quien contiene toda la información.

Las dos primeras líneas se corrigen con un comando. La tercera es la más taimada y merece su propia sección. La cuarta no es en absoluto un problema de certificado.

Por qué le ocurre a sitios que funcionan

El recordatorio salió hacia una dirección que nadie lee. Las autoridades de certificación avisan por correo, a la dirección introducida durante la emisión: a menudo un buzón genérico, a veces un desarrollador que se fue hace dos años.

La renovación automática ha fallado en silencio. La tarea está programada y termina en error. Nada cae con estrépito: el certificado simplemente deja de sustituirse. Es la causa más frecuente en los servidores modernos, y tiene tres variantes clásicas.

El certificado se ha renovado pero no se ha desplegado. Un archivo nuevo existe en el disco, con fecha de hoy, perfectamente válido. El servidor web conserva el antiguo en memoria, porque nadie lo ha recargado. Realmente exasperante, y muy corriente.

Se ha olvidado un subdominio. El certificado cubre ejemplo.com y www, pero no el tienda. que usted añadió en marzo. El sitio principal va bien, y una parte del tráfico se estrella contra un muro.

Lo que hace un visitante ante esa página

No lee el código de error. Ve un candado tachado, un fondo rojo, y una frase que habla de robo de información. Tres reacciones se reparten lo esencial: cerrar la pestaña, volver a los resultados de búsqueda y hacer clic en el siguiente, o escribir a alguien para señalar que su sitio ha sido pirateado.

Ninguna de esas tres reacciones se repara a posteriori. Es lo que distingue esta avería de un error de servidor ordinario: una página que devuelve un código 500 o 503 inquieta a un visitante; una página que anuncia un intento de robo le hace huir y le deja un recuerdo.

Desconfíe de las cifras que circulan sobre la proporción de gente que pasa de largo: vienen de muestras antiguas y de contextos que no son el suyo. Lo seguro es que el botón para continuar está deliberadamente escondido tras dos clics, y que el diseño de esa página busca exactamente que nadie la cruce.

La media jornada que sale más cara

El bloqueo aparece en el instante exacto de la caducidad, a menudo de noche, a menudo un fin de semana, porque es entonces cuando han caído los noventa días. Al tiempo que alguien se da cuenta el lunes por la mañana, el sitio lleva treinta y seis horas mostrando una advertencia de seguridad a cada visitante.

Nadie le llamará durante ese tiempo: sus herramientas internas no verán nada, y su alojador tampoco, ya que desde su punto de vista la máquina responde perfectamente. Es la avería que más se parece a una avería sin serlo, y por eso corresponde al mismo reflejo que los quince primeros minutos de un incidente: mirar desde fuera antes de mirar el código.

Verificar en treinta segundos

Un solo comando da la fecha de caducidad del certificado realmente presentado al público, que no siempre es el que anda por su disco:

echo | openssl s_client -servername ejemplo.es -connect ejemplo.es:443 2>/dev/null \
  | openssl x509 -noout -dates -subject

notAfter da el vencimiento, subject y los nombres alternativos dicen qué hosts están cubiertos. Repita el comando para cada subdominio que sirva: cada uno es una pregunta distinta. Ejecútelo además desde una máquina que no sea la suya: una caché local o una entrada en su archivo de hosts puede mostrarle un resultado que ningún visitante obtiene jamás.

Si no tienes un terminal a mano, o solo quieres la cifra: nuestro lector de certificados hace lo mismo desde el navegador, y te da la fecha, los hosts cubiertos y el estado de la cadena.

El caso de la cadena incompleta

Es la trampa que más tiempo hace perder, porque no se ve en la máquina de quien verifica.

Un certificado no está solo: está firmado por un intermedio, firmado a su vez por una raíz. Su servidor debe servir el certificado y el intermedio. Si olvida el segundo, los navegadores de escritorio suelen salir del paso, porque han guardado el intermedio en caché durante una visita anterior a otro sitio. Los móviles, en cambio, rechazan.

Resultado: el sitio funciona perfectamente en su puesto, y muestra una advertencia a una parte de sus visitantes. La prueba se hace desde un teléfono con datos móviles, o con el comando de arriba desde una máquina que nunca ha visitado el sitio.

Lo que ha cambiado la vida útil corta

Hace diez años, un certificado duraba un año o más, y el recordatorio en una agenda compartida hacía el trabajo. Los certificados gratuitos de hoy duran noventa días, y la tendencia general va hacia duraciones aún más cortas, por buenas razones de seguridad.

Eso desplaza por completo el problema. Una renovación anual es un acontecimiento del que alguien se acuerda; una renovación trimestral es una rutina automática que nadie mira. La pregunta ya no es, pues, «quién piensa en renovar» sino «quién verifica que el automatismo sigue funcionando».

Es un vuelco que merece enunciarse, porque vuelve inútiles dos viejos reflejos. Anotar la fecha de caducidad en una agenda ya no sirve de nada: cambia cuatro veces al año. Fiarse del registro de la renovación tampoco: las tres averías clásicas dejan allí un rastro que nadie abre, y la tercera ni siquiera deja un error.

Queda una sola verificación que conserva sentido, y es la que mira desde fuera, como lo haría un visitante.

Lo que realmente lo evita

Vigilar la fecha de caducidad, no la tarea de renovación. Una verificación que lee el certificado presentado por su servidor y cuenta los días restantes dice la verdad: ve el certificado que recibiría un visitante, no el que existe en el disco. Las tres causas de arriba acaban todas en el mismo sitio, y esa medida las atrapa a las tres.

Alertar con verdadero margen. Treinta días, luego siete, luego uno. Treinta días bastan para reparar con calma una renovación rota; un día basta para recuperar un despliegue que no ha recargado.

Verificar cada nombre de host que sirve. Cada subdominio es una pregunta de certificado distinta, y el que se olvida es siempre el que se añadió después.

Poner una dirección humana en el certificado. No cuesta nada y es la última línea de defensa cuando todo lo demás se ha olvidado.

Lo que no es

No es un pirateo, y decírselo con claridad a quien se lo señala evita una hora de pánico inútil. No es una avería de servidor: nada que reiniciar, nada que restaurar. Y no es en primer lugar un problema de posicionamiento.

Lo que HTTPS cambia realmente para los motores es más modesto de lo que la urgencia de esta página deja creer. La razón para reparar un certificado es el visitante que ve rojo, no el algoritmo.