Infraestructura de clave pública, explicada.

La Infraestructura de clave pública (PKI) es la maquinaria que responde a una pregunta engañosamente difícil: ¿cómo establecen confianza dos partes que nunca se han visto, sobre una red en la que cualquiera puede hacerse pasar por cualquiera? Es el sistema que hay debajo del candado de tu navegador, el visto bueno que dice que un programa procede de verdad de su editor, y la firma que demuestra que un correo no se manipuló en tránsito. Quítale las siglas y la PKI son en realidad tres ideas trabajando juntas: una relación matemática entre dos claves, una forma de demostrar autoría sin revelar un secreto, y una red de partes de confianza que avalan quién es dueño de qué clave. Este artículo construye esa imagen desde cero, y va de la mano con nuestro artículo hermano sobre certificados TLS y Certificate Transparency, que cubre con más profundidad la cadena de confianza específica de la web.

El par de claves en el centro de todo

La PKI se construye sobre criptografía asimétrica —un par de claves relacionadas matemáticamente, una pública y una privada, donde una operación hecha con una clave solo puede revertirse o verificarse con la otra. Cubrimos la mecánica más profunda de la criptografía simétrica frente a la asimétrica en criptografía que sí puedes usar; la versión corta basta aquí para construir sobre ella: genera un par de claves una vez, mantén la clave privada en secreto y no dejes que salga jamás de tu control, y entrega la clave pública libremente a absolutamente cualquiera.

La relación entre las dos claves desbloquea dos capacidades distintas, y es fácil confundirlas:

En la práctica, los algoritmos del mundo real son RSA o esquemas de curva elíptica como ECDSA y Ed25519 —las matemáticas difieren, pero los papeles de «la clave pública cifra o verifica» y «la clave privada descifra o firma» se mantienen en todos ellos.

Firmas digitales: demostrar autoría sin un secreto compartido

Una firma digital es lo que permite a la PKI demostrar autenticidad e integridad al mismo tiempo, y funciona en tres pasos. Primero, el firmante pasa el mensaje por una función hash criptográfica, produciendo una huella corta y de longitud fija del contenido. Segundo, el firmante cifra ese hash con su propia clave privada: ese hash cifrado es la firma. Tercero, cualquiera que tenga la clave pública del firmante puede descifrar la firma para recuperar el hash original, volver a calcular por su cuenta el hash del mensaje que recibió, y comparar ambos. Si coinciden, dos cosas son ciertas a la vez: el mensaje vino de alguien que posee esa clave privada, y el mensaje no se ha alterado ni en un solo byte desde que se firmó —cambiar cualquier cosa del contenido cambia por completo su hash, rompiendo la coincidencia.

Esto le da a la PKI tres propiedades que las simples contraseñas o secretos compartidos no pueden ofrecer por sí solos:

• Autenticidad — la firma solo podría haberla producido quien posee la clave privada.
• Integridad — cualquier manipulación del contenido firmado, por pequeña que sea, invalida la firma.
• No repudio — suponiendo que la clave privada no estuviera comprometida, el firmante no puede negar de forma creíble haberlo firmado, porque nadie más podría haber producido una firma válida.

Fíjate en lo que una firma no demuestra por sí sola: no dice nada sobre quién es en realidad, en el mundo real, el propietario de la clave. Un par de claves generado hace cinco minutos por cualquiera, en cualquier lugar, puede producir firmas perfectamente válidas. Vincular una clave pública a una identidad real verificada es precisamente el trabajo de la siguiente pieza: el certificado.

Certificados: vincular una clave a una identidad

Un certificado digital es una estructura de datos pequeña y firmada que dice, en esencia, «esta clave pública pertenece a esta identidad, y yo —una parte de confianza— lo avalo». El formato dominante es X.509, y todo certificado con el que te vayas a encontrar, ya sea de un sitio web, de un programa firmado o de una dirección de correo, lleva aproximadamente los mismos campos básicos:

Ese último campo es todo el truco: la autoridad de certificación no se limita a afirmar el vínculo entre clave e identidad, sino que firma criptográficamente esa afirmación usando su propia clave privada —lo que significa que verificar un certificado es, en sí mismo, solo otra comprobación de firma, encadenada un nivel más arriba.

Autoridades de certificación y la cadena de confianza

Una autoridad de certificación (CA) es una organización cuyo trabajo es verificar que quien solicita un certificado controla de verdad la identidad —un dominio, una dirección de correo, una organización— que dice poseer, y después emitir un certificado firmado que lo atestigüe. Tu navegador, sistema operativo y cliente de correo vienen cada uno con una lista seleccionada de CA raíz en las que confían por defecto. Todo certificado que vayan a aceptar tiene que remontarse hasta una de esas raíces a través de una cadena ininterrumpida de firmas: una CA raíz firma el certificado de una CA intermedia, y esa intermedia firma el certificado real que se te presenta día a día. Las claves raíz se mantienen fuera de línea y se usan lo menos posible, precisamente porque una raíz comprometida sería catastrófica —si en cambio se compromete una intermedia, puede revocarse y sustituirse sin tocar la raíz en absoluto.

