Escribes la dirección de tu banco, aparece el candado y das por hecho que estás hablando con quien crees. Pero entre tu navegador y ese servidor hay una red que no controlas, llena de puntos donde alguien podría hacerse pasar por el sitio. La pregunta de fondo no es "¿está cifrada la conexión?", sino "¿estoy cifrando con quien de verdad quiero?". Esa es exactamente la pregunta que resuelven los certificados digitales y la infraestructura que los sostiene: la PKI.
El problema que resuelven
El cifrado asimétrico deja que un servidor publique su llave pública para que cualquiera pueda cifrarle mensajes que solo él, con su llave privada, puede leer. Elegante —pero deja un hueco enorme.
El cifrado asimétrico deja que un servidor publique su llave pública, pero surge una pregunta que el cifrado por sí solo no responde: ¿cómo sé que esa llave pública es de quien dice ser, y no de un impostor que se puso en medio?
Un certificado digital responde exactamente eso: le pone un sello de identidad a la llave pública, firmado por alguien en quien ya confías.
Sin certificados, un atacante en medio del camino podría entregarte su llave pública haciéndose pasar por el banco. Cifrarías felizmente… hacia el atacante. El certificado es lo que rompe ese engaño: ata la llave pública a un dominio concreto y lo respalda con una firma verificable.
Qué es un certificado digital
Un certificado digital es un documento electrónico que liga una
identidad —un dominio, por ejemplo banco.com— con su llave pública, y que
está firmado por una autoridad de confianza. Ese sello es lo que le
da valor: cualquiera puede afirmar ser banco.com, pero no cualquiera puede
producir una firma válida de una autoridad reconocida.
Dentro, un certificado contiene principalmente:
- El dominio (o dominios) para el que es válido.
- La llave pública del sitio.
- Las fechas de validez —desde cuándo y hasta cuándo—.
- La firma de la autoridad que lo emitió, que garantiza que nada de lo anterior fue alterado.
Todo eso viaja en un formato estándar llamado X.509 —el mismo que usan los certificados de HTTPS, de correo o de firma de código—. No necesitas leerlo a mano; tu navegador lo interpreta por ti en milisegundos.
Quién firma: las autoridades de certificación (CA)
Una autoridad de certificación (CA, por Certificate Authority) es una organización en la que los navegadores y los sistemas operativos confían por defecto. Su trabajo es verificar solicitudes y firmar certificados con su propia llave privada, poniendo su reputación detrás de cada firma.
Tu dispositivo trae preinstalada una lista de CA raíz de confianza —el llamado almacén de confianza (root store)—. Esas raíces son el punto de partida: todo lo que firmen ellas, directa o indirectamente, hereda su confianza.
Por eso confiar en un sitio no exige que lo conozcas de antes; basta con que su certificado descienda de una raíz que tu sistema ya conocía el día que lo instalaste.
Ese almacén no lo eliges tú a mano: lo mantienen los fabricantes de navegadores y sistemas operativos con criterios estrictos. Si una CA se porta mal, la pueden expulsar del almacén, y con ella dejan de valer todos los certificados que haya firmado.
La cadena de confianza
Las CA no firman los certificados de los sitios directamente con su raíz —esa llave es demasiado valiosa para exponerla a diario—. En su lugar montan una cadena:
- Existe una CA raíz, cuyo certificado ya está en tu dispositivo y en quien confías de base. Su llave privada se guarda con extremo cuidado, offline.
- La raíz firma uno o varios certificados intermedios. Estos son los que operan en el día a día, protegiendo a la raíz de la exposición.
- Los intermedios firman el certificado del sitio —el de "hoja" o leaf—, que es el que el servidor presenta al conectarte.
- Tu navegador verifica la cadena hacia arriba: del certificado del sitio al intermedio, del intermedio a la raíz, hasta aterrizar en una raíz de confianza.
Si en algún eslabón la firma no cuadra, la cadena se rompe, o el ascenso termina en una raíz que tu dispositivo no conoce, el navegador no confía. No hay atajos: o la cadena llega a una raíz de confianza, o no vale.
Cómo lo valida el navegador
Cuando te conectas por HTTPS, el servidor te entrega su certificado (y normalmente los intermedios). Tu navegador, en silencio, corre una lista de comprobaciones antes de mostrar el candado:
- Comprueba que el certificado no expiró y que no fue revocado —una CA puede invalidar un certificado antes de tiempo si, por ejemplo, se filtró su llave privada—.
- Comprueba que el dominio del certificado coincide con el que estás visitando. Un certificado de
banco.comno vale paraotro-sitio.com. - Verifica la firma siguiendo la cadena hasta una raíz de confianza, tal como vimos arriba.
- Si todo cuadra, muestra el candado y establece la sesión cifrada. Si algo falla, muestra la advertencia de "conexión no segura" y te frena.
Todo esto ocurre en el handshake, antes de que se cargue un solo byte de la página. Cuando ves el candado, esas cuatro comprobaciones ya pasaron.
Errores comunes
"El candado —o el certificado válido— significa que la empresa es legítima o de confianza." No necesariamente. Un certificado DV (validación de dominio), el más común, solo prueba que quien lo pidió controla el dominio, no quién es la organización detrás. Un sitio fraudulento puede tener un certificado perfectamente válido para su propio dominio. El certificado prueba control del dominio y habilita el cifrado; no acredita honestidad.
Alrededor de esa confusión central hay otros tropiezos habituales:
- Confundir "certificado válido" con "sitio confiable". El candado dice "la conexión es privada y hablo con quien controla este dominio", no "esta gente es honesta".
- Usar certificados autofirmados en producción. Un certificado que se firma a sí mismo no desciende de ninguna raíz de confianza: el navegador lo rechaza y acostumbra a los usuarios a saltarse advertencias.
- Ignorar la fecha de expiración. Un certificado caducado tumba el sitio para todos, de golpe. Es una de las causas de caída más comunes —y más evitables— en producción.
El ángulo banca
En banca, la PKI no se limita a consumir certificados públicos para las webs de cara al cliente. Puertas adentro, las instituciones operan su propia PKI interna para que los servicios se autentiquen entre sí antes de intercambiar nada.
- mTLS (TLS mutuo). En un servicio público, solo el servidor presenta certificado; el cliente no. En banca, entre servicios críticos se usa mTLS: ambos extremos presentan certificado y se validan mutuamente. Nadie habla con nadie sin acreditar identidad.
- Emisión, rotación y revocación controladas. La PKI interna emite certificados de vida corta, los rota de forma automática y puede revocarlos al instante si un servicio se compromete —sin depender de una CA pública externa—.
- Pinning. Para servicios críticos se "fija" (pin) qué certificado o qué CA se espera exactamente de la contraparte. Si aparece otro —aunque sea técnicamente válido—, se rechaza. Es una defensa directa contra suplantaciones y contra una CA comprometida.
La confianza en la web no es magia: es una cadena de firmas que alguien tiene que emitir, validar y renovar a tiempo. El candado es el resultado visible de esa cadena funcionando. En un banco, donde cada servicio se acredita ante el siguiente, esa cadena no se deja al azar —se gobierna—.
