¿Qué es una autoridad de certificación? Una guía completa sobre la confianza digital

Todas las conexiones cifradas en las que confías, desde el inicio de sesión en un banco hasta una llamada a una API entre microservicios, dependen de que se responda correctamente a una única pregunta: ¿es la entidad del otro lado realmente quien dice ser? Las autoridades de certificación existen para responder a esa pregunta. Son los pilares de confianza que hacen posible la comunicación autenticada y cifrada a gran escala.

Esta guía explica qué es una autoridad de certificación, cómo funciona el proceso de emisión, la jerarquía de confianza que garantiza la seguridad del sistema y cómo decidir qué tipo de autoridad de certificación se adapta mejor a las necesidades de su organización.

¿Qué es una autoridad de certificación?

Una autoridad de certificación es una entidad de confianza que verifica la identidad de usuarios, equipos, organizaciones, servicios, etc., y a continuación emite certificados firmados digitalmente que acreditan dichas identidades. En el contexto de la infraestructura de clave pública, la función principal de la CA es emitir y revocar certificados, al tiempo que da soporte a los flujos de trabajode gestión de certificados, incluyendo la validación de solicitudes y su publicación.

En esencia, una CA vincula una identidad a un par de claves criptográficas. Cuando una CA emite un certificado, está realizando una declaración verificable: «He confirmado que esta clave pública pertenece a esta entidad». Cualquier persona que confíe en la CA puede, por tanto, confiar en esa declaración, lo que permite a personas desconocidas establecer conexiones seguras sin necesidad de haber mantenido ninguna relación previa.

El término «CA» puede referirse tanto a la organización que avala las identidades como a la infraestructura de servidores utilizada para emitir y gestionar certificados. Tanto si la gestiona un proveedor global como si la implementa internamente el equipo de TI de una empresa, la función es la misma: autenticar una entidad, emitir un certificado firmado y gestionar dicho certificado a lo largo de su ciclo de vida.

Por qué son necesarias las autoridades de certificación

Las autoridades de certificación existen para resolver de manera eficaz un problema fundamental de la criptografía de clave pública: ¿cómo se sabe que una clave pública pertenece realmente a la entidad a la que dice pertenecer?

La criptografía de clave pública permite que dos partes se comuniquen de forma segura sin necesidad de compartir un secreto previamente, pero presenta una vulnerabilidad fundamental. Si recibes una clave pública que afirma proceder de tu banco, nada en la propia clave demuestra que esa afirmación sea cierta. Un atacante podría presentar su propia clave, suplantar la identidad del banco e interceptar toda tu conexión. La criptografía garantiza la validez matemática, pero no la identidad que hay detrás.

Sin un tercero de confianza que verifique las identidades, las organizaciones se enfrentan a graves riesgos:

• Ataques de «hombre en el medio»:un atacante intercepta la comunicación entre dos partes, haciéndose pasar por cada una de ellas ante la otra.
• Suplantación de identidad:Los actores maliciosos presentan credenciales fraudulentas que parecen legítimas, lo que les permite obtener acceso no autorizado a los sistemas y a los datos.
• Interceptación de datos:La información confidencial que se transmite a través de conexiones no verificadas puede ser capturada y utilizada con fines maliciosos.

Las CA resuelven estos problemas actuando como terceros de confianza que avalan la vinculación entre una identidad y una clave pública. La CA verifica que una entidad es quien dice ser y, a continuación, emite un certificado firmado digitalmente que da fe de dicha vinculación. Dado que la CA firma con su propia clave privada, cualquiera puede verificar la autenticidad del certificado utilizando la clave pública conocida de la CA. No es necesario confiar en la entidad que presenta el certificado; solo hay que confiar en la CA que ha avalado dicho certificado.

Este modelo es el que permite que la confianza sea escalable. En lugar de que cada parte tenga que establecer la confianza de forma individual con todas las demás (algo imposible a la escala de Internet, o incluso dentro de una empresa moderna), todos basan su confianza en un conjunto relativamente pequeño de autoridades de certificación (CA). Los sistemas operativos y los navegadores incluyen de serie un conjunto preinstalado de CA raíz de confianza, y esa base compartida permite que cada día se establezcan miles de millones de conexiones de forma segura.

