Certificado no confiable: tres causas aparte de la caducidad

Ayer tu aplicación cargaba sin problemas. Hoy alguien te manda una captura de un aviso del navegador a pantalla completa, que dice que la conexión no es privada, y te pregunta si te han hackeado la web. Abres el certificado y es válido hasta la próxima primavera. No ha caducado, y aun así el navegador dice que el certificado no es de confianza.

Lo obvio es renovarlo, y para esta pantalla es lo equivocado. Cada una de las tres causas de abajo le pasa a un certificado que ya está en fecha, así que una renovación te da una fecha de caducidad más lejana en un certificado que se sigue rechazando por otro motivo.

En nuestro artículo sobre la caducidad, el certificado es la licencia del escaparate que dice que esta tienda es de verdad la del cartel. El navegador de un visitante lee tres cosas en esa licencia antes de dejar pasar a nadie: la fecha, el nombre de la tienda para la que se emitió y la firma de quien la emitió. La caducidad es la fecha. Este artículo trata de las otras dos.

¿Por qué sale certificado no confiable si no ha caducado?

Porque falló el nombre o la firma, y el navegador levanta el mismo muro para cada una de sus comprobaciones.

Un certificado solo es de confianza si nombra exactamente la dirección que hay en la barra del visitante y lo firmó una autoridad en la que el navegador ya confía, con cada certificado intermedio enviado junto a él. Si falla cualquiera de las dos, Chrome muestra el aviso de que la conexión no es privada y Firefox el de un posible riesgo de seguridad, exactamente igual que con uno caducado.

Lo que cambia es la letra pequeña bajo el aviso. Léela antes de tocar nada:

Chrome muestra el mismo código para la segunda y la tercera fila, y por eso merece la pena abrir el propio certificado.

Si una sola persona te avisa y nadie más lo ve, pregúntale en qué red estaba. El código fuente de Chrome cita una red wifi que manda a sus usuarios a una página de acceso como una de las causas del error de nombre. Ese se resuelve en cuanto inicia sesión en la red.

¿Cómo veo lo que dice el certificado?

Ábrelo desde el aviso y lee dos campos: a quién se emitió y quién lo emitió.

En Chrome, haz clic en la indicación de alerta a la izquierda de la barra de direcciones (Not secure en un Chrome en inglés) y abre el certificado desde el panel que aparece. En Firefox, haz clic en Advanced en el aviso y luego en el enlace al certificado del sitio (así se llaman en un Firefox en inglés). Los dos navegadores llaman de forma distinta a los mismos campos:

• El campo que dice a quién se emitió el certificado (Issued To en un Chrome en inglés, Subject Name en Firefox) da el nombre para el que se hizo. La lista completa de nombres que cubre está bajo Subject Alternative Name, y esa lista es lo que el navegador compara con la dirección.
• El campo que dice quién lo emitió (Issued By en Chrome, Issuer Name en Firefox) da la autoridad que lo firmó.

Cada una de las tres causas se lee distinto ahí:

• El certificado nombra otra dirección. Es la causa 1.
• El titular y el emisor tienen el mismo nombre. Se firmó a sí mismo: es la causa 2.
• Nombra tu dirección, el emisor es una autoridad de la que has oído hablar, y el navegador lo rechaza igualmente. Es la causa 3, la cadena.

Causa 1: el certificado es para otra dirección

El certificado es auténtico y está en fecha, y se emitió para otro nombre. Es la licencia de otra tienda, colgada en tu escaparate.

Aparece de tres formas:

• Tu dominio apunta a un hosting que todavía no tiene certificado para él. El hosting responde con el certificado que tiene, emitido a un nombre suyo. La documentación de Lovable lo dice claramente: hasta que el certificado está listo, el navegador muestra un aviso de seguridad en lugar de tu web.
• El certificado cubre una forma de escribir tu dirección y el visitante escribió la otra. www.yourapp.com y yourapp.com son dos nombres para un certificado, y cada uno tiene que estar en su lista.
• Una parte de tu DNS todavía apunta a un sitio que dejaste. Un hosting antiguo, o la página de aparcamiento que mostraba tu registrador antes de que conectaras nada, responde en ese nombre con un certificado propio.

En Lovable y Vercel no compras ni instalas este certificado tú. El hosting emite uno por cada nombre que añades en sus ajustes de dominio, una vez que tu DNS apunta ese nombre hacia él. La documentación de Lovable añade que su hosting no usa en absoluto un certificado comprado a tu registrador. Añade las dos formas, apunta las dos al hosting y espera a que cada una aparezca como activa.

Causa 2: el certificado se firmó a sí mismo

Nadie responde por este certificado salvo el servidor que lo presenta. Es una licencia que el tendero imprimió en casa.

Todos los navegadores rechazan uno en una web pública, y deben hacerlo. Un comentario en el código fuente de Chrome da el motivo en una línea: un certificado autofirmado no ofrece ninguna defensa frente a un atacante situado entre tu visitante y tu aplicación.

Te lo encuentras en servidores que alguien configuró a mano: un servidor alquilado, una herramienta autoalojada, un ajuste de prueba que salió a producción con la aplicación. Un builder emite certificados de verdad para los dominios que le añades. Un certificado autofirmado en una aplicación alojada por un builder significa, por tanto, que algo distinto del builder está respondiendo en tu dirección. Comprueba adónde apunta tu DNS antes de cambiar nada más.

La solución es un certificado de una autoridad de verdad. Let's Encrypt los emite gratis, y es la autoridad que usa Vercel cuando emite el tuyo.

