Cuando entras en la web de tu banco, el navegador no tiene forma de ver quién hay al otro lado del cable. Lo único que recibe es un certificado: un documento digital que dice «este sitio es de verdad tubanco.com». Pero cualquiera puede escribir un documento así. Lo que lo hace creíble es quién lo firma y una red de empresas, reglas y listas públicas que se vigilan entre sí. Esta guía explica, sin tecnicismos, qué le pasa a un certificado desde que se pide hasta que aparece el candado, y cómo decide tu navegador si es de confianza.
La idea en tres frases
- Un certificado es como un pasaporte. Lo emite una autoridad, la autoridad certificadora (GoDaddy, Let’s Encrypt, DigiCert…), después de comprobar que el sitio es quien dice ser.
- El navegador no conoce a todos los sitios, pero sí a las autoridades. Trae de fábrica una lista corta de autoridades de confianza, y se fía de lo que ellas firmen.
- Nada se hace a escondidas. Las reglas son públicas, las autoridades se auditan cada año y cada certificado emitido queda anotado en registros que cualquiera puede consultar.
Quién es quién
En la historia de un certificado intervienen cinco participantes. Cada uno vigila a otro, y esa es la clave: la confianza no depende de una sola empresa.
La analogía del pasaporte ayuda a ordenarlo. El sitio web es el viajero. La autoridad certificadora es la oficina que expide el pasaporte después de comprobar la identidad. Los registros públicos son un libro donde se anota cada pasaporte expedido, a la vista de todos. Los programas de confianza de Mozilla, Google, Apple y Microsoft hacen el papel de los países que deciden qué oficinas de pasaportes aceptan. Y tu navegador es el agente de la frontera, que revisa el documento cada vez que alguien llega.
La vida de un certificado, paso a paso
Sigamos un caso inventado: tutienda.com quiere el candado y le pide su certificado a GoDaddy, una de las autoridades más grandes. El proceso es el mismo con cualquier otra, y casi siempre lo hace un programa automático en minutos.
1. La petición. El servidor de la tienda genera dos claves que van juntas, como una cerradura y su llave. La clave privada se queda guardada en el servidor y no la ve nadie, ni siquiera GoDaddy. La clave pública se envía en la petición, junto con el nombre tutienda.com. El certificado, al final, no será más que esa clave pública con el nombre y la firma de GoDaddy.
2. La comprobación. GoDaddy no le pregunta a la tienda quién es: le pide que lo demuestre. Las formas habituales son colocar un archivo con un código concreto en la propia web, añadir un dato en la configuración del dominio (el DNS) o responder a un correo enviado a la dirección del dueño del dominio. Solo quien controla de verdad tutienda.com puede hacer cualquiera de las tres. Antes, GoDaddy mira además si el dueño del dominio ha publicado en su DNS un aviso que diga qué autoridades pueden emitirle certificados (un registro llamado CAA); si GoDaddy no está en esa lista, tiene prohibido seguir. Para los certificados de empresa, que muestran el nombre de la organización, se comprueba también que la empresa existe.
3. La anotación en público. Antes de entregar el certificado, GoDaddy lo envía a varios registros de transparencia (en inglés, Certificate Transparency): grandes libros públicos, llevados por empresas como Google, Cloudflare o Sectigo, donde queda constancia de cada certificado emitido en el mundo. Cada registro devuelve un justificante con la fecha y la hora, y esos justificantes viajan dentro del certificado. Ocurre en un instante: en un certificado real de GoDaddy que analizamos, los tres justificantes llevaban la hora de la emisión con un segundo de diferencia. Chrome no acepta ningún certificado sin ellos desde 2018, y Safari tampoco.
4. La firma. GoDaddy firma el certificado con la clave de una de sus autoridades intermedias. Su autoridad raíz, la que está en la lista de los navegadores, casi nunca se usa: se guarda desconectada, en cámaras protegidas, y solo sirve para firmar unas pocas intermedias. Así, si una intermedia tuviera un problema, se puede anular sin tocar la raíz, que tardaría años en reemplazarse en todos los dispositivos del mundo.
5. La instalación. La tienda coloca en su servidor su certificado y, junto a él, el de la intermedia de GoDaddy. Desde ese momento, cada visitante recibe los dos al conectarse.
6. La caducidad. Los certificados duran poco a propósito: si una clave se pierde o se roba, el daño tiene fecha de fin. Desde el 15 de marzo de 2026 ningún certificado puede durar más de 200 días; en marzo de 2027 serán 100 y en marzo de 2029, 47. Lo acordaron las autoridades y los navegadores en 2025, y en la práctica obliga a que la renovación sea automática.
Lo que hace tu navegador al entrar en la tienda
Cuando visitas tutienda.com, el servidor te envía su certificado y el de la intermedia. Tu navegador no consulta a GoDaddy ni pregunta a ningún servidor si la tienda es de fiar: lo resuelve él solo, con lo que ya tiene guardado.
Es como una cadena de recomendaciones. El certificado de la tienda dice «me recomienda la intermedia de GoDaddy», y la firma lo demuestra. El de la intermedia dice «me recomienda la raíz de GoDaddy». Y la raíz no necesita recomendación, porque el navegador ya la tenía en su lista de confianza. Si el sitio olvidara enviar la intermedia, la cadena quedaría rota y el navegador no podría llegar a la raíz; es uno de los errores de configuración más frecuentes.
Las firmas son lo que impide las trampas. Una firma digital se calcula a partir de todo el contenido del certificado, así que cambiar una sola letra (por ejemplo, el nombre del sitio) la invalida, y nadie puede fabricar una firma nueva sin la clave privada de la autoridad. Un impostor puede hacerse un certificado que diga tubanco.com, pero no conseguir que lo firme una autoridad de la lista sin demostrar antes que controla ese dominio.
¿Quién decide qué autoridades vienen de fábrica?
La lista de confianza no la elige el navegador al azar ni la elige cada usuario. Hay cuatro grandes listas, cada una con su propio programa de confianza, sus reglas y su equipo de revisión:
| Programa | Quién lo usa |
|---|---|
| Mozilla | Firefox y, además, la mayoría de las distribuciones de Linux y muchos programas que se conectan a internet, que copian su lista. La que trae Debian, por ejemplo, tiene 150 raíces. |
| Google (Chrome Root Store) | Chrome, con lista propia desde 2022 (en iPhone y iPad usa la de Apple) |
| Apple | Safari y todas las aplicaciones de iPhone, iPad y Mac |
| Microsoft | Windows, Edge y las aplicaciones de Windows |
Entrar en esas listas es difícil y lento: una autoridad nueva puede tardar años. Tiene que superar una auditoría independiente (de los esquemas WebTrust o ETSI), demostrar que cumple los requisitos básicos del CA/Browser Forum (el foro donde autoridades y navegadores acuerdan las normas comunes) y, en el caso de Mozilla, pasar una revisión pública en la que cualquiera puede opinar. Una vez dentro, la vigilancia sigue: auditoría cada año, y cualquier error, como un certificado mal emitido, hay que declararlo en público y explicar cómo se corrige.
Cuando una raíz entra o sale de la lista, el cambio te llega con las actualizaciones normales del navegador o del sistema. No hace falta hacer nada: por eso es tan importante tenerlos al día.
Dónde se comparte la información
La respuesta corta a «¿dónde se dice qué certificado es de confianza?» es: en varios sitios a la vez, y casi todos públicos. Cada uno guarda una parte de la información, y entre todos forman el sistema.
| Dónde | Qué guarda | Quién lo consulta |
|---|---|---|
| Requisitos del CA/Browser Forum | Las normas que toda autoridad debe cumplir: cómo comprobar un dominio, cuánto puede durar un certificado, cómo proteger las claves | Autoridades, auditores y navegadores |
| Informes de auditoría | El resultado de la revisión anual de cada autoridad | Los programas de confianza |
| Base de datos común (CCADB) | Todas las autoridades raíz e intermedias aceptadas, con sus auditorías y sus incidentes. La comparten los programas de confianza | Programas de confianza, investigadores, cualquier interesado |
| Registros de transparencia | Cada certificado emitido, con su fecha. Si alguien emite uno a tu nombre sin permiso, queda a la vista | Navegadores (piden los justificantes), dueños de dominios, investigadores |
| Listas de revocados | Los certificados anulados antes de caducar, por ejemplo porque se robó la clave | Navegadores, que reciben un resumen compacto |
| El DNS del dominio (registro CAA) | Qué autoridades puede usar cada dominio | Las autoridades, antes de emitir |
| La lista de confianza de tu equipo | Las raíces aceptadas, unas 150 | Tu navegador, en cada conexión |
Los registros de transparencia merecen un detalle más, porque son el invento que más ha cambiado el sistema. Antes de ellos, si una autoridad emitía por error o a escondidas un certificado para google.com, nadie se enteraba hasta que alguien lo detectaba en uso. Hoy, como Chrome y Safari rechazan cualquier certificado que no se haya anotado, emitir uno en secreto ya no sirve: o se anota y queda a la vista, o los navegadores no lo aceptan. Hay servicios gratuitos, como crt.sh, en los que puedes escribir un dominio y ver todos los certificados que se han emitido para él.
Cuando un certificado se anula antes de tiempo
A veces un certificado tiene que dejar de valer antes de caducar: la clave se ha filtrado, la empresa ha cerrado o se emitió por error. La autoridad lo revoca y lo añade a su lista de revocados. El problema es que tu navegador no puede preguntar a la autoridad en cada visita: sería lento y le contaría a la autoridad qué páginas visitas. Durante años se hizo así, con un sistema llamado OCSP, y por motivos de privacidad está desapareciendo: Let’s Encrypt, la autoridad más usada del mundo, lo apagó el 6 de agosto de 2025.
La solución actual es que el navegador reciba un resumen de todos los revocados y lo consulte sin salir de tu equipo: Firefox usa uno llamado CRLite, que se actualiza dos veces al día, y Chrome tiene sus propias listas, llamadas CRLSets. Y la otra mitad de la solución es la que ya vimos: con certificados de 47 días, un certificado robado deja de servir pronto aunque nadie lo revoque.
Cuando una autoridad pierde la confianza
El sistema funciona porque los programas de confianza están dispuestos a expulsar a una autoridad, por grande que sea. Ha pasado varias veces:
- DigiNotar (2011). Unos atacantes entraron en esta autoridad holandesa y emitieron certificados falsos, entre ellos uno para Google, que se usó para espiar a usuarios de Gmail en Irán. Todos los navegadores la retiraron en pocos días, y la empresa quebró ese mismo septiembre.
- Symantec (2017-2018). Tras años de certificados mal emitidos, Chrome y Firefox dejaron de confiar en ella por etapas. Symantec vendió su negocio de certificados a DigiCert.
- Entrust (2024). Por una larga serie de incumplimientos, Chrome dejó de aceptar los certificados que emitiera a partir de noviembre de 2024, y Mozilla y Apple hicieron lo mismo. Entrust acabó vendiendo esa parte del negocio a Sectigo.
- Chunghwa Telecom y Netlock (2025). Chrome dejó de aceptar sus certificados nuevos a partir de agosto de 2025, por lo que Google describió como un patrón de comportamiento preocupante.
Fíjate en cómo se hace normalmente: no se borra la raíz de golpe, sino que se deja de aceptar lo que la autoridad emita a partir de una fecha. Los certificados que ya tienen los sitios siguen funcionando hasta que caducan, lo que da tiempo a cambiarse de autoridad sin que nadie se quede sin web.
Qué puedes hacer tú
- Mira el certificado de un sitio. Pulsa el icono que hay a la izquierda de la dirección (el candado o el de los ajustes del sitio) y busca la opción de ver el certificado. Verás a quién se emitió, qué autoridad lo firmó, la cadena hasta la raíz y las fechas de validez.
- No ignores los avisos. Una pantalla de «La conexión no es privada» significa que algo de lo anterior ha fallado: el certificado ha caducado, es de otro nombre o no llega a ninguna raíz de la lista. En una web de compras o de tu banco, no sigas.
- No instales raíces que te pidan. Añadir una raíz a tu lista de confianza le da a su dueño el poder de hacerse pasar por cualquier sitio en tu equipo. Solo tiene sentido en un equipo del trabajo, cuando lo hace el departamento de informática, o en tus propias pruebas.
- Mantén el sistema y el navegador al día. Las raíces nuevas, las retiradas y las listas de revocados llegan con las actualizaciones.
- Recuerda qué promete el candado. Que hablas con el dominio que escribiste y que nadie escucha por el camino. No dice que el sitio sea honesto: una web de estafa también puede tener su certificado.
Resumen
| Pregunta | Respuesta |
|---|---|
| ¿Quién crea el certificado? | Una autoridad certificadora (GoDaddy, Let’s Encrypt, DigiCert…), después de comprobar que quien lo pide controla el dominio |
| ¿Cómo se sabe que nadie lo ha falsificado? | Por la firma de la autoridad: cualquier cambio la invalida |
| ¿Cómo sabe el navegador que la autoridad es de fiar? | Porque su raíz está en la lista de confianza que trae el navegador o el sistema |
| ¿Quién hace esa lista? | Los programas de confianza de Mozilla, Google, Apple y Microsoft, con auditorías anuales y las reglas del CA/Browser Forum |
| ¿Dónde se comparte la información? | En la base de datos común CCADB, en los registros públicos de transparencia y en las listas de revocados; a tu equipo llega con las actualizaciones |
| ¿Y si una autoridad falla? | Se la expulsa de las listas, y sus certificados nuevos dejan de aceptarse |
Si quieres ver lo mismo con más detalle técnico, con el apretón de manos de TLS, cómo se acuerda la clave de cifrado y cómo falla una verificación de verdad, lo tienes en HTTPS por dentro: del clic al candado.
Las cifras sobre la lista de raíces y los registros de transparencia se comprobaron el 18 de octubre de 2026 con openssl 3.5 sobre la lista de confianza de Debian 13 y sobre un certificado real emitido por GoDaddy. Las normas y fechas proceden de los requisitos básicos del CA/Browser Forum, la política del programa de raíces de Chrome, la política de raíces de Mozilla, la CCADB, el anuncio de Let’s Encrypt sobre el fin de OCSP y el artículo de Mozilla sobre CRLite.
Fuente: IETF, RFC 9162, «Certificate Transparency Version 2.0»