01Componentes de una PKI y su Modelo de Relaciones
Una infraestructura de clave pública (PKI, Public Key Infrastructure) es el conjunto de personas, políticas, procedimientos, hardware y software que permite emitir, distribuir, verificar y revocar certificados digitales. Su objetivo es que podamos confiar en que una clave pública pertenece a quien dice pertenecer.
Componentes
Autoridad de Certificación (CA)
Emite, renueva y revoca certificados, firmándolos con su clave privada. Es el núcleo de la confianza.
Autoridad de Registro (RA)
Comprueba la identidad del solicitante antes de que la CA emita. En la FNMT, por ejemplo, son las oficinas donde acreditas tu identidad.
Autoridad de Validación (VA)
Responde en tiempo real si un certificado sigue siendo válido, normalmente mediante OCSP.
Repositorio
Publica los certificados y las listas de revocación (CRL), normalmente por HTTP o LDAP.
Autoridad de Sellado de Tiempo (TSA)
Emite sellos de tiempo firmados que prueban cuándo existía un documento o una firma.
Titulares y terceros que confían
Los titulares usan su certificado; los terceros (navegadores, servidores, personas) lo verifican.
La cadena de confianza
CA raíz
autofirmada, guardada fuera de línea
CA intermedia
firmada por la raíz
Certificado final
servidor, persona, dispositivo
El navegador o el sistema operativo trae un almacén de certificados raíz en los que confía. Para validar un certificado, construye la cadena hasta una de esas raíces y comprueba cada firma. La raíz se mantiene desconectada y solo firma CA intermedias: si una intermedia se ve comprometida, se revoca sin tener que sustituir la raíz en millones de equipos.
Modelos de confianza
🌳 Jerárquico
Una raíz y varias intermedias. Es el modelo de las CA públicas de Internet y de las PKI corporativas.
🔗 Certificación cruzada
Dos CA independientes se firman mutuamente para que sus usuarios confíen entre sí.
🌉 CA puente
Una CA central conecta varias PKI de organizaciones distintas sin que cada una tenga que cruzarse con todas.
🕸️ Red de confianza
Sin CA: los propios usuarios se avalan unos a otros, como en PGP.
02Autoridad de Certificación y sus Elementos
Una CA es una entidad de confianza que da fe, con su firma, de que una clave pública pertenece a un titular. Toda la seguridad de la PKI depende de que su clave privada no se vea comprometida y de que verifique bien las identidades.
Elementos de una CA
- Par de claves de la CA
- Certificado de la CA (autofirmado si es raíz)
- HSM certificado (FIPS 140 o Common Criteria) que custodia la clave privada
- Política de certificación (CP)
- Declaración de prácticas (CPS)
- Acuerdos con titulares y terceros
- Emisión y renovación
- Revocación y publicación de CRL
- Respondedor OCSP
- Repositorio público
- Seguridad física de las instalaciones
- Separación de funciones y control dual
- Registros de auditoría
- Auditorías externas (WebTrust, ETSI)
Ciclo de vida de un certificado
CA públicas y CA privadas
🌐 CA pública
- Sus raíces vienen de serie en navegadores y sistemas
- Para webs y servicios abiertos a cualquiera
- Sometidas a las normas del CA/Browser Forum y a auditorías anuales
- Ejemplos: Let's Encrypt, DigiCert, Sectigo, FNMT
🏢 CA privada o corporativa
- Solo confían en ella los equipos de la organización donde se instala su raíz
- Para intranets, VPN, WiFi 802.1X, autenticación de usuarios y dispositivos
- Ejemplos: Active Directory Certificate Services, EJBCA, step-ca
⚠️ Cuando una CA falla
- En 2011 atacantes comprometieron la CA holandesa DigiNotar y emitieron certificados falsos para Google, usados para espiar a usuarios
- Los navegadores retiraron la confianza en sus raíces y la empresa quebró en semanas
- Lección: una CA comprometida rompe la seguridad de todos los que confían en ella
03Política de Certificado (CP) y Declaración de Prácticas de Certificación (CPS)
Son los dos documentos que permiten a cualquiera decidir si confía o no en los certificados de una CA. Su estructura habitual sigue el RFC 3647.
📘 Política de Certificado (CP)
- Responde a qué: reglas que deben cumplir los certificados
- Para qué se pueden usar y con qué nivel de confianza
- Requisitos mínimos de identificación del titular
- Se identifica con un OID que aparece dentro de cada certificado
📗 Declaración de Prácticas (CPS)
- Responde a cómo: procedimientos reales de la CA para cumplir la CP
- Cómo verifica identidades, emite, renueva y revoca
- Controles físicos, técnicos y de personal
- Es pública y se audita
Contenido típico según el RFC 3647
- Introducción – Participantes de la PKI y usos permitidos de los certificados
- Publicación y repositorios – Dónde y con qué frecuencia se publican certificados y CRL
- Identificación y autenticación – Cómo se comprueba la identidad del solicitante
- Requisitos operativos del ciclo de vida – Solicitud, emisión, aceptación, renovación y revocación
- Controles físicos, de procedimiento y de personal
- Controles técnicos de seguridad – Generación y protección de claves, uso de HSM
- Perfiles de certificado, CRL y OCSP
- Auditorías de cumplimiento y aspectos legales y de negocio – Responsabilidades, tarifas, privacidad
La FNMT publica en su sede electrónica la «Declaración General de Prácticas de Servicios de Confianza» y las políticas específicas de cada tipo de certificado. Abre cualquier certificado en el navegador, busca la extensión Certificate Policies y verás el OID y la URL de la política aplicable.
04Lista de Certificados Revocados (CRL)
Un certificado puede dejar de ser fiable antes de caducar: se robó la clave privada, el titular dejó la empresa o los datos cambiaron. La CA lo revoca y lo comunica a través de una CRL: una lista firmada con los números de serie de los certificados revocados.
Contenido de una CRL
- Emisor y firma de la CA
- Fecha de emisión (thisUpdate) y próxima actualización (nextUpdate)
- Por cada certificado revocado: número de serie, fecha de revocación y, opcionalmente, motivo
Motivos de revocación (RFC 5280)
CRL frente a OCSP
📋 CRL
- Se descarga la lista completa y se consulta localmente
- Puede ser grande; se mitiga con CRL delta (solo los cambios)
- Información con cierto retraso: hasta la próxima publicación
- No revela a la CA qué webs visita el usuario
⚡ OCSP
- Se pregunta a la CA por un certificado concreto y responde «válido», «revocado» o «desconocido»
- Respuesta inmediata y pequeña
- Problema de privacidad: la CA sabe qué sitios consultas
- OCSP stapling: el servidor adjunta la respuesta y el cliente no tiene que preguntar
La tendencia actual es acortar la vida de los certificados para depender menos de la revocación. Let's Encrypt dejó de dar servicio OCSP en 2025 y volvió a las CRL, y el CA/Browser Forum ha aprobado reducir la validez máxima de los certificados TLS de forma escalonada hasta 47 días en 2029.
openssl crl -in ca.crl -inform DER -text -noout
# Consultar por OCSP el estado de un certificado
openssl ocsp -issuer intermedia.pem -cert servidor.pem -url http://ocsp.ejemplo.com
05Funcionamiento de las Solicitudes de Firma de Certificados (CSR)
Una CSR (Certificate Signing Request, formato PKCS#10) es el fichero que se envía a una CA para pedir un certificado. Contiene la clave pública y los datos del solicitante, y va firmada con la clave privada correspondiente para demostrar que la posee. La clave privada nunca sale del equipo del solicitante.
Proceso
- Generar el par de claves en el servidor o dispositivo que usará el certificado.
- Crear la CSR con los datos del sujeto y los nombres alternativos (SAN): dominios, IP o correos.
- Enviar la CSR a la CA o a su RA.
- Validación: la CA comprueba que controlas el dominio (DV), la organización (OV) o, con más rigor, la entidad legal (EV).
- Emisión: la CA devuelve el certificado firmado, normalmente con la cadena de CA intermedias.
- Instalación del certificado y de la cadena junto a la clave privada.
Generar una CSR con OpenSSL
openssl req -new -newkey rsa:3072 -nodes -keyout web.key -out web.csr \
-subj "/C=ES/ST=Alicante/L=Alicante/O=Ejemplo SL/CN=www.ejemplo.com" \
-addext "subjectAltName=DNS:www.ejemplo.com,DNS:ejemplo.com"
# Comprobar lo que contiene antes de enviarla
openssl req -in web.csr -text -noout -verify
Automatización con ACME
El protocolo ACME (RFC 8555), creado por Let's Encrypt, automatiza todo el proceso: el cliente (por ejemplo, certbot) genera la clave y la CSR, demuestra el control del dominio y renueva el certificado solo. Con certificados cada vez más cortos, la automatización ha pasado de ser cómoda a ser imprescindible.
📌 Errores frecuentes
- Poner el dominio solo en el CN: los navegadores solo miran el SAN
- Generar la clave privada en una web de terceros: deja de ser privada
- Olvidar instalar la CA intermedia: algunos clientes mostrarán el certificado como no fiable
06Infraestructura de Gestión de Privilegios (PMI)
La PKI responde a la pregunta «¿quién eres?» (autenticación). La PMI (Privilege Management Infrastructure), definida también en la norma X.509, responde a «¿qué puedes hacer?» (autorización), gestionando privilegios mediante certificados de atributos.
🪪 PKI
- Vincula identidad y clave pública
- La emite una Autoridad de Certificación (CA)
- Certificado de clave pública, de larga duración
🎫 PMI
- Vincula identidad y privilegios (roles, permisos)
- La emite una Autoridad de Atributos (AA)
- Certificado de atributos, a menudo de corta duración
Elementos de una PMI
Fuente de Autoridad (SOA)
Entidad raíz que tiene la última palabra sobre los privilegios, equivalente a la CA raíz.
Autoridad de Atributos (AA)
Emite y revoca los certificados de atributos. Puede delegar en otras AA.
Certificados de atributos
Contienen los privilegios del titular, firmados por la AA.
Política de privilegios
Reglas que dicen qué atributos dan acceso a qué recursos.
Cómo se toma una decisión de acceso
El modelo más extendido (XACML) separa la decisión en cuatro piezas:
| Punto | Función |
|---|---|
| PEP · Policy Enforcement Point | Intercepta la petición y aplica la decisión: deja pasar o bloquea |
| PDP · Policy Decision Point | Evalúa la política con los atributos y decide «permitir» o «denegar» |
| PIP · Policy Information Point | Aporta atributos adicionales: certificados de atributos, directorio, hora, ubicación |
| PAP · Policy Administration Point | Donde se escriben y gestionan las políticas |
Separar autenticación y autorización permite cambiar los permisos de alguien sin revocar su identidad, aplicar el mínimo privilegio y conceder permisos temporales que caducan solos.
07Certificados de Atributos
Un certificado de atributos (AC, Attribute Certificate, perfilado en el RFC 5755) es un documento firmado por una Autoridad de Atributos que asigna privilegios a un titular. No contiene clave pública: se apoya en el certificado de identidad del titular.
Campos principales
- Titular (Holder) – Referencia al certificado de identidad del titular (emisor y número de serie)
- Emisor – La Autoridad de Atributos
- Atributos – Rol, grupo, nivel de autorización, cargo…
- Periodo de validez – Suele ser corto: horas o días
- Número de serie, extensiones y firma de la AA
¿Por qué no meter los permisos en el certificado de identidad?
📜 Certificado de identidad
- Cambia poco: el nombre de una persona no varía
- Lo emite una CA, a menudo externa
- Vigencia de uno o varios años
🎫 Certificado de atributos
- Cambia a menudo: roles, proyectos, turnos
- Lo emite quien gestiona los permisos dentro de la organización
- Vigencia corta, así que apenas hace falta revocarlo
Usos habituales
Hoy la misma idea aparece con otros formatos: los tokens SAML y JWT con roles, o las credenciales verificables de la Cartera Europea de Identidad Digital.
08Aplicaciones que se Apoyan en una PKI
HTTPS (TLS)
Autentica el servidor web y permite cifrar la conexión.
Correo S/MIME
Firma y cifra correos con certificados personales.
Firma de documentos
Contratos, facturas electrónicas y trámites con la Administración.
Firma de código
Garantiza el origen y la integridad de programas y controladores.
VPN
Autentica servidores y clientes en IPsec y OpenVPN.
WiFi corporativa (802.1X)
EAP-TLS autentica a cada usuario o equipo con su certificado.
Tarjetas inteligentes
DNIe e inicio de sesión en Windows con tarjeta.
IoT y servicios
Identidad de dispositivos y mTLS entre microservicios.
- Entras en la web del banco: el candado es un certificado TLS validado hasta una raíz de tu navegador
- Presentas un trámite en la Agencia Tributaria con el certificado de la FNMT: firma avanzada o cualificada
- Windows instala una actualización: comprueba la firma de código de Microsoft
- Tu portátil se conecta a la WiFi de la empresa con EAP-TLS: un certificado emitido por la CA corporativa
09Definición, Finalidad y Funcionalidad de las VPN
Una red privada virtual (VPN) crea un canal cifrado y autenticado sobre una red que no es de confianza, normalmente Internet, de modo que los equipos se comunican como si estuvieran en la misma red privada.
Finalidad
Confidencialidad
Nadie en el camino puede leer el tráfico.
Integridad
Se detecta cualquier modificación de los paquetes.
Autenticación
Solo se conectan equipos y usuarios autorizados.
Acceso remoto
Teletrabajo con acceso a los recursos internos.
Tipos según su uso
🏢↔🏢 VPN de sitio a sitio
- Une dos o más redes completas, por ejemplo la sede central con una delegación
- La establecen los routers o cortafuegos de cada sede; los usuarios no hacen nada
- Protocolo típico: IPsec
👤↔🏢 VPN de acceso remoto
- Conecta un usuario individual con la red de la empresa
- Requiere un cliente o un navegador y autenticación del usuario, idealmente con MFA
- Protocolos típicos: IPsec/IKEv2, SSL VPN, OpenVPN, WireGuard
Cómo funciona
Equipo del usuario
Autenticación
Intercambio de claves
Túnel cifrado por Internet
Concentrador VPN y red interna
📌 VPN corporativa no es lo mismo que VPN comercial
- La VPN corporativa da acceso a recursos internos y protege el tráfico de la empresa
- Las VPN comerciales de consumo ocultan tu IP a las webs y protegen en redes WiFi públicas, pero el proveedor ve todo tu tráfico: solo trasladan la confianza de tu operador a ellos
10Protocolo IPsec
IPsec es un conjunto de protocolos que protege el tráfico en la capa de red (capa 3). Al trabajar sobre IP, protege cualquier aplicación sin que esta tenga que saberlo. Es el estándar de las VPN de sitio a sitio.
Componentes
| Componente | Qué hace | Detalle técnico |
|---|---|---|
| AH · Authentication Header | Integridad y autenticación del paquete, sin cifrado | Protocolo IP 51. Incompatible con NAT, porque firma también las direcciones IP |
| ESP · Encapsulating Security Payload | Cifrado, integridad y autenticación | Protocolo IP 50. Es el que se usa en la práctica |
| IKE · Internet Key Exchange | Autentica a los extremos y negocia claves y algoritmos | UDP 500; UDP 4500 cuando hay NAT (NAT-T). Versión actual: IKEv2 |
| SA · Asociación de Seguridad | Acuerdo unidireccional de algoritmos y claves entre dos extremos | Identificada por un SPI; se guardan en la SAD y las reglas en la SPD |
Modos de funcionamiento
🚚 Modo transporte
- Protege solo la carga útil; la cabecera IP original se mantiene
- Comunicación directa entre dos equipos
- Ejemplo: cifrar el tráfico entre dos servidores
🚇 Modo túnel
- Cifra el paquete IP completo y lo mete dentro de uno nuevo
- Oculta las direcciones internas
- Es el modo de las VPN entre sedes
Establecimiento de una VPN con IKEv2
- IKE_SA_INIT. Los extremos negocian algoritmos y hacen un intercambio Diffie-Hellman. A partir de aquí todo va cifrado.
- IKE_AUTH. Cada extremo demuestra su identidad con certificado, secreto precompartido o EAP, y se crea la primera SA de ESP.
- Tráfico protegido. Los datos viajan en paquetes ESP.
- Renovación. Las claves se renuevan periódicamente (rekeying) sin cortar la conexión.
📌 Recomendaciones
- Usar IKEv2 con certificados en lugar de secretos precompartidos débiles
- ESP con AES-GCM y grupos Diffie-Hellman de curva elíptica (19, 20 o 31)
- Abrir en el cortafuegos UDP 500, UDP 4500 y el protocolo ESP
11Protocolos SSL/TLS y SSH
🌐 SSL / TLS
- Protege conexiones de aplicaciones sobre TCP: HTTPS, correo (SMTPS, IMAPS), LDAPS, VPN SSL
- El servidor se autentica con un certificado X.509; el cliente, opcionalmente (mTLS)
- SSL 2.0/3.0 y TLS 1.0/1.1 están obsoletos (RFC 8996)
- Versiones válidas: TLS 1.2 bien configurado y TLS 1.3
- Puerto típico: 443 (HTTPS)
🖥️ SSH
- Acceso remoto seguro por consola, sustituto de Telnet, rlogin y FTP
- El servidor se autentica con su clave de host; el usuario, con contraseña o, mejor, con clave pública
- Incluye transferencia de ficheros (SFTP, SCP) y túneles (redirección de puertos)
- Versión válida: SSH-2 (SSH-1 está roto)
- Puerto típico: 22
Qué aporta TLS 1.3 frente a versiones anteriores
- Más rápido – Handshake en un solo viaje de ida y vuelta (1-RTT)
- Solo algoritmos seguros – Elimina RC4, 3DES, CBC, SHA-1 y el intercambio RSA estático
- Secreto hacia delante obligatorio – Siempre ECDHE o DHE
- Más privacidad – El certificado del servidor viaja cifrado
Las tres capas de SSH
Capa de transporte
Intercambio de claves, autenticación del servidor y cifrado de la conexión.
Autenticación de usuario
Contraseña, clave pública, certificados SSH o segundo factor.
Conexión
Multiplexa canales: sesión de consola, SFTP y túneles dentro de la misma conexión.
SSH con claves en lugar de contraseñas
ssh-keygen -t ed25519 -C "alumno@portatil"
# Copiar la clave pública al servidor
ssh-copy-id usuario@servidor
# Comprobar la configuración TLS de una web
nmap --script ssl-enum-ciphers -p 443 www.ejemplo.com
12Sistemas SSL VPN
Una SSL VPN ofrece acceso remoto usando TLS (el nombre «SSL» es histórico). Como viaja por el puerto 443, atraviesa casi cualquier cortafuegos o NAT, algo que a IPsec le cuesta más.
Modalidades
🌐 Sin cliente (portal web)
El usuario entra en un portal desde el navegador y accede a aplicaciones web publicadas, sin instalar nada.
🧩 Túnel completo con cliente
Un cliente ligero crea una interfaz virtual y da acceso a nivel de red, como una VPN IPsec.
🔀 Túnel dividido (split tunneling)
Solo el tráfico corporativo va por la VPN; el resto sale directo a Internet. Ahorra ancho de banda, pero reduce la visibilidad.
🎯 Acceso granular
Permite dar a cada usuario o grupo acceso solo a aplicaciones concretas, en lugar de a toda la red.
Productos habituales
⚠️ La puerta más atacada de la empresa
- Los concentradores SSL VPN están expuestos a Internet y son un objetivo prioritario: vulnerabilidades como CVE-2018-13379 (Fortinet) o CVE-2023-46805 y CVE-2024-21887 (Ivanti) se explotaron de forma masiva
- En 2021, el ataque de ransomware a Colonial Pipeline empezó con una contraseña filtrada de una cuenta VPN antigua sin MFA
- Medidas: parchear en cuanto salga la corrección, exigir MFA, retirar cuentas que no se usan y vigilar los registros de acceso
13Túneles Cifrados
Un túnel encapsula un protocolo dentro de otro. Si además el paquete encapsulado se cifra, tenemos un túnel cifrado: el tráfico viaja por una red pública pero nadie en el camino puede leerlo ni modificarlo.
Funcionamiento
- Encapsulación. El paquete original se envuelve con una nueva cabecera del protocolo de túnel.
- Cifrado y autenticación. El contenido se cifra y se añade un código de integridad.
- Transporte. El paquete viaja por Internet como tráfico normal entre los dos extremos del túnel.
- Desencapsulación. El otro extremo verifica, descifra y entrega el paquete original a su red.
Tecnologías de túnel
| Tecnología | Capa | ¿Cifra? | Uso típico |
|---|---|---|---|
| GRE | 3 | ❌ No (se combina con IPsec) | Transportar tráfico entre routers |
| IPsec (modo túnel) | 3 | ✅ | VPN entre sedes |
| WireGuard | 3 | ✅ | VPN moderna, sencilla y muy rápida |
| OpenVPN | 3 o 2 (sobre TLS) | ✅ | Acceso remoto multiplataforma |
| Túnel SSH | Aplicación (puertos TCP) | ✅ | Acceso puntual a un servicio interno |
| stunnel | Aplicación | ✅ | Añadir TLS a un servicio que no lo soporta |
Túneles SSH en la práctica
ssh -L 3306:db.interna:3306 usuario@bastion
# Remoto: publicar un puerto local en el servidor
ssh -R 8080:localhost:80 usuario@servidor
# Dinámico: proxy SOCKS para navegar a través del servidor
ssh -D 1080 usuario@servidor
📌 Arma de doble filo
- Los atacantes también usan túneles (SSH, DNS, HTTP) para sacar datos o mantener el acceso saltándose el cortafuegos
- Por eso conviene controlar qué túneles se permiten (AllowTcpForwarding en sshd), inspeccionar el tráfico saliente y vigilar conexiones de larga duración hacia destinos inusuales
14Ventajas e Inconvenientes de las Alternativas VPN
| Alternativa | Ventajas | Inconvenientes |
|---|---|---|
| IPsec / IKEv2 | Estándar abierto, interoperable entre fabricantes, protege todo el tráfico IP, ideal entre sedes | Configuración compleja; problemas con NAT y cortafuegos restrictivos |
| SSL VPN | Atraviesa cortafuegos por el 443, acceso desde el navegador, control granular por aplicación | Productos propietarios; los concentradores son un objetivo frecuente de ataques |
| OpenVPN | Código abierto, muy flexible, funciona en TCP o UDP | Más lento que WireGuard; configuración extensa |
| WireGuard | Muy rápido, código pequeño y auditable, criptografía moderna fija | Sin negociación de algoritmos; gestión de usuarios y claves más básica |
| L2TP/IPsec | Cliente nativo en muchos sistemas | Doble encapsulación y poco rendimiento; en desuso |
| PPTP | Muy sencillo | ❌ Criptografía rota (MS-CHAPv2). No debe usarse |
| VPN hardware (appliance) | Alto rendimiento, gestión centralizada | Coste elevado, dependencia del fabricante |
| VPN software | Barata, flexible, fácil de escalar | Consume recursos del equipo y depende de su seguridad |
Más allá de la VPN: ZTNA
🏰 VPN tradicional
- Una vez dentro, el usuario suele ver toda la red
- La confianza se concede al conectarse
- Un equipo comprometido puede moverse lateralmente
🎯 ZTNA (Zero Trust Network Access)
- Acceso solo a la aplicación concreta, nunca a la red
- Se verifica identidad, dispositivo y contexto en cada petición
- Las aplicaciones no quedan expuestas a Internet
Criterios para elegir
🏢 Unir sedes
IPsec/IKEv2 entre cortafuegos, con certificados.
👥 Teletrabajo general
SSL VPN o IKEv2 con MFA obligatorio, o ZTNA.
🧑💻 Equipos técnicos y laboratorios
WireGuard u OpenVPN.
🛡️ Siempre
MFA, parches al día, mínimo privilegio y registros de conexión vigilados.