El panel de seguridad: certificado, conexión y contenido mixto
Qué información da el panel de seguridad sobre la conexión y el certificado, cómo se diagnostica el contenido mixto, y qué comprobaciones no hace nadie por ti.
El candado de la barra de direcciones responde a una sola pregunta binaria y la respuesta casi siempre es que sí. El panel de seguridad responde a las preguntas que de verdad importan cuando algo falla: qué certificado presentó exactamente este origen, quién lo emitió, hasta cuándo vale, qué versión del protocolo y qué cifrado se negociaron, y cuáles de los treinta orígenes que carga la página tienen un problema que el candado no refleja. Es un panel que se abre pocas veces al año y que las pocas veces resuelve en dos minutos algo que de otra forma cuesta una tarde.
- Leer la información de conexión y de certificado de un origen concreto.
- Diagnosticar contenido mixto y distinguir el bloqueado del actualizado automáticamente.
- Explicar por qué un certificado válido en el navegador puede fallar en otro cliente.
- Comprobar la cadena de certificación y las fechas sin salir del navegador.
Lo que muestra el panel
Se abre por su nombre desde el menú de comandos, como todo. La vista principal resume el estado de la página y una lista lateral enumera todos los orígenes desde los que se ha cargado algo, cada uno con su propio estado. Esa lista es la parte valiosa: una página puede estar perfectamente servida y cargar recursos de un origen con un certificado a punto de caducar.
Al seleccionar un origen, el panel separa tres bloques de información.
El certificado. Para qué nombres es válido, quién lo emitió, y entre qué fechas. El campo de nombres alternativos es el que decide de verdad si un certificado sirve para un dominio, no el nombre común, que hace años que no se usa para validar. Un certificado emitido para un dominio que no incluye el subdominio concreto que estás usando falla aunque el dominio principal esté en la lista.
La conexión. La versión del protocolo negociada y la suite de cifrado. Aquí lo relevante en la práctica es detectar versiones antiguas: si un origen negocia una versión obsoleta del protocolo, funciona hoy y dejará de funcionar cuando el navegador la retire, cosa que ocurre con preaviso pero sin que nadie del equipo se entere.
Los recursos. Si todo lo que ese origen sirvió vino por una conexión segura. Es donde aparece el contenido mixto.
El panel de seguridad muestra el certificado tal y como lo validó este navegador, en esta máquina, con este almacén de confianza. Es una distinción que importa: un certificado emitido por una autoridad interna de la empresa se ve perfectamente válido en tu portátil, que tiene la raíz instalada, y falla en el móvil de un usuario que no la tiene. Si un problema de certificado aparece en un dispositivo y no en otro, la primera hipótesis es el almacén de confianza y no el servidor.
Contenido mixto
Contenido mixto es una página servida de forma segura que carga algo por una conexión no segura, y el navegador lo trata de dos maneras muy distintas según el tipo de recurso.
El contenido mixto activo —scripts, hojas de estilo, marcos, peticiones de red— se bloquea siempre. Un atacante que pudiera modificar ese recurso controlaría la página entera, así que no hay grado de tolerancia. El síntoma es un recurso que simplemente no está: el script no se ejecuta, el estilo no se aplica, y en el panel de red la petición aparece fallida.
El contenido mixto pasivo —imágenes, audio, vídeo— se actualiza automáticamente a la versión segura de la URL, y si esa no existe, se bloquea. Este comportamiento es reciente en términos históricos y sustituyó al de mostrar el recurso con una advertencia. El síntoma hoy es una imagen que no carga y una entrada en el panel de incidencias.
La forma rápida de encontrar todo el contenido mixto de una página no es el panel de seguridad sino el filtro del panel de red combinado con una comprobación del propio documento:
// Encuentra referencias inseguras en el documento y en las hojas de estilo
(() => {
const inseguras = [];
const atributos = ['src', 'href', 'action', 'data', 'poster', 'formaction'];
for (const el of document.querySelectorAll('*')) {
for (const attr of atributos) {
const v = el.getAttribute?.(attr);
if (v && v.toLowerCase().startsWith('http://')) {
inseguras.push({ tipo: el.tagName.toLowerCase(), atributo: attr, url: v.slice(0, 70), nodo: el });
}
}
const bg = el.style?.backgroundImage;
if (bg && bg.includes('http://')) {
inseguras.push({ tipo: el.tagName.toLowerCase(), atributo: 'style', url: bg.slice(0, 70), nodo: el });
}
}
for (const hoja of document.styleSheets) {
let reglas;
try { reglas = hoja.cssRules; } catch { continue; }
for (const r of reglas) {
if (r.cssText && r.cssText.includes('http://')) {
inseguras.push({ tipo: 'css', atributo: hoja.href || 'inline', url: r.cssText.slice(0, 70), nodo: null });
}
}
}
if (!inseguras.length) console.log('Sin referencias inseguras en el documento.');
else console.table(inseguras);
// Los recursos ya cargados dicen la verdad definitiva
const cargados = performance.getEntriesByType('resource')
.filter(e => e.name.startsWith('http://'))
.map(e => ({ recurso: e.name.slice(0, 70), tipo: e.initiatorType }));
if (cargados.length) { console.warn('Recursos cargados por conexion insegura:'); console.table(cargados); }
})();
La distinción entre las dos mitades del fragmento es útil: la primera encuentra referencias escritas en el documento, incluidas las que nunca se cargaron; la segunda encuentra lo que realmente viajó. Una URL insegura en un atributo de un elemento oculto es una bomba de relojería que estallará cuando alguien lo muestre.
Lo que este panel no comprueba
Merece la pena enumerar los límites, porque el panel da una sensación de completitud que no le corresponde.
No comprueba la cadena entera como lo haría otro cliente. Los navegadores toleran cadenas incompletas reconstruyéndolas desde certificados intermedios que ya tienen en caché de otras visitas. Un servidor que no envía el intermedio funciona en tu navegador y falla en un cliente recién arrancado. Es una de las causas más frecuentes de “funciona en el navegador y falla en el servidor de integración”, y no se detecta desde el navegador por definición: hay que probar con un cliente limpio.
No avisa de caducidades futuras. Muestra la fecha de expiración pero no la convierte en una alarma. Comprobar caducidades es trabajo de la monitorización, no de una inspección manual.
No dice nada sobre las cabeceras de seguridad de la respuesta. La política de seguridad de contenido, el transporte estricto, las políticas de aislamiento de origen: todo eso está en las cabeceras de respuesta del panel de red y en el panel de incidencias, no aquí. El panel de seguridad se ocupa del transporte, no de la política de la aplicación.
No refleja lo que ve un usuario con una configuración corporativa. Muchos entornos empresariales interceptan el tráfico con un certificado propio instalado en la máquina. En esas máquinas el panel mostrará el certificado del interceptor y todo parecerá correcto.
El candado significa exactamente una cosa: que el tráfico entre este navegador y el titular de este certificado no puede ser leído ni modificado por un tercero en el camino. No significa que el sitio sea legítimo, ni que el servidor sea el que crees, ni que los datos estén a salvo una vez llegan. Esa confusión tiene dos consecuencias muy concretas en el trabajo diario. La primera afecta a cómo se leen los incidentes: cuando un usuario reporta una advertencia de certificado, la hipótesis más probable no es que tu servidor esté mal, sino que hay algo entre medias. Un antivirus que inspecciona tráfico, un proxy corporativo, una red pública con portal cautivo, un reloj del sistema desajustado —un certificado perfectamente válido produce un error de caducidad si el reloj del cliente está adelantado un año— o una extensión del navegador. La comprobación que ordena el diagnóstico es pedir al usuario que abra el panel de seguridad y diga quién emitió el certificado: si el emisor no es la autoridad que tú contrataste, el problema no está en tu infraestructura y ninguna reconfiguración del servidor lo va a arreglar. La segunda consecuencia es de diseño: el cifrado del transporte protege el trayecto y no el destino, y por tanto no es una respuesta a la pregunta de dónde puedes poner un secreto. Un token en el código de la página viaja cifrado y llega íntegro a un sitio donde cualquiera puede leerlo con estas mismas herramientas. La regla que se deriva es dura y no tiene excepciones: todo lo que llega al navegador es público. Cifrado en tránsito, pero público en destino. Cada vez que alguien propone ocultar una clave ofuscándola en el paquete, o proteger una ruta escondiendo el enlace, o confiar en que una comprobación del cliente no se puede saltar, está confundiendo el candado con una garantía que el candado nunca prometió. Las herramientas que estás aprendiendo a usar en esta guía son, vistas desde ese ángulo, la demostración de por qué esa confusión es indefendible.