Un certificado X.509 es una salvaguarda vital contra los suplantadores maliciosos de la red. Sin la autenticación del servidor x.509, los puntos de acceso maliciosos, los routers comprometidos, etc. pueden iniciar ataques de intermediario.
X.509 es más utilizado para las conexiones SSL/TLS conexiones para garantizar que el cliente (por ejemplo, un navegador web) no sea engañado por un suplantador malicioso que se haga pasar por un sitio web conocido y de confianza.
Sin embargo, los certificados X.509 protegen las comunicaciones de red de todo tipo:
- Protección de las comunicaciones por Internet
- Proteger las comunicaciones de la intranet
- Protección de las comunicaciones por correo electrónico
- Protección de las comunicaciones entre dispositivos
Este artículo no pretende ofrecer una visión exhaustiva de ningún estándar o marco X.509. Su objetivo es más bien 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 comunicaciones por internet.
X.509 para comunicaciones por Internet
SSL/TLS Apretón de manos
Durante las conexiones SSL/TLS , el servidor se autentica según los protocolos handshake y record. Al iniciar el protocolo handshake, el servidor presenta un certificado X.509 firmado al cliente. En la mayoría de las sesiones de navegación seguras sólo es necesario validar el servidor. La autenticación del cliente es menos común, pero requeriría que el servidor verificara también 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 requerido y la información contenida en un certificado X.509 permiten al cliente autenticar y verificar con confianza la integridad de la identidad certificada.
Tiendas 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 CA Raíz de confianza, esta lista se denomina "Almacén de Confianza". Por ejemplo, en el momento de escribir esto, el almacén de confianza de Firefox contiene 150 certificados raíz en los que confía automáticamente su navegador web.
En cambio, Google Chrome utiliza el almacén de confianza del sistema operativo 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 un ID único que debe aparecer en los certificados emitidos desde esa raíz. Nota: Desde 2015, Chrome exige que todos los certificados EV utilicen Certificate Transparency.
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 jerárquica de certificación que enlace recursivamente con al menos una CA raíz incluida 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 las llamadas telefónicas internacionales. Si cada código de país está representado por una CA raíz, los acuerdos de certificación cruzada entre las CA ampliarían el alcance de la llamada. Cuando dos CA raíz firman los certificados de la otra, confían intrínsecamente en todos los demás certificados de la ruta de la otra.
Formato del certificado
El emisor y el sujeto de un certificado deben proporcionar información específica para que la certificación sea válida. La norma X.509 define estos 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úmero de serie: Número de serie único que se crea para cada certificado creado por una CA.
- firma: El algoritmo utilizado para generar la firma. Debe coincidir con el signatureAlgorithm.
- issuer: El nombre distinguido (DN) de la CA emisora.
- validez: Dos fechas: desde notBefore (fecha de emisión) hasta notAfter (fecha de expiración).
- asunto: Nombre distinguido de la entidad validada a la que se emite el certificado.
- subjectPublicKeyInfo: Algoritmo y valor de la clave pública (RSA, DSA o Diffie-Hellman).
Campos de extensiones X.509 versión 3:
- extnId: Se utiliza para identificar esta extensión.
- crítica: Es un valor booleano que se utiliza para informar si la extensión es vital o no.
- extnValue: Contiene una cadena de octetos que podría ser interpretada libremente por una comunidad que utilice una extensión opcional.
Nota: Muchas extensiones habilitadas por X.509 Versión 3 son esenciales para las relaciones comerciales dentro y a través de PKI entre dominios PKI.
Codificación de certificados X.509
X.509 no define cómo debe codificarse el contenido de los certificados para almacenarlo en archivos. Sin embargo, para almacenar certificados X.509 en archivos se utilizan dos esquemas de codificación de uso común, DER y PEM.
DER (Distinguished Encoding Rules) es un esquema de codificación de objetos de datos que puede utilizarse para codificar objetos de certificado. DER es el formato de archivo más popular para almacenar certificados X.509. Los certificados codificados con 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 problemas.
PEM (Privacy Enhanced Mail) es un esquema de codificación de correo electrónico cifrado que puede utilizarse para convertir certificados codificados con 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 X509 añadió dos nuevos campos: Identificador único del emisor e Identificador único del sujeto. En la actualidad, el IETF considera obsoletos estos campos, por lo que no deben utilizarse en los certificados. El uso generalizado de Internet inspiró un mayor desarrollo del sistema de nomenclatura jerárquica.
Desde 1996, la versión 3 de X.509 permite añadir múltiples extensiones a un certificado. Las extensiones proporcionan información mejorada sobre el uso de claves, políticas y restricciones de los certificados, formas de nombre alternativas, etc.
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 losSin una gestión adecuada de los certificados, los equipos de seguridad dejan a su empresa expuesta a interrupciones, infracciones y auditorías fallidas.
Visite un inventario de su actual X.509 gestión de certificados de certificados y evalúe si es necesaria una nueva solución es necesaria para abordar la continuo aumento de sus certificados digitales.
