Una PKI (Public Key Infrastructure, Infraestructura de Clave Pública) es el conjunto de hardware, software, políticas, procedimientos y autoridades que emiten, distribuyen, gestionan y revocan certificados digitales basados en criptografía asimétrica. Es la infraestructura invisible que hace posible que un navegador confíe en https://secra.es sin haberlo visto antes, que un correo S/MIME se firme con identidad verificable, que un empleado se autentique con tarjeta criptográfica y que una administración pública emita firmas digitales con valor legal. Sin PKI no hay TLS, no hay firma electrónica reconocida, no hay autenticación con certificado y, en la práctica, no hay confianza digital escalable entre sistemas que no se conocen previamente.
Esta guía explica qué es una PKI, qué componentes la forman, cómo funciona el chain of trust, los casos de uso empresariales más frecuentes, las diferencias entre PKI pública y privada, los errores que más aparecen en auditoría y cómo encaja en NIS2, eIDAS, ISO 27001 y demás marcos.
Qué es una PKI
Una PKI es un sistema confiable que asocia identidades digitales (personas, dispositivos, dominios, servicios) a claves públicas mediante certificados firmados por una autoridad reconocida. La criptografía asimétrica (RSA, ECDSA, Ed25519) permite que cada entidad tenga un par de claves: una pública que puede compartir y una privada que sólo ella custodia. La PKI resuelve el problema de "cómo confío en que esta clave pública realmente pertenece a quien dice ser" mediante una cadena de firmas.
Lo que aporta operativamente:
- Autenticación: el receptor de un certificado puede verificar que la clave pública de la otra parte está firmada por una autoridad en la que confía.
- Confidencialidad: cifrado de datos en tránsito (TLS) o en reposo (S/MIME, archivos firmados).
- Integridad: cualquier modificación en un dato firmado se detecta al verificar la firma.
- No repudio: el firmante no puede negar después haber firmado un documento (en jurisdicciones con eIDAS o equivalentes).
La PKI es la base técnica de la firma electrónica con valor legal, los certificados TLS de servidor, los certificados de cliente para autenticación corporativa, S/MIME para correo, code signing, certificados de dispositivo IoT y más.
Componentes de una PKI
Cinco piezas que cualquier PKI seria tiene:
Autoridad de Certificación (CA)
La CA es la entidad que emite y firma certificados digitales. Tiene una clave privada que custodia con máxima protección (HSM, off-line, segregada). Su clave pública está embebida en sistemas operativos y navegadores como "raíz de confianza" cuando es una CA pública.
Las CA forman jerarquías. La CA raíz emite certificados a CAs intermedias, que a su vez emiten los certificados de uso final (TLS, S/MIME, autenticación). Esta estructura permite revocar una CA intermedia comprometida sin tocar la raíz.
Ejemplos públicos: Let's Encrypt, DigiCert, Sectigo, Entrust, GlobalSign. En España: FNMT-RCM (Fábrica Nacional de Moneda y Timbre), Camerfirma, Firmaprofesional, AC Catalunya.
Autoridad de Registro (RA)
La RA es la entidad que verifica la identidad del solicitante antes de que la CA emita el certificado. En PKI corporativa pequeña suele ser la misma persona/sistema que la CA; en PKI pública grande son entidades separadas (oficinas físicas o procesos automatizados de validación de dominio en TLS).
Certificado digital
El certificado es un fichero firmado por la CA que contiene la clave pública del titular más sus datos identificativos. El estándar dominante es X.509 v3.
Campos típicos:
- Subject: a quién pertenece (CN=
secra.es, O=Secra Solutions, etc.) - Issuer: quién lo firma (la CA)
- Validity period: desde y hasta cuándo es válido
- Public key: la clave pública del titular
- Signature: la firma de la CA sobre el resto del certificado
- Extensions: restricciones de uso (sólo TLS server, sólo client auth, sólo code signing), URLs de revocación, SANs (Subject Alternative Names) para múltiples dominios
CRL (Certificate Revocation List) y OCSP
La revocación es lo que permite invalidar un certificado antes de que expire (clave privada comprometida, baja del titular, error en la emisión).
- CRL: lista publicada periódicamente por la CA con todos los certificados revocados. El cliente la descarga y la consulta. Funciona pero es ineficiente con CRLs grandes.
- OCSP (Online Certificate Status Protocol): el cliente pregunta a un servidor OCSP por un certificado concreto en tiempo real. Más eficiente que CRL.
- OCSP Stapling: el servidor TLS adjunta la respuesta OCSP firmada al handshake, eliminando la consulta del cliente al OCSP responder. Es el modelo recomendado actualmente.
Repositorio y políticas
La PKI también incluye CPS (Certification Practice Statement) y CP (Certificate Policy): documentos que detallan cómo opera la CA, cómo verifica identidades, cómo gestiona claves, cómo audita y cómo responde a incidentes. En PKI pública estos documentos son obligatorios y públicos.
Cómo funciona el chain of trust
Cuando un navegador entra en https://ejemplo.com:
- El servidor envía su certificado TLS al navegador, junto con la cadena de CAs intermedias que lo firmaron.
- El navegador busca la CA raíz en su almacén de confianza local.
- Verifica la firma de cada CA intermedia hasta llegar a la raíz.
- Comprueba la validez (fechas, SAN coincide con el dominio, no está revocado vía OCSP/CRL).
- Si todo encaja, el cliente confía en el certificado y se establece la conexión TLS.
Cualquier eslabón roto rompe la cadena: CA raíz no en el almacén, certificado expirado, dominio no coincide con SAN, certificado revocado, intermediate certificate no entregado por el servidor (causa frecuente de "incomplete chain").
Casos de uso empresariales habituales
PKI no es sólo TLS. Los usos que aparecen en organizaciones medianas y grandes:
| Caso de uso | Detalle |
|---|---|
| TLS de servidor (HTTPS) | El más común. Certificado por dominio o wildcard, gestión automatizada con ACME (Let's Encrypt) o manual con CAs comerciales |
| TLS de cliente (mTLS) | Autenticación de cliente con certificado en lugar de password. APIs internas, IoT, B2B |
| S/MIME | Firma y cifrado de correo electrónico con identidad verificada |
| Code signing | Firma de software para que sistemas operativos y navegadores confíen en el binario |
| Firma electrónica reconocida | Documentos con valor legal bajo eIDAS, certificado emitido por prestador cualificado |
| Autenticación corporativa con tarjeta o token | Smart cards, YubiKeys, certificados en HSM |
| Certificados de dispositivo IoT | Identidad única por dispositivo, autenticación contra cloud sin password |
| VPN con certificado | OpenVPN o IPsec con autenticación basada en PKI en lugar de PSK |
| Cifrado de documentos | Encriptación con clave pública del receptor (correo, ficheros sensibles) |
| Firma de transacciones | Banca electrónica, SWIFT, marcos sectoriales con firma técnica obligatoria |
PKI pública vs PKI privada
Las dos coexisten en cualquier organización mediana.
PKI pública
Operada por una CA reconocida globalmente cuyo certificado raíz está en navegadores y sistemas operativos. Sirve para identidades que tienen que ser válidas frente al exterior (web pública, S/MIME entre dominios, firma reconocida bajo eIDAS).
Pros: confianza universal, sin necesidad de distribuir certificados raíz. Contras: coste por certificado (excepto Let's Encrypt para TLS de dominio), sometida a políticas y auditorías de CA/Browser Forum.
PKI privada
Operada por la propia organización para identidades internas (mTLS entre microservicios, autenticación de empleados con tarjeta, certificados de dispositivo en una flota IoT). El certificado raíz se distribuye a los sistemas que deben confiar.
Pros: control completo, coste bajo por certificado, plazos personalizados. Contras: gestión operativa (HSM, rotación, revocación, distribución de raíz). Si el equipo no puede mantener la PKI, conviene externalizar.
Productos habituales para PKI privada: Microsoft AD Certificate Services (en organizaciones Windows), HashiCorp Vault PKI, EJBCA, Smallstep CA, OpenSSL CA casero (no recomendado en producción).
Errores comunes en gestión de PKI
Cinco patrones que aparecen en auditorías:
- Certificados sin rotación. Certificados de larga vida (5-10 años) que nunca se renuevan, claves privadas más antiguas que el algoritmo recomendado, sin proceso de rotación documentado.
- Clave privada de la CA en disco sin HSM. Cualquier compromiso del servidor que aloja la CA invalida toda la PKI. La CA raíz debería estar en HSM offline; las CAs intermedias en HSM online con auditoría.
- Sin CRL ni OCSP funcional. Cuando hay que revocar un certificado, no se puede en la práctica. Los clientes siguen confiando en certificados ya invalidados.
- Algoritmos obsoletos. SHA-1, RSA-1024, claves DSA. Cualquier auditoría moderna lo señala. Migración mínima a SHA-256, RSA-2048 o ECDSA P-256.
- CAs intermedias accesibles desde fuera de la red administrativa. Si la CA emite certificados desde un servidor expuesto, una intrusión gana capacidad de emitir certificados arbitrarios. Debe estar en red administrativa segregada.
PKI y compliance
Marcos donde la PKI es exigible o muy recomendada:
- eIDAS (Reglamento UE 910/2014, próxima eIDAS 2). Establece tres niveles de firma electrónica (simple, avanzada, cualificada). La firma cualificada exige certificado emitido por prestador cualificado de servicios de confianza supervisado.
- NIS2 (artículo 21). Eficacia probada de medidas técnicas, incluyendo gestión de identidades digitales y criptografía.
- DORA (artículo 9). Gestión segura de datos y comunicaciones en entidades financieras.
- ENS (Real Decreto 311/2022, Marco Operacional). Uso de firma electrónica y certificados con validez reconocida en el sector público español.
- ISO 27001:2022 (controles 8.24 y 8.26). Uso de criptografía y gestión de claves criptográficas.
- PCI DSS v4.0 (req. 3 y 4). Protección de datos de tarjeta en reposo y en tránsito con criptografía robusta.
Para empresas reguladas, la PKI no es opcional sino infraestructura crítica que el auditor revisa específicamente.
Preguntas frecuentes
¿Qué diferencia hay entre PKI y certificado digital?
El certificado digital es uno de los componentes de la PKI. La PKI incluye además la autoridad que lo emite (CA), la verificación previa (RA), el sistema de revocación (CRL/OCSP), las políticas operativas (CPS) y la infraestructura técnica (HSM, repositorios). El certificado por sí solo no funciona; necesita el resto del ecosistema PKI para que tenga valor.
¿Necesita mi empresa una PKI privada?
Probablemente no si todos los certificados que usas son TLS de servidor público (cubierto por Let's Encrypt o CA comercial) y firma electrónica externa (cubierta por FNMT u otro prestador). Sí necesitas PKI privada si tienes mTLS entre microservicios internos, autenticación de empleados con tarjeta corporativa, flotas IoT con certificado por dispositivo o VPN con autenticación basada en certificados internos.
¿Cuánto cuesta montar una PKI privada?
El coste base depende de si optas por software open source (EJBCA, Smallstep, HashiCorp Vault PKI gratuito) o enterprise (DigiCert ONE, Microsoft AD CS sobre Windows Server). El gasto principal está en HSM (10-50K€ por par redundante) y en horas de equipo para la operación (rotación, revocación, gestión de certificados). Externalizar a un proveedor managed PKI puede simplificar la decisión si la organización no tiene equipo dedicado.
¿Qué pasa si se compromete la clave privada de mi CA?
Es el peor escenario. Todos los certificados emitidos por esa CA quedan en duda hasta que se rotacione la PKI completa: nueva CA, reemisión de todos los certificados de uso final, distribución del nuevo certificado raíz a todos los clientes que confían en la PKI, invalidación de la CA antigua. Por eso la clave privada de la CA raíz se mantiene off-line en HSM y sólo se usa para firmar CAs intermedias en ceremonias auditadas.
¿Sirve la firma electrónica de FNMT para uso corporativo internacional?
La firma con certificado FNMT tiene validez legal en España y en la UE bajo eIDAS. Para uso fuera de la UE, depende del marco del país receptor. Para acuerdos B2B internacionales, suelen usarse plataformas (DocuSign, Adobe Sign) que combinan firma cualificada eIDAS con audit trail propio que tiene reconocimiento más amplio.
¿Es posible hacer PKI sin HSM?
Técnicamente sí, almacenando la clave privada en disco con permisos restrictivos. En la práctica, cualquier auditoría seria (especialmente bajo eIDAS o para CAs intermedias relevantes) exige HSM porque es la única forma de garantizar que la clave nunca sale del dispositivo. Para PKI privada de bajo riesgo (mTLS interno, IoT no crítico) puede ser aceptable arrancar sin HSM y migrar después.
Recursos relacionados
- Qué es un CVE: cómo se gestionan vulnerabilidades en bibliotecas criptográficas y PKI.
- Qué es un ransomware: el cifrado simétrico es lo que usa el ransomware; PKI es el sistema que valida confianza, no el que cifra masivamente.
- Qué es un SOC: la operación que monitoriza compromisos en infraestructura PKI corporativa.
- Cómo cumplir NIS2 en España: el marco regulatorio donde PKI aporta evidencia de medidas técnicas.
- ISO 27001 explicada: cómo se documentan los controles criptográficos y de gestión de claves dentro del SGSI.
PKI en Secra
En Secra trabajamos con PKI en dos frentes: como parte de auditorías técnicas (revisión de implementaciones TLS, mTLS, certificados de cliente, code signing, gestión de claves y rotación) y como apoyo en proyectos de compliance NIS2, ENS o ISO 27001 donde la criptografía y la gestión de claves forma parte del alcance. Si tu organización quiere validar la postura de su PKI o necesita apoyo en el diseño de una infraestructura de claves para compliance regulatorio, escríbenos a través de contacto o consulta nuestros servicios de consultoría GRC.
Sobre el autor
Equipo de Secra Solutions
Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.