Certificados TLS de servidor
Tráfico web seguro a gran escala
Inventario de certificados
Descubrir y rastrear todos los certificados
Certificados DevOps
Automatizar para pipelines CI/CD
Cifrado de correo electrónico
S/MIME para correo electrónico empresarial
Una Autoridad de Certificación es la entidad de confianza que emite, firma y gestiona certificados digitales. Sin las AC, no habría una forma fiable de verificar identidades en línea. Cada conexión segura comienza con la confianza en una AC.
Imagine que necesita comprar una casa. Antes de que el banco entregue la hipoteca, un notario verifica la identidad del vendedor', comprueba que los documentos de la propiedad son legítimos y sella todo con un sello oficial. Sin el notario, ni usted ni el banco podrían confiar en que la transacción sea válida.
Una Autoridad de Certificación (CA) desempeña el mismo papel en el mundo digital. Es la tercera parte de confianza que verifica la identidad de una entidad (un sitio web, una organización, un dispositivo) y emite un certificado digital confirmando esa identidad. El certificado vincula un clave pública a la identidad verificada, y la firma digital de la CA's en el certificado es el sello que lo hace confiable.
Cada vez que su navegador establece una conexión HTTPS, verifica si el certificado del servidor fue emitido por una CA que reconoce. Si la CA es de confianza, la conexión continúa. Si no, ve una advertencia de seguridad. Este sencillo mecanismo (verificar el emisor, confiar en el certificado) es la base de la confianza en línea.
No todas las Autoridades de Certificación sirven al mismo propósito ni operan al mismo nivel. Comprender las diferencias es importante al diseñar o evaluar una PKI.
Los CAs públicos son confiados por navegadores, sistemas operativos y dispositivos en todo el mundo. Empresas como DigiCert, Let's Encrypt y Sectigo operan CAs públicos. Sus certificados raíz están preinstalados en almacenes de confianza, las listas curadas de CAs de confianza que se incluyen con cada navegador y SO. Los CAs públicos son necesarios cuando necesita certificados que usuarios externos o el público en general validarán, como certificados TLS para sitios web de cara al público.
Los CA privados (o internos) son operados por organizaciones para su propio uso. Emiten certificados para servicios internos, autenticación de empleados, identidad de dispositivos y comunicación entre microservicios. Debido a que no están en almacenes de confianza públicos, sus certificados solo son confiados por los sistemas que la organización configura. Los CA privados le dan control total sobre políticas de certificados, períodos de validez y reglas de emisión.
Una Root CA se encuentra en la parte superior de la jerarquía de confianza. Su certificado está autofirmado y almacenado sin conexión en entornos altamente seguros, a menudo en hardware security modules (HSMs) dentro de bóvedas cerradas. Las CA raíz rara vez emiten certificados directamente. En su lugar, firman los certificados de Intermediate CAs, que manejan la emisión día a día. Este diseño en capas limita la exposición: si una CA intermedia se ve comprometida, solo sus certificados necesitan ser revocados, no toda la raíz. Esta arquitectura forma la chain of trust.
El proceso de emisión sigue una secuencia bien definida. Ya sea que esté solicitando un certificado de una CA pública para su sitio web o de una CA privada para una API interna, los pasos son fundamentalmente los mismos.
El solicitante genera una par de claves pública/privada. La clave privada permanece secreta y nunca abandona el sistema del solicitante. La clave pública se incluirá en el certificado.
El solicitante crea una CSR, un mensaje estructurado que contiene la clave pública, el nombre de sujeto deseado (p.ej., www.example.com), y otros detalles identificativos. La CSR está firmada digitalmente con la clave privada del solicitante, demostrando que posee la clave correspondiente.
La CA verifica la identidad del solicitante's. Para un certificado TLS público, esto podría implicar demostrar el control del dominio mediante un registro DNS o un desafío HTTP. Para un certificado validado por la organización, significa revisar documentos de registro legal. Para una CA privada, la verificación podría seguir políticas internas, como revisar un registro de Active Directory o un flujo de aprobación.
Una vez verificada la identidad, la CA construye el certificado, incorporando la clave pública, la información del sujeto, las fechas de validez y las extensiones, y lo firma con la CA's propia clave privada. Esta firma es lo que los clientes verificarán para establecer la confianza.
El certificado firmado se devuelve al solicitante, quien lo instala en el servidor, dispositivo o aplicación correspondiente. A partir de este momento, cualquier cliente que confíe en la CA emisora aceptará el certificado como válido.
La confianza en el sistema CA no es ciega. Está deliberadamente diseñada a través de almacenes de confianza y cadenas de certificados.
Cada navegador y sistema operativo incluye una lista preconfigurada de certificados raíz de CA de confianza. Apple, Google, Mozilla y Microsoft mantienen cada uno sus propios programas de almacén de confianza con requisitos estrictos que las CAs deben cumplir, incluidos auditorías regulares, cumplimiento de normas industriales y reportes transparentes. Si una CA no cumple con estos requisitos, su certificado raíz puede ser eliminado, haciendo instantáneamente que todos los certificados que emitió no sean de confianza.
Cuando su navegador recibe un certificado, no solo verifica si el propio certificado es de confianza. Sigue la cadena de certificados, desde el certificado de entidad final, pasando por una o más CAs intermedias, hasta una CA raíz en el almacén de confianza. Cada enlace en la cadena se verifica comprobando la firma digital del certificado superior. Si cada firma es válida y la raíz es de confianza, toda la cadena es de confianza.
A veces, una nueva CA necesita ganar confianza antes de que su propia raíz se añada a los almacenes de confianza. A través de la certificación cruzada, una CA ya confiable firma el certificado de la nueva CA's, creando una ruta de confianza alternativa. Esta técnica fue utilizada por Let's Encrypt en sus primeros años, cuando su raíz fue firmada cruzadamente por IdenTrust.
Las organizaciones que operan CAs privadas distribuyen sus certificados raíz de CA a los sistemas internos mediante políticas de grupo, perfiles MDM o herramientas de gestión de configuración. Esto crea un almacén de confianza privado que existe junto al público, lo que permite validar los certificados internos sin involucrar ninguna CA pública.
Porque las CA son centrales para el modelo de confianza, una CA comprometida es uno de los eventos más graves en ciberseguridad. Si un atacante obtiene acceso a la clave privada de una CA, puede emitir certificados fraudulentos para cualquier dominio, habilitando ataques de hombre en el medio que son invisibles para los usuarios finales.
La historia ofrece ejemplos contundentes. En 2011, DigiNotar, una CA holandesa, fue vulnerada, y los atacantes emitieron certificados fraudulentos para Google, Yahoo y otros dominios importantes. El incidente provocó que la raíz de DigiNotar' fuera eliminada de todas las principales tiendas de confianza y que la empresa se declarara en bancarrota. Comodo sufrió una vulneración similar ese mismo año. Estos eventos subrayaron la necesidad de prácticas de seguridad de CA robustas y dieron lugar a iniciativas como Transparencia de Certificados.
Cuando un certificado necesita ser invalidado antes de su fecha de expiración, ya sea por una compromisión de clave, un cambio de propiedad, o una violación de la CA, la CA revoca lo. Los certificados revocados se publican en Listas de Revocación de Certificados (CRLs) o se verifican en tiempo real mediante el Protocolo de Estado de Certificado en Línea (OCSP). Los navegadores y clientes consultan estos mecanismos para asegurarse de que no confíen en un certificado que ha sido revocado.
Los CA modernos protegen contra compromisos mediante claves raíz offline almacenadas en HSM, controles físicos estrictos, auditorías regulares de WebTrust o ETSI, y la participación en registros de Transparencia de Certificados. Para los CA privados, las organizaciones deben aplicar los mismos principios: mantener los CA raíz offline, usar CA intermedios para la emisión y monitorear toda la actividad de certificados.
Elegir entre una CA pública y una privada depende de quién necesita confiar en el certificado y de cuánto control necesitas sobre las políticas de emisión.
Usa un CA público. Los visitantes necesitan confiar en su certificado sin ninguna configuración especial. Sus navegadores ya incluyen la raíz del CA público en su almacén de confianza.
Utilice un private CA. Usted controla el almacén de confianza de todos los sistemas internos, por lo que no es necesario involucrar una CA pública. Esto también evita costos por certificado y le brinda control total sobre las políticas.
Utilice un private CA. Los certificados de cliente para acceso VPN, autenticación Wi‑Fi o inicio de sesión con tarjeta inteligente deben ser emitidos por una CA interna cuya raíz está desplegada en los dispositivos corporativos.
Utilice un CA privada. Los dispositivos que fabrica o administra se autentican en su infraestructura usando certificados que controla. Una CA privada le permite definir períodos de validez personalizados, algoritmos de clave y políticas de revocación adaptadas a sus dispositivos.
Utilice un CA pública para software distribuido a clientes externos. Utilice un CA privada para scripts y herramientas internos donde controla los puntos finales.
Usa un CA privado. La comunicación de servicio a servicio dentro de tu infraestructura debe usar certificados de una CA interna. Esta es la base de arquitecturas de confianza cero donde cada servicio prueba su identidad a cada otro servicio.
Muchas organizaciones usan ambos. Las CA públicas manejan certificados externos, mientras que una CA privada, a menudo gestionada a través de una plataforma como Evertrust PKI, maneja todo lo interno. La clave es entender los límites de confianza y elegir en consecuencia.
Ejecute su propia CA privada: Evertrust PKI le permite implementar una Autoridad de Certificación privada totalmente equipada con jerarquías de CA raíz e intermedias, perfiles de certificado personalizables y emisión basada en políticas, todo a través de una plataforma moderna y auditable.
Automatice la emisión a gran escala: El soporte para ACME, SCEP, EST y APIs REST significa que los certificados pueden ser solicitados y desplegados automáticamente por servidores, dispositivos y pipelines CI/CD, sin intervención manual requerida.
Aplicar gobernanza: Definir políticas de certificados, flujos de aprobación, restricciones de nombres y requisitos de algoritmos de clave. Cada emisión se registra y es auditable, cumpliendo las expectativas de gobernanza de PKI empresarial implementaciones.
Visibilidad unificada: Ya sea que sus certificados provengan de CAs públicas, CAs privadas o ambas, Evertrust ofrece un panel único para monitorear, alertar y reportar todo su inventario de certificados.