Cómo funciona una autoridad de certificación

El proceso de emisión de certificados sigue una secuencia bien definida. Comprender cada paso permite entender cómo las autoridades de certificación (CA) establecen y verifican la confianza.

Paso 1: Generar un par de claves.
El solicitante crea un par de claves, una pública y otra privada. La clave privada es secreta y nunca sale del control del solicitante.

Paso 2: Crear una solicitud de firma de certificado (CSR).
El solicitante genera una CSR que contiene su clave pública e información identificativa (como un nombre distinguido para un certificado X.509). La CSR se firma con la clave privada del solicitante para demostrar que es el titular.

Paso 3: Enviar la CSR a la autoridad de certificación.
El solicitante envía la CSR a la autoridad de certificación junto con cualquier documento de identidad que se requiera. La autoridad de certificación puede exigir documentación legal, la verificación de la titularidad del dominio o la validación de la organización, dependiendo del tipo de certificado.

Paso 4: La CA valida la solicitud.
La CA revisa la CSR, verifica la identidad del solicitante y confirma que la solicitud cumple con sus políticas de emisión.

Paso 5: La CA firma y devuelve el certificado.
Una vez validado, la CAfirma el certificado con su propia clave privada y devuelve el certificado completado al solicitante. El certificado ya puede implementarse en servidores, dispositivos o aplicaciones.

En IoT , este proceso se adapta a la fabricación de dispositivos. En algunos casos, la «raíz de confianza» del dispositivo genera un par de claves ECC y una solicitud de certificado (CSR), que se envía a la infraestructura de clave pública (PKI) del fabricante. El certificado intermedio de certificación del producto (PAI) firma la solicitud y emite un certificado de certificación del dispositivo (DAC) que se almacena de forma segura en el dispositivo.

La función de las claves públicas y privadas

La criptografía asimétrica es la base de todo el proceso de la CA. Cada CA mantiene su propio par de claves: una clave privada que se utiliza para firmar certificados y una clave pública que se distribuye ampliamente para que cualquiera pueda verificar dichas firmas.

Cuando una autoridad de certificación (CA) emite un certificado, crea una firma digital cifrando un hash del contenido del certificado con su clave privada. A continuación, cualquier destinatario puede verificar dicha firma utilizando la clave pública de la CA. Si la verificación se supera, la firma es válida y se puede confiar en el certificado.

Este mecanismo garantiza que los certificados no puedan falsificarse. Solo la autoridad de certificación (CA) que posea la clave privada puede generar una firma válida, mientras que cualquier persona que disponga de la clave pública puede verificarla.

La jerarquía de confianza de las autoridades de certificación

El modelo de confianza de las CA se basa en una jerarquía por niveles que concilia la seguridad con la flexibilidad operativa. Las cadenas de confianza parten de una única CA raíz, pasan por las autoridades intermedias y llegan hasta los certificados instalados en los terminales.

Autoridades de certificación raíz

La CA raíz se sitúa en el nivel más alto de la jerarquía y actúa como punto de referencia de confianza. Para que un certificado de entidad final sea considerado fiable, debe estar vinculado a una CA raíz integrada en el sistema operativo, el navegador o el dispositivo que valida el certificado.

Las CA raíz cuentan con un alto nivel de seguridad y, por lo general, se mantienen desconectadas de la red. Sus claves privadas se almacenan en instalaciones que cumplen los requisitos de la GSA y están sometidas a estrictos controles. Dado que el compromiso de una CA raíz socavaría la validez de todos los certificados de su jerarquía, las CA raíz rara vez emiten certificados directamente. En su lugar, delegan esa responsabilidad a las CA subordinadas.

Autoridades de certificación intermedias, subordinadas y emisoras

Las CA intermedias actúan entre la CA raíz y los certificados de las entidades finales. Su objetivo principal es definir y autorizar los tipos de certificados que pueden solicitarse a la CA raíz. También se conocen como CA subordinadas, ya que su propio certificado ha sido firmado por otra CA.

