Un certificado X.509 es una salvaguarda vital contra los suplantadores maliciosos de red. Sin la autenticación de servidor X.509, los ataques de intermediario (man-in-the-middle) pueden ser iniciados por puntos de acceso maliciosos, routers comprometidos, etc.
X.509 se utiliza principalmente para conexiones SSL/TLS para asegurar que el cliente (p. ej., un navegador web) no sea engañado por un suplantador malicioso que finja ser un sitio web conocido y confiable.
Sin embargo, los certificados X.509 aseguran las comunicaciones de red de todo tipo:
- Asegurar las comunicaciones por internet
- Asegurar las comunicaciones por intranet
- Asegurar las comunicaciones por correo electrónico
- Asegurar las comunicaciones de dispositivos
Este artículo no pretende ofrecer una visión general exhaustiva de ningún estándar o marco X.509. Más bien, este artículo tiene como objetivo simplificar la comprensión de los certificados digitales X.509 y cómo se utilizan para establecer conexiones seguras entre un cliente y un servidor durante las comunicaciones por internet.
X.509 para comunicaciones por internet
Handshake SSL/TLS
Durante las conexiones SSL/TLS, el servidor se autentica de acuerdo con los protocolos de handshake y de registro. Al iniciar el protocolo de handshake, el servidor presenta un certificado X.509 firmado al cliente. Solo el servidor necesita ser validado en la mayoría de las sesiones de navegación segura. La autenticación de cliente es menos común, pero requeriría que el servidor también verificara el certificado del cliente.
La firma del certificado X.509 debe ser verificada por el cliente antes de establecer una conexión HTTPS. El formato y la información requeridos contenidos en un certificado X.509 permiten al cliente autenticar y verificar con confianza la integridad de la identidad certificada.
Almacenes de confianza
Los navegadores y aplicaciones cliente dependen en gran medida de su confianza en las Autoridades de Certificación (CA) para la correcta validación de los certificados X.509. Cada aplicación cliente y Sistema Operativo (SO) mantiene una lista de Certificados Raíz de CA de confianza; esta lista se denomina 'Almacén de confianza'. Por ejemplo, en el momento actual de la redacción, el almacén de confianza de Firefox contiene 150 certificados raíz que son automáticamente confiables por su navegador web.
En contraste, Google Chrome utiliza el almacén de confianza del sistema operativo (SO) subyacente para determinar si un certificado es de confianza, con algunas excepciones. Google mantiene una lista codificada de certificados raíz 'EV-Qualified', junto con una ID única que debe aparecer en los certificados emitidos desde esa raíz. Nota: Desde 2015, Chrome requiere que todos los certificados EV utilicen la Transparencia de Certificados.
Cadenas de confianza jerárquicas
Como parte del proceso de verificación X.509, cada certificado debe estar firmado por la misma CA emisora nombrada en su certificado. El cliente debe poder seguir una ruta de certificación jerárquica que se vincule recursivamente a al menos una CA raíz listada en el almacén de confianza del cliente.
Sin embargo, la estructura de la ruta de certificación puede ser jerárquica (como un árbol con una única CA raíz de origen) o no jerárquica (como un bosque con muchas CA raíz con certificación cruzada). Es más fácil entender la certificación cruzada imaginando llamadas telefónicas internacionales. Si cada código de país está representado por una CA raíz, entonces los acuerdos de certificación cruzada entre las CA ampliarían el alcance de las llamadas. Cuando dos CA raíz firman los certificados de la otra, confían inherentemente en todos los demás certificados en las rutas de la otra.
Formato del certificado
El emisor y el sujeto de un certificado deben proporcionar información específica para una certificación válida. El estándar X.509 define esos requisitos.
Campos del certificado X.509:
- versión: El número de versión del certificado X.509. (si se omite, se asume la versión 1)
- númeroDeSerie: Número de serie único que se crea para cada certificado emitido por una CA.
- firma: El algoritmo utilizado para generar la firma. Debe coincidir con el signatureAlgorithm.
- emisor: El nombre distinguido (DN) de la CA emisora.
- validez: Dos fechas: desde notBefore (fecha de emisión) hasta notAfter (fecha de caducidad).
- sujeto: Nombre distinguido de la entidad validada a la que se emite el certificado.
- subjectPublicKeyInfo: El algoritmo y el valor de la clave pública (RSA, DSA o Diffie-Hellman).
Campos de extensiones de la versión 3 de X.509:
- extnId: Se utiliza para identificar esta extensión.
- crítico: Es un valor booleano que se utiliza para indicar si la extensión es vital o no.
- extnValue: Contiene una cadena de octetos que puede ser interpretada libremente por una comunidad que utilice una extensión opcional.
Nota: Muchas extensiones habilitadas por la versión 3 de X.509 son esenciales para las relaciones comerciales dentro y entre los dominios de PKI.
Codificación de certificados X.509
X.509 no define cómo deben codificarse los contenidos de los certificados para almacenarlos en archivos. Sin embargo, se utilizan dos esquemas de codificación comunes para almacenar certificados X.509 en archivos: DER y PEM.
DER (Distinguished Encoding Rules) es un esquema de codificación de objetos de datos que se puede utilizar para codificar objetos de certificado. DER es el formato de archivo más popular para almacenar certificados X.509. Los certificados codificados en DER son archivos binarios y no pueden ser leídos por editores de texto, pero pueden ser procesados por navegadores web y algunas aplicaciones sin ningún problema.
PEM (Privacy Enhanced Mail) es un esquema de codificación de correo electrónico cifrado que se puede utilizar para convertir certificados codificados en DER en archivos de texto.
Historial de versiones de X.509
En 1988, se publicó la versión 1 de X.509. La disposición jerárquica de los nombres distinguidos seguía las reglas de X.500. Estas reglas se inspiraron en los sistemas utilizados para asignar números de teléfono a nivel mundial.
En 1993, la versión 2 de X.509 añadió dos nuevos campos: Identificador Único del Emisor e Identificador Único del Sujeto. Estos campos ahora se consideran obsoletos por el IETF y no deben utilizarse en sus certificados. El uso generalizado de Internet inspiró un mayor desarrollo del sistema de nombres jerárquico.
Desde 1996, la versión 3 de X.509 permite múltiples extensiones que pueden añadirse a un certificado. Las extensiones proporcionan información mejorada sobre el uso de claves, políticas y restricciones de certificados, formas de nombres alternativos y más.
Próximos pasos
Como menciona Gartner, los certificados X.509 son fundamentales para establecer la confianza digital en el mundo digital. Sin una gestión adecuada de estos certificados, los equipos de seguridad exponen a su empresa a interrupciones, filtraciones y auditorías fallidas.
Realice un inventario de sus actuales X.509 capacidades de gestión de certificados y evalúe si una nueva solución es necesaria para abordar el continuo aumento de sus certificados digitales.
