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
Las contraseñas pueden ser robadas, suplantadas mediante phishing o forzadas por fuerza bruta. Los certificados de autenticación de cliente sustituyen los secretos compartidos por una prueba criptográfica de identidad, permitiendo una autenticación más fuerte y sin contraseña para usuarios, dispositivos y servicios en entornos empresariales.
Durante décadas, la combinación de nombre de usuario y contraseña ha sido la forma predeterminada de demostrar identidad en línea. Pero las contraseñas son fundamentalmente defectuosas: pueden ser adivinadas, interceptadas, reutilizadas en varios servicios o obtenidas mediante phishing. Incluso con políticas de contraseñas robustas, el robo de credenciales sigue siendo la causa principal de violaciones de datos año tras año.
Los certificados de autenticación de cliente ofrecen un enfoque fundamentalmente diferente. En lugar de demostrar quién eres mediante algo que sabes (una contraseña), lo demuestras con algo que posees: un certificado digital vinculado a una clave privada almacenada de forma segura en tu dispositivo. El servidor no solo verifica un secreto compartido; verifica una firma criptográfica que solo tu clave privada podría haber generado.
Este modelo está en el corazón de mutual TLS (mTLS), donde tanto el cliente como el servidor presentan certificados y verifican la identidad de each other's. Mientras que TLS estándar garantiza que you're hablando con el servidor correcto, mTLS añade la otra mitad: el servidor también confirma que tú eres quien afirmas ser.
En un apretón de manos TLS estándar, solo el servidor presenta un certificado. En TLS mutuo, el servidor también solicita un certificado del cliente. Aquí's cómo se desarrolla el proceso paso a paso:
El cliente inicia una conexión al servidor. El servidor responde con su propio certificado TLS, que el cliente valida contra autoridades de confianza Autoridades de certificación. Hasta ahora, esto es idéntico a una conexión HTTPS normal.
El servidor envía un CertificateRequest mensaje, especificando qué Autoridades de Certificación confía para los certificados de cliente. Esto le dice al cliente: "Necesito que pruebes también tu identidad."
El cliente selecciona un certificado coincidente de su almacén local y lo envía, junto con un CertificateVerify mensaje, un firma digital sobre los datos del apretón de manos, creado con la clave privada del client's.
El servidor verifica el certificado del client's cadena de confianza, verifica que hasn't no haya sido revocado, y valida la firma. Si todo está correcto, la conexión se establece, y el servidor sabe exactamente quién (o qué) está en el otro extremo.
Todo el proceso ocurre de forma transparente durante el apretón de manos TLS, típicamente en milisegundos. Desde la perspectiva del usuario, la experiencia puede ser completamente fluida: sin solicitud de contraseña, sin códigos de un solo uso. El certificado habla por ellos.
Los certificados de cliente se utilizan en una amplia variedad de escenarios donde se requiere una autenticación fuerte y no falsificable. Aquí están los más comunes:
Las soluciones VPN empresariales como Cisco AnyConnect, OpenVPN y WireGuard pueden requerir certificados de cliente para el establecimiento de la conexión. Esto garantiza que solo los dispositivos gestionados y autorizados (no cualquier persona con credenciales robadas) puedan acceder a la red corporativa. Cuando se pierde un portátil o un empleado se marcha, revocar su certificado corta el acceso al instante.
En un modelo de confianza cero, cada solicitud debe ser autenticada y autorizada, sin importar la ubicación de la red. Los certificados de cliente proporcionan una verificación continua y criptográfica de identidad en la capa de transporte. Mallas de servicio como Istio y Linkerd utilizan mTLS entre cada microservicio, garantizando que incluso el tráfico interno este-oeste esté autenticado y cifrado.
Las redes WPA2/WPA3-Enterprise utilizan el estándar 802.1X para el control de acceso a la red. Con EAP-TLS, los dispositivos presentan un certificado de cliente al servidor RADIUS antes de obtener acceso a la red. Esto elimina por completo las contraseñas compartidas de WiFi y vincula cada conexión a una identidad de dispositivo específica, lo que lo hace ideal para entornos corporativos y universitarios.
Cuando los servicios se comunican a través de APIs, los certificados de cliente sustituyen a las claves API o tokens OAuth en la capa de transporte. Esto es particularmente común en los servicios financieros, de salud y gubernamentales, donde los requisitos regulatorios exigen una fuerte autenticación mutua. A diferencia de las claves API, los certificados no pueden ser accidentalmente comprometidos en un repositorio Git ni filtrados en los registros.
Los certificados de cliente no son el único mecanismo de autenticación disponible, y comprender dónde encajan en relación con otros enfoques le ayuda a elegir la herramienta adecuada para cada escenario.
Las contraseñas son un secreto compartido: si cualquiera de los lados se ve comprometido, la credencial es inútil. Los certificados de cliente utilizan criptografía asimétrica: la clave privada nunca abandona el dispositivo, así que no hay nada que robar del lado del servidor. Son inmunes al phishing, al relleno de credenciales y a los ataques de reutilización de contraseñas.
MFA agrega un segundo factor (código SMS, TOTP, notificación push) además de una contraseña. Los certificados de cliente pueden servir como un factor único y fuerte que combina la posesión (el dispositivo con la clave) y, a menudo, un paso de autenticación local (PIN o biométrico para desbloquear el almacén de claves). En muchos marcos regulatorios, un certificado vinculado al hardware califica como multifactor por sí mismo.
Las passkeys de FIDO2 también utilizan criptografía asimétrica y resisten el phishing. Sin embargo, FIDO2 está diseñado para autenticación basada en la web y orientada al usuario, mientras que los certificados de cliente operan en la capa TLS, lo que los hace adecuados para máquina a máquina, VPN, WiFi y escenarios donde los flujos basados en el navegador aren't disponibles.
Las claves API y los tokens portadores son simples de implementar pero son secretos estáticos que pueden filtrarse. Los certificados de cliente ofrecen expiración incorporada, revocación y vinculación de identidad. También autentican en la capa de transporte, antes de que se ejecute cualquier lógica de aplicación, reduciendo significativamente la superficie de ataque.
Desplegar certificados de cliente con éxito requiere una planificación cuidadosa en tres dimensiones: aprovisionamiento, experiencia de usuario, y revocación.
Provisionamiento es el paso más crítico. Cada usuario o dispositivo necesita un certificado único emitido por una autoridad interna de confianza Autoridad de Certificación. Para implementaciones pequeñas, la inscripción manual puede ser suficiente. A gran escala, necesita protocolos de inscripción automatizados: SCEP para dispositivos heredados, EST para sistemas modernos, o ACME para entornos que ya lo usan. El objetivo es colocar el certificado correcto en el dispositivo correcto con la mínima fricción para el usuario.
Experiencia de usuario puede hacer o romper la adopción. Si se solicita a los usuarios que seleccionen un certificado de un cuadro de diálogo confuso cada vez que se conectan, resistirán el cambio. Los despliegues modernos usan políticas de certificado y perfiles MDM para preconfigurar la selección de certificados, de modo que la autenticación ocurra silenciosamente en segundo plano. Cuando se hace bien, la autenticación basada en certificados es realmente más más conveniente que las contraseñas; no hay nada que escribir, recordar o rotar manualmente.
Revocación es la red de seguridad. Cuando un dispositivo se pierde, un empleado se va, o una clave se ve comprometida, necesita revocar el certificado de inmediato. Esto significa que su infraestructura debe soportar la verificación de revocación en tiempo real (a través de puntos de distribución CRL o respondedores OCSP), y sus servidores deben estar configurados para aplicar estas verificaciones. Un certificado revocado debería ser tan inútil como un pasaporte cancelado.
Mientras los certificados de cliente ofrecen ventajas de seguridad convincentes, implementarlos en una empresa introduce desafíos operativos que las organizaciones deben abordar:
Una organización con 10,000 empleados podría necesitar 30,000 o más certificados de cliente en laptops, teléfonos y tabletas. Cada uno tiene su propio ciclo de vida: inscripción, renovación y posible revocación. Sin automatización, la carga operativa se vuelve insostenible a medida que aumenta el número de certificados.
Windows, macOS, Linux, iOS y Android manejan los almacenes de certificados de manera diferente. Cada plataforma tiene su propio llavero o gestor de credenciales, diferentes API para la inscripción y distintos comportamientos cuando un servidor solicita un certificado de cliente. Garantizar una experiencia consistente y fiable en todas las plataformas requiere una configuración y pruebas significativas.
Plataformas de gestión de dispositivos móviles (Intune, Jamf, Workspace ONE) son el vehículo principal para distribuir certificados de cliente a dispositivos gestionados. Integrar su CA con su MDM (a través de conectores SCEP o EST) es esencial para una provisión sin problemas. Pero cada MDM tiene sus propias particularidades, y las configuraciones erróneas pueden dejar los dispositivos sin certificados válidos o, peor, con certificados que don't coinciden con la política esperada.
Estos desafíos no disminuyen el valor de los certificados de cliente; subrayan la necesidad de un plataforma de gestión centralizada que maneja la inscripción, renovación, revocación y monitoreo en todos los dispositivos y plataformas desde una única vista.
Emitir certificados de cliente a gran escala: Evertrust PKI actúa como su Autoridad de Certificación interna, emitiendo certificados de cliente a través de SCEP, EST, CMP y ACME. Ya sea que esté inscribiendo a 100 usuarios o a 100,000 dispositivos, la plataforma gestiona el aprovisionamiento automáticamente.
Visibilidad de ciclo de vida completo: Evertrust CLM le brinda un inventario en tiempo real de cada certificado de cliente en su entorno: quién lo posee, cuándo expira y si cumple con sus políticas de certificado.
Integración perfecta de MDM: Conectores nativos para las principales plataformas MDM le permiten enviar certificados de cliente a dispositivos gestionados sin desarrollo personalizado. Los certificados se inscriben, renuevan y revocan a través de sus flujos de trabajo de gestión de dispositivos existentes.
Revocación instantánea: Cuando un dispositivo se pierde o un empleado se marcha, revoque su certificado de cliente inmediatamente a través del panel de Evertrust o API. OCSP y la distribución de CRL aseguran que las partes confiables sean notificadas en tiempo real.