Las organizaciones suelen implementar autoridades de certificación subordinadas independientes para distintos fines. En las jerarquías públicas, por ejemplo, las autoridades de certificación subordinadas TLS S/MIME deben estar separadas. Otras configuraciones habituales incluyen autoridades subordinadas independientes para distintas ubicaciones geográficas, o una autoridad subordinada para los certificados que utilizan claves ECC y otra para las claves RSA.

Las CA intermedias dedicadas a firmar certificados para usuarios finales (entidades finales) se denominan CA emisoras. Por lo tanto, una CA emisora es casi siempre una CA subordinada, ya que las CA raíz rara vez emiten certificados a usuarios finales.

Certificados de entidad final

Las entidades finales son los usuarios finales a los que se ha hecho referencia anteriormente. Los certificados de entidades finales constituyen el eslabón final de la cadena de confianza y también se conocen como las «hojas» de la jerarquía de la PKI. Se trata de los certificados instalados en servidores, equipos, hardware criptográfico y dispositivos. Representan la identidad de un punto final específico y permiten que dicho punto final establezca conexiones autenticadas y cifradas.

Cada certificado de entidad final se remonta, a través de una o varias autoridades de certificación intermedias, hasta una autoridad de certificación raíz de confianza. La verificación de esta cadena es la forma en que los sistemas confirman que un certificado es legítimo.

Tipos de autoridades de certificación

Autoridades de certificación públicas

Las autoridades de certificación públicas gozan de confianza por defecto en los navegadores, los sistemas operativos y los dispositivos. Emiten certificados para sitios web, aplicaciones y servicios de acceso público en los que los usuarios externos y los clientes necesitan verificar la identidad del servidor sin necesidad de realizar ninguna configuración manual.

Las organizaciones recurren a autoridades de certificación públicas (como DigiCert) para obtener TLS que protegen las interacciones con los clientes. Las autoridades de certificación públicas operan bajo una estricta gobernanza externa, que incluye los requisitos básicos del CA/Browser Forum, y sus certificados se registran a través de Certificate Transparency para garantizar la rendición de cuentas.

Autoridades de certificación privadas

Las CA privadas son gestionadas internamente por las organizaciones para emitir certificados destinados a casos de uso que no requieren confianza pública. Entre los usos habituales de las CA privadas se incluyen:

• Comunicaciones seguras entre servicios internos, incluidos los entornos en la nube en contenedores y conectados mediante API
• Sitios de intranet
• Certificado de Red Privada Virtual (VPN) o autenticación inalámbrica
• Identificación de dispositivos
• Cargas de trabajo e identificación de contenedores
• Proyectos de IoT (Internet de las Cosas)

Con una CA privada, la organización se convierte en su propio punto de referencia de confianza. Es ella quien decide qué identidades son válidas, emite certificados para sus propios servicios y dispositivos, y controla toda la jerarquía de confianza. Por eso, una CA privada puede autenticar comunicaciones de máquina a máquina que ninguna CA pública respaldaría jamás, lo que permite implementar arquitecturasde «confianza cero»en las redes internas.

Cómo elegir entre una CA pública y una privada

La elección entre autoridades de certificación públicas y privadas depende de quién deba confiar en el certificado.

Dimensión	CA Pública	CA Privada
¿Quién confía en ello?	Goza de confianza universal gracias a los almacenes raíz preinstalados en navegadores, sistemas operativos y dispositivos	Solo confían en ti los sistemas que estén configurados explícitamente para confiar en tu raíz
Caso de uso principal	Servicios orientados al usuario: sitios web públicos, API para clientes, servidores de correo electrónico	Infraestructura interna: mTLS, autenticación entre servicios, VPN, identidad de dispositivos y cargas de trabajo
Ancla de confianza	La CA pública (tercero externo)	Tu organización
Validación de identidad	Validación obligatoria del dominio o la organización según normas externas	Sea cual sea el esquema de identificación que definas (nombres de host internos, cuentas de servicio, identificadores de dispositivos)
Normas de funcionamiento	Requisitos básicos del CA/Browser Forum, normas obligatorias	Vuestra propia política interna
Vigencia de los certificados	Dictado por factores externos, con una tendencia constante a acortarse	Configúralo según lo que mejor se adapte a tu entorno
Tala pública	Registrado a través de Certificate Transparency	No hay nada registrado públicamente
Modelo de costes	Precio por certificado (o planes gratuitos como Let’s Encrypt)	No hay coste por certificado; los costes de infraestructura y operativos corren a tu cargo.
Economías de escala	No es viable para miles de certificados de corta duración	Diseñado para emisiones internas de gran volumen
Controlar	Limitada, sujeta a la política exterior	Control total sobre las políticas, la emisión y la jerarquía