Este modelo de cadena de confianza, y la mecánica concreta de cómo se aplica a los certificados web —incluidos los niveles de validación de dominio, de organización y extendida, y los registros de Certificate Transparency que mantienen honestas a las autoridades de certificación— se cubre en detalle en certificados TLS y Certificate Transparency. Lo que importa aquí es el patrón general: la confianza no viene de que un certificado concreto sea evidentemente correcto por sí mismo, viene de una cadena verificable de firmas enraizada en un pequeño conjunto de partes que un enorme número de sistemas independientes han acordado, de antemano, confiar.

Dónde se usa realmente la PKI

TLS es la aplicación más visible de la PKI, pero el mismo modelo de clave pública más certificado hace funcionar en silencio varios otros sistemas con los que la mayoría de la gente interactúa a diario:

Los certificados de cliente merecen mención aparte porque invierten la dirección habitual: en la navegación TLS normal, el servidor te demuestra su identidad a ti. En TLS mutuo (mTLS), ambas partes presentan certificados, de modo que el servidor también puede verificar exactamente qué dispositivo o usuario se está conectando —el modelo detrás de los inicios de sesión con tarjeta inteligente, muchas VPN corporativas y la autenticación servicio a servicio dentro de la propia infraestructura de una empresa.

Generar e inspeccionar un certificado tú mismo

Nada de esto requiere un acceso especial para observarlo: todo el ciclo de vida de un par de claves y un certificado está a un puñado de comandos de OpenSSL de distancia, y recorrerlo una vez convierte el diagrama abstracto de más arriba en algo concreto. Genera una clave privada, solicita un certificado para ella, y después mira exactamente qué campos acaban dentro:

# Genera una clave privada de curva elíptica (la clave pública se puede derivar de ella)
$ openssl ecparam -name prime256v1 -genkey -noout -out private.key

# Crea una Certificate Signing Request (CSR) — lo que le entregarías a una CA real
$ openssl req -new -key private.key -out request.csr -subj "/CN=example.com"

# Para pruebas locales, autofírmalo en vez de enviarlo a una CA
$ openssl x509 -req -in request.csr -signkey private.key \
    -out selfsigned.crt -days 365

# Inspecciona los campos reales de cualquier certificado
$ openssl x509 -in selfsigned.crt -noout -text | head -12
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4a:1f:...
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=example.com
        Validity
            Not Before: Jul 22 00:00:00 2026 GMT
            Not After : Jul 22 00:00:00 2027 GMT
        Subject: CN=example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey

Un certificado autofirmado como este lleva exactamente los mismos campos que uno emitido por una CA real —sujeto, emisor, ventana de validez, clave pública, firma— salvo que su Issuer y su Subject son idénticos, y ningún navegador ni sistema operativo confiará en él, porque no lo firmó nada que ya estuviera en su almacén de confianza. Esa es toda la diferencia práctica entre «un certificado» y «un certificado de confianza»: la firma, y si la parte que la produjo es una en la que tu software ya había aceptado creer de antemano.

Revocación: qué pasa cuando se filtra una clave privada

El periodo de validez de un certificado limita por diseño el radio de impacto de un compromiso, pero las fechas de caducidad por sí solas suelen ser demasiado lentas —una clave privada filtrada necesita dejar de ser de confianza de inmediato, no cuando le toque caducar. Existen dos mecanismos para hacerlo posible:

• Certificate Revocation Lists (CRL) —una lista firmada y publicada de números de serie de certificados que una CA ha revocado antes de su caducidad natural. Los clientes pueden descargarla y comprobarla, aunque las CRL pueden crecer mucho y no siempre se consultan en tiempo real.
• Online Certificate Status Protocol (OCSP) —una consulta en vivo, certificado por certificado: un cliente pregunta «¿sigue siendo válido este certificado en concreto?» y recibe una respuesta firmada en tiempo real, evitando tener que descargar una lista entera.

Sin embargo, la revocación solo protege lo que pasa a partir de ese momento. No deshace nada que ya se hubiera firmado con una clave comprometida antes de que se descubriera el compromiso —razón por la cual la gestión de claves (mantener las claves privadas fuera de línea, protegidas por hardware y con acceso controlado) importa tanto como la propia criptografía. El algoritmo más fuerte del mundo no sirve de nada si la clave privada que hay detrás está en un archivo legible por cualquiera.

La conclusión

La PKI no es una sola tecnología sino un sistema por capas: los pares de claves asimétricas hacen posibles la firma y el cifrado, las firmas digitales permiten que cualquiera verifique autoría e integridad sin un secreto compartido, los certificados vinculan una clave pública a una identidad real, y las autoridades de certificación extienden ese vínculo en una cadena de confianza que navegadores, sistemas operativos y clientes de correo aceptan respetar de antemano. El mismo patrón aparece tanto si estás cargando un sitio web, instalando software firmado, leyendo un correo verificado o conectándote a una VPN corporativa con una tarjeta inteligente: certificados distintos, la misma maquinaria de fondo. Entender esa maquinaria es lo que convierte «el candado significa que es seguro» en una afirmación real y verificable sobre quién controla qué clave.

Preguntas frecuentes