Causa 3: nunca se envió un eslabón de la cadena

El certificado es para tu dirección y lo firmó una autoridad de verdad, pero el servidor lo envió sin el certificado intermedio, así que el navegador no puede conectarlo con nadie en quien confíe. La licencia la firmó una sucursal, y en el escaparate falta la carta de la central que responde por esa sucursal.

Mozilla llama a un certificado intermedio que falta uno de los problemas de configuración de servidores más comunes. Firefox descarga ahora por adelantado una copia de cada certificado intermedio de confianza, para que sus usuarios dejen de encontrarse el error.

Eso es lo que hace que esta causa cueste verla: en tu portátil puede parecer que todo va bien mientras a otra persona le falla. Un navegador que tiene su propia copia del eslabón que falta rellena el hueco. Un software que solo usa lo que envía tu servidor no tiene con qué rellenarlo. Nuestro escáner es de ese tipo de software, y por eso puede marcar un certificado como no confiable mientras tu propio navegador muestra un candado.

En un builder la cadena se gestiona por ti. Falta en servidores configurados a mano, y ahí la solución es servir el certificado seguido del certificado intermedio, en un solo archivo. Si usas certbot de Let's Encrypt, ese archivo es fullchain.pem, y el error es apuntar tu servidor a cert.pem en su lugar. Para comprobarlo desde fuera, la prueba de servidor gratuita de SSL Labs señala un certificado intermedio que falta como un problema de la cadena.

El caso del dominio propio, paso a paso

Cuando conectas tu propio dominio a un builder, los visitantes ven este aviso hasta que el hosting tiene un certificado para tu nombre, y el aviso dice la verdad. Se acaba solo cuando se emite el certificado.

El orden, en Lovable:

1. Añade el dominio en Lovable. Configura yourapp.com y www.yourapp.com y los muestra por separado.
2. Cambia los registros DNS en tu registrador a los valores que te da Lovable. Según Lovable, la mayoría de los cambios están activos en pocas horas, y la propagación puede tardar hasta 72.
3. Lovable verifica el dominio y emite el certificado. Vercel funciona igual: demuestra a Let's Encrypt que el nombre es tuyo, automáticamente, siempre que el dominio apunte a Vercel.
4. Abre la web cuando el dominio aparezca como Live, que es lo que aconseja la propia Lovable.

Si el aviso sigue ahí después de 72 horas, Lovable te pide que contactes con su soporte. Hay dos ajustes que conviene revisar antes de escribir:

• Busca un registro CAA. Es una entrada DNS que indica qué autoridades pueden emitir certificados para tu dominio. Una que deja fuera a la autoridad de tu hosting bloquea el certificado, y un subdominio hereda los registros CAA del dominio padre cuando no tiene los suyos. El artículo sobre la caducidad se encuentra el mismo registro como motivo de que falle una renovación. Aquí impide que llegue a emitirse el primer certificado.
• Busca un proxy delante. Si tu DNS está en Cloudflare con la nube naranja activada en los registros que te dio tu hosting, responde Cloudflare en lugar de tu hosting. Lovable dice que entonces no puede verificar el dominio ni emitir certificados para él, y tanto Lovable como Vercel dicen que pongas esos registros en DNS only.

Qué encontramos en 30.879 aplicaciones

Ocho tenían un certificado en el que ningún navegador confiaría, y todas estaban en un dominio que su dueño había conectado.

En agosto de 2026 nuestro escaneo leyó el certificado de 30.879 aplicaciones en producción: 29.927 en el subdominio propio de un builder y 952 en un dominio propio. Los ocho certificados no confiables estaban entre las 952, algo menos de uno de cada cien. Ninguna de las aplicaciones en el subdominio de un builder tenía uno, lo que encaja con todo lo anterior. En la dirección propia del builder, el nombre y el certificado son del builder.

Nuestro hallazgo registra que el certificado falló, pero no cuál de las tres causas fue, así que no podemos decirte cómo se reparten las ocho. Los certificados caducados o a punto de caducar del mismo escaneo se cuentan en el artículo sobre la caducidad.

Para comprobar tu propia aplicación, nuestro escaneo gratuito lee desde fuera el certificado que envía tu servidor y nombra este hallazgo cuando lo ve. Tarda unos 20 segundos y no necesita cuenta.

Enterarte la próxima vez que algo cambie

Un certificado pasa de confiable a rechazado cuando cambia algo a su alrededor: un dominio nuevo, una mudanza de DNS, un proxy activado. La comprobación que importa es la que se hace después del cambio.

Escanea tu aplicación gratis para ver lo que recibe hoy el navegador de un visitante.

• Lee desde fuera el certificado que envía tu servidor, junto con otras ocho comprobaciones.
• Nombra el hallazgo cuando el certificado no es de confianza, y cuando ha caducado o está a punto de hacerlo.
• Unos 20 segundos, y sin cuenta.

Reeve Monitor para enterarte poco después del cambio.

• Comprueba tu aplicación cada 60 segundos, y un certificado en el que no puede confiar cuenta como una caída de tu aplicación. Te avisa, por tanto, como con cualquier otra caída.
• Repite las nueve comprobaciones cada hora y te envía un correo cuando baja tu nota.
• Cubre hasta tres aplicaciones.

Qué hacer ahora mismo

Cuando el aviso ha desaparecido y la aplicación sigue sin cargar, la siguiente pregunta es si es tu aplicación o la plataforma que hay debajo, y ¿se ha caído Supabase o es tu aplicación? explica cómo distinguirlo.