El modelo: una CA pública cambia el control por la confianza universal y la externalización de operaciones, mientras que una CA privada cambia la carga operativa por el control total y las ventajas económicas propias de una escala interna. La mayoría de las organizaciones cuentan con ambas, una para cada límite de confianza.

Tipos de autoridades de certificación según el formato del certificado

Más allá de la distinción entre públicas y privadas, las CA también pueden clasificarse según los tipos de certificados que emiten.

Autoridades de certificación X.509

X.509 es el tipo de CA más habitual, utilizado para el correo electrónico seguro, el inicio de sesión, la autenticación web, las VPN y otras aplicaciones, tal y como se define en el RFC 5280. Los certificados X.509 son el formato estándar para SSL y constituyen la columna vertebral de la mayoría de las implementaciones de PKI. Definen la estructura de los certificados digitales, incluidos los nombres distinguidos, los períodos de validez, las extensiones y los algoritmos criptográficos utilizados para la firma.

Autoridades de certificación CVC

Las autoridades de certificación (CA) de CVC emiten certificados «Card Verifiable» (CV), que son certificados especializados diseñados para los pasaportes electrónicos de la UE con EAC (Control de Acceso Ampliado). Estos certificados permiten una verificación electrónica segura de la identidad para los controles fronterizos y los sistemas de identificación gubernamentales.

Autoridades de certificación SSH

Las autoridades de certificación (CA) de SSH emiten certificados en un formato específico del protocolo SSH, lo que supone una alternativa a la autenticación tradicional basada en claves SSH. En lugar de distribuir claves públicas individuales a cada servidor, las organizaciones pueden utilizar una CA de SSH para emitir certificados de corta duración en los que confía automáticamente cualquier servidor configurado para reconocer dicha CA.

Autoridades de certificación para la inscripción en C-ITS

Los certificados C-ITS (Sistemas de Transporte Inteligentes Cooperativos) utilizan un formato definido por la UE para las comunicaciones «Vehículo a todo» (V2X). Estos certificados especializados permiten una comunicación segura entre los vehículos, la infraestructura y los sistemas de gestión del tráfico, y desempeñan un papel fundamental en la seguridad del sector de la automoción y el transporte.

Cumplimiento de las normas de seguridad y de las autoridades de certificación

Las autoridades de certificación (CA) deben cumplir unas normas rigurosas de seguridad y cumplimiento normativo para mantener la confianza. Los marcos que rigen el funcionamiento de las CA abarcan normativas sectoriales, normas técnicas y requisitos de seguridad física.

Normas del sector y normativas

Las autoridades de certificación operan de conformidad con diversos marcos normativos, en función de su contexto de implementación:

• DORA(Ley de Resiliencia Operativa Digital): Se aplica a las entidades del sector financiero de toda la UE y exige la adopción de medidas de resiliencia digital, incluida la seguridad basada en la infraestructura de clave pública (PKI).
• NIS2(Directiva sobre seguridad de las redes y la información): Amplía los requisitos de ciberseguridad a las entidades esenciales e importantes de la UE.
• HIPAA(Ley de Portabilidad y Responsabilidad del Seguro Médico): exige el cifrado y controles de identidad para los datos sanitarios, lo que afecta directamente a la forma en que se implementan las autoridades de certificación (CA) en entornos médicos.
• PCI/DSS(Norma de Seguridad de Datos de la Industria de Tarjetas de Pago): exige el cifrado de los datos de los titulares de tarjetas, lo que requiere unas operaciones de CA sólidas para los sistemas de procesamiento de pagos.
• FedRAMP(Programa Federal de Gestión de Riesgos y Autorizaciones): Establece normas de seguridad para los servicios en la nube que utilizan las agencias federales de EE. UU.
• FIPS 140-2, 140-3:La norma FIPS 140-2 define los requisitos de seguridad para los módulos criptográficos, incluido el hardware software por las autoridades de certificación (CA) para la generación y el almacenamiento de claves. Estos requisitos se mantienen y, en algunos aspectos, se hacen más estrictos en la norma FIPS 140-3.

Requisitos básicos del CA/Browser Forum

El CA/Browser Forum establece normas que deben cumplir todas las autoridades de certificación (CA) de confianza pública. Estos «Requisitos Básicos» regulan las prácticas de emisión de certificados, los procedimientos de validación y las restricciones técnicas.

Un requisito destacable es el relativo a la entropía del número de serie del certificado. Los certificados que cumplan con la normativa deben contener, como mínimo, 64 bits de información totalmente aleatoria en sus números de serie. Esto sirve como defensa frente a los ataques de colisión basados en funciones hash sobre la firma del certificado, lo que refuerza la PKI frente a los ataques de preimagen.

Módulos Hardware y protección de claves

Las CA se integran con módulos hardware (HSM) para garantizar el almacenamiento seguro de claves y las operaciones criptográficas. Los HSM proporcionan entornos a prueba de manipulaciones en los que las claves privadas se generan, almacenan y utilizan sin quedar expuestas en texto plano en ningún momento.

El mantenimiento de la infraestructura para implementaciones de CA de alta seguridad incluye CA raíz fuera de línea alojadas en instalaciones físicamente protegidas, con estrictos controles de acceso, supervisión ambiental y registro de auditoría. Este enfoque por capas garantiza que, incluso si los sistemas operativos se ven comprometidos, el ancla de confianza raíz permanezca protegida.

Protocolos de las autoridades de certificación e integración técnica

Las CA admiten diversos protocolos de registro y gestión que permiten realizar operaciones automatizadas con certificados a gran escala. El protocolo adecuado depende del entorno, de los dispositivos implicados y del nivel de automatización requerido.

Protocolos habituales de inscripción

• SCEP(Protocolo simple de inscripción de certificados): Se utiliza ampliamente para la inscripción de dispositivos, sobre todo en infraestructuras de red y en la gestión de dispositivos móviles. El SCEP permite a los dispositivos solicitar y recibir certificados con una intervención manual mínima.
• CMP(Protocolo de gestión de certificados): un protocolo basado en estándares que gestiona todo el ciclo de vida de los certificados, incluyendo la emisión, la renovación, la revocación y la recuperación de claves.
• EST(Enrollment over Secure Transport): un protocolo de inscripción moderno, TLS, diseñado para sustituir al SCEP y ofrecer una mayor seguridad. El EST utiliza HTTPS para el transporte y admite la renovación de certificados y la reinscripción.
• ACME(Automatic Certificate Management Environment): Permite la emisión y renovación totalmente automatizadas de certificados; se asocia habitualmente con Let’s Encrypt, aunque cada vez se utiliza más para la automatización de la infraestructura de clave pública (PKI) interna.
• Inscripción automática de Microsoft:integra la implementación de certificados con Active Directory, lo que permite que los certificados se emitan automáticamente a los equipos y usuarios pertenecientes al dominio, en función de la configuración de la Política de grupo.

Formatos de certificados

El formato de certificado X.509 (definido en el RFC 5280) es la estructura más habitual para los certificados digitales. Un certificado X.509 incluye campos como el nombre distinguido del sujeto, el nombre distinguido del emisor, el periodo de validez (fechas de inicio y fin), la clave pública del sujeto, un número de serie y la firma digital de la autoridad de certificación (CA). Otros formatos de certificado habituales son los certificados OpenPGP, los certificados OpenSSH, los certificados CVC, etc.

La CSR (solicitud de firma de certificado) que inicia el proceso de emisión incluye datos identificativos del solicitante (como un nombre distintivo) y la clave pública que este prefiere. La CSR debe firmarse con la clave privada del solicitante para demostrar que es el titular de la misma.

Autoridades de certificación y casos de uso emergentes

Identidad de IoT

En IoT , las autoridades de certificación (CA) constituyen la base para garantizarla identidad segura de los dispositivos. Cada dispositivo recibe un certificado único durante su fabricación o configuración, lo que permite la autenticación mutua entre dispositivos y servicios.

Una implementación típica de la jerarquía de CA dentro de un IoT es la siguiente: una CA raíz (que se mantiene fuera de línea) emite certificados a una Autoridad de Certificación de Productos (PAA), la cual delega en Autoridades Intermedias de Certificación de Productos (PAI) para los distintos tipos de productos. Cada PAI emite un Certificado de Certificación de Dispositivo (DAC) único para cada dispositivo físico. La raíz de confianza del dispositivo genera un par de claves pública/privada y una solicitud de certificado (CSR), que la PKI del fabricante firma y devuelve como DAC.

Este enfoque garantiza que cada dispositivo conectado cuente con una identidad única y verificable, basada en una cadena de certificados de confianza, que va desde el propio dispositivo hasta la CA raíz del fabricante.

Preparación para la criptografía poscuántica

A medida que avanza la informática cuántica, las autoridades de certificación (CA) deben prepararse para la transición a algoritmos resistentes a los ataques cuánticos. Los algoritmos actuales de clave pública (RSA, ECDH, ECDSA, etc.) son vulnerables a los ataques de ordenadores cuánticos suficientemente potentes, lo que significa que los certificados que emiten hoy en día las CA podrían verse comprometidos en el futuro.

Las plataformas modernas de CA ya son compatibles con algoritmosde criptografía poscuántica. Por ejemplo, EJBCA algoritmos de firma poscuántica como DILITHIUM5, que solo pueden utilizarse junto con claves DILITHIUM5. También está disponible la emisión de certificados híbridos, que combina firmas clásicas y resistentes a la computación cuántica en un único certificado, lo que permite a las organizaciones alcanzar la «criptoagilidad» antes de que se materialice la amenaza cuántica.

Cómo Keyfactor ayudarte Keyfactor

La gestión de autoridades de certificación a gran escala requiere algo más que procesos manuales. Keyfactor unaplataformaunificada para las organizaciones que gestionan autoridades de certificación públicas, privadas o ambas.

• EJBCA :Una plataforma de CA y PKI completa y escalable que admite los tipos de certificados X.509, CVC, SSH y C-ITS. EJBCA controles de seguridad integrados, automatización y gestión del ciclo de vida, y admite múltiples CA, autoridades de validación y autoridades de registro en una única implementación.
• Keyfactor Command:Visibilidad y gestión centralizadas de todas las autoridades de certificación (CA) en un único panel de control. Command CA públicas (como DigiCert), CA de Microsoft y CA privadas internas, y ofrece un inventario de certificados en tiempo real, análisis automatizados, supervisión y funciones de renovación con un solo clic. También integra autoridades de certificación con criptografía poscuántica, incluidas aquellas que utilizan MLDSA-65 y algoritmos híbridos, lo que ofrece a las organizaciones una vía para prepararse para la era cuántica dentro de su infraestructura de autoridades de certificación existente. Los administradores pueden configurar programas de análisis, establecer umbrales de alerta para la emisión masiva de certificados y gestionar los ciclos de vida de los certificados en toda la organización.
• PKI como servicio:Combina una PKI gestionada con la automatización de certificados, lo que reduce la carga operativa que supone gestionar una infraestructura interna de CA, al tiempo que se mantiene un control total sobre el ciclo de vida de los certificados.
• Criptoagilidad y preparación para la era poscuántica:la compatibilidad con certificados híbridos y algoritmos resistentes a la computación cuántica garantiza que las organizaciones puedan adaptar su infraestructura de CA a medida que evolucionan los estándares criptográficos.

Solicita una demostraciónpara descubrir cómo Keyfactor modernizar las operaciones de tu autoridad de certificación (CA) y preparar tu infraestructura de clave pública (PKI) para el futuro.