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
X.509 es el estándar internacional que define el formato de los certificados digitales. Cada certificado TLS, cada certificado de firma de código y cada certificado de autenticación de cliente que encuentres sigue esta especificación. Entender X.509 significa comprender el lenguaje de la confianza digital.
X.509 es un estándar definido originalmente por la ITU-T (Unión Internacional de Telecomunicaciones, Sector de Normalización de Telecomunicaciones) como parte del marco de servicios de directorio X.500. Publicado por primera vez en 1988, fue diseñado inicialmente para asociar claves públicas con entradas de directorio en sistemas de telecomunicaciones globales. Durante las décadas siguientes, X.509 evolucionó mucho más allá de su alcance original para convertirse en el formato universal para certificados digitales en la infraestructura de clave pública.
Today, the X.509 standard (formalized by the IETF in RFC 5280) governs the structure of every certificate used in TLS/SSL, S/MIME, code signing, and client authentication. When your browser validates a website's identity, it is parsing an X.509 certificate. When a server authenticates a client through mutual TLS, it is reading X.509 fields. The standard defines not just what information a certificate contains, but also how that information is encoded, signed, and validated.
Comprender X.509 es esencial para cualquiera que trabaje con PKI. Explica por qué los certificados tienen el aspecto que tienen, qué significa cada campo y cómo las extensiones añaden flexibilidad a una estructura de otro modo rígida. Este capítulo desglosa el estándar en sus componentes principales para que pueda leer, interpretar y solucionar problemas de certificados con confianza.
Un certificado X.509 es un objeto de datos estructurado codificado usando ASN.1 (Abstract Syntax Notation One). Cada certificado, sin importar su propósito, contiene un conjunto de campos obligatorios que identifican el certificado, su sujeto, su emisor y los parámetros criptográficos utilizados. Aquí están los campos principales definidos por el estándar:
Indica qué versión de X.509 utiliza el certificado. Casi todos los certificados actuales son versión 3 (v3), que introdujo el mecanismo de extensiones que hace posible la PKI moderna.
Un número entero único asignado por la entidad emisora Autoridad de Certificación. La combinación del nombre del emisor y el número de serie debe ser globalmente única. También se utiliza para identificar certificados en listas de revocación.
Especifica el algoritmo criptográfico que la CA utilizó para firmar el certificado (por ejemplo, SHA-256 with RSA o ECDSA with SHA-384). Este campo aparece dos veces: una vez en la porción TBS (to-be-signed) y una vez junto a la firma real.
Un Nombre Distinguido (DN) que identifica la CA que emitió y firmó el certificado. Este campo es crítico para construir la cadena de certificados de vuelta a una raíz de confianza.
Dos marcas de tiempo, notBefore y notAfter, que definen cuándo el certificado se vuelve válido y cuándo expira. Las partes dependientes deben rechazar los certificados fuera de esta ventana.
Un nombre distinguido que identifica la entidad a la que se emitió el certificado. Para un certificado TLS, esto típicamente incluye el nombre de dominio. Para una organización, incluye el nombre de la empresa, el país y la unidad organizativa.
Contiene la clave pública del sujeto y identifica el algoritmo que utiliza (RSA, ECDSA, Ed25519, etc.). Esta es la clave que se usará para el cifrado o la verificación de firmas en los protocolos que dependen del certificado.
Campos opcionales introducidos en la versión 3 que añaden restricciones y metadatos. Las extensiones pueden marcarse crítica (debe ser comprendido por la parte confiada) o no crítica (puede ser ignorado de forma segura si no se reconoce).
Las extensiones son lo que hacen que los certificados X.509 v3 sean tan versátiles. Permiten a las CA expresar restricciones, declarar propósitos y proporcionar información adicional sin cambiar el formato base del certificado. Aquí están las extensiones más importantes que encontrará en la práctica:
Define las operaciones criptográficas que la clave del certificado está permitida ejecutar. Los valores comunes incluyen digitalSignature, keyEncipherment, keyCertSign, y cRLSign. Por ejemplo, un certificado CA necesita keyCertSign para emitir otros certificados, mientras que un certificado de servidor TLS típicamente tiene digitalSignature y keyEncipherment. Esta extensión casi siempre está marcada como crítica.
Proporciona una definición más granular del certificado's propósito. Mientras que el Uso de Clave define operaciones de bajo nivel, EKU se asigna a casos de uso del mundo real: serverAuth para servidores TLS, clientAuth para TLS mutuo, codeSigning para editores de software, y emailProtection para S/MIME. Un certificado con serverAuth no puede usarse para firma de código, incluso si el tipo de clave lo permitiría técnicamente.
Enumera las identidades para las que el certificado es válido, más allá de lo que especifica el campo Subject. Para los certificados TLS, el SAN típicamente contiene nombres DNS (como www.example.com y example.com), pero también puede incluir direcciones IP, direcciones de correo electrónico y URIs. Los navegadores modernos dependen del SAN en lugar del campo Subject CN para la validación de nombres de host, lo que hace que esta extensión sea esencial para cualquier certificado TLS.
Indica si el certificado pertenece a una CA o a una entidad final. Cuando cA: TRUE, el certificado está autorizado a emitir otros certificados. El opcional pathLenConstraint campo limita cuántas CAs intermedias pueden existir bajo esta en la cadena de certificados. Esta extensión es crítica: sin configurarla correctamente, un certificado de entidad final comprometido podría teóricamente usarse para falsificar nuevos certificados.
Especifica URLs donde la parte confiada puede descargar la Lista de Revocación de Certificados (CRL) publicada por la CA emisora. Cuando un cliente necesita comprobar si un certificado ha sido revocado, recupera la CRL de la ubicación indicada en esta extensión y busca el número de serie del certificado's.
Proporciona dos URL importantes: el respondedor OCSP dirección (para la verificación de revocación en tiempo real) y el emisores CA URL (donde se puede descargar el certificado intermedio de CA). AIA es lo que permite a un cliente construir dinámicamente la cadena completa de confianza incluso cuando el servidor solo presenta su propio certificado.
Los mismos datos del certificado X.509 pueden almacenarse y transmitirse en varios formatos de codificación diferentes. Estos formatos determinan cómo se representa en disco o en tránsito los datos binarios del certificado. Comprender las diferencias es esencial al configurar servidores, importar certificados en almacenes de claves o depurar problemas de TLS.
El formato más común en sistemas Linux y Unix. PEM es simplemente datos DER codificados en Base64 y envueltos entre -----BEGIN CERTIFICATE----- y -----END CERTIFICATE----- encabezados. Debido a que usa texto plano, los archivos PEM pueden abrirse en cualquier editor de texto y transmitirse de forma segura por correo electrónico o pegarse en archivos de configuración. Las extensiones de archivo son típicamente .pem, .crt, o .cer.
La codificación binaria cruda de la estructura del certificado ASN.1. Los archivos DER son compactos e inequívocos, lo que los convierte en el formato nativo para muchas aplicaciones Java, almacenes de certificados de Windows y sistemas integrados. Como son binarios, no pueden verse en un editor de texto. Las extensiones de archivo son típicamente .der o .cer.
Un formato contenedor definido en RFC 2315 que puede contener uno o más certificados (y opcionalmente CRL) pero nunca claves privadas. PKCS#7 se usa comúnmente para entregar una cadena completa de certificados desde una CA. Puede codificarse en formato PEM o DER. Las extensiones de archivo son típicamente .p7b o .p7c. Los entornos Windows y Java utilizan frecuentemente este formato para la distribución de la cadena.
Un formato de archivo protegido por contraseña que agrupa el certificado, la cadena completa y la clave privada en un solo archivo. PKCS#12 es la forma estándar de exportar una credencial completa de un sistema e importarla en otro. Se utiliza ampliamente para configuraciones de Windows IIS, almacenes de claves Java (mediante conversión) y migración de certificados. Las extensiones de archivo son típicamente .p12 o .pfx.
El estándar X.509 ha pasado por tres versiones principales. Cada versión añadió capacidades que abordaron limitaciones descubiertas en la práctica.
La especificación original, publicada como parte del estándar de directorio X.500. La versión 1 definió los campos básicos del certificado: número de serie, algoritmo de firma, emisor, validez, sujeto y clave pública. No tenía un mecanismo para extensiones, lo que significaba que no había una forma estándar de expresar restricciones como el uso de clave o nombres alternativos. Los certificados de la versión 1 son esencialmente obsoletos hoy.
Se añadieron dos campos opcionales: el Identificador Único del Emisor y el Identificador Único del Sujeto. Estos fueron diseñados para manejar casos en los que el mismo Nombre Distinguido pudiera reutilizarse con el tiempo (por ejemplo, después de una reorganización de una CA). En la práctica, estos campos se usaban rara vez, y la versión 2 rara vez se encuentra en entornos reales.
La versión actual y dominante. La versión 3 introdujo el marco de extensiones, permitiendo a las CAs adjuntar datos estructurados adicionales a los certificados. Este único cambio hizo posible la PKI moderna: habilitó restricciones de Uso de Clave, Nombres Alternativos de Sujeto, Restricciones Básicas para la distinción CA/entidad final, Puntos de Distribución de CRL, Acceso a Información de Autoridad, y decenas de otras extensiones estándar y personalizadas. Prácticamente todos los certificados emitidos hoy son X.509 v3.
Visibilidad completa de X.509: Evertrust CLM analiza cada campo y extensión de sus certificados, brindándole una vista clara y buscable de los sujetos, SANs, usos de clave, períodos de validez y relaciones de cadena en toda su infraestructura.
Aplicación de políticas en el contenido del certificado: Defina reglas para algoritmos de clave permitidos, tamaños mínimos de clave, extensiones requeridas y convenciones de nomenclatura. Evertrust marca los certificados no conformes antes de que lleguen a producción, garantizando que cada certificado X.509 en su entorno cumpla con los estándares organizacionales.
Gestión independiente del formato: Si sus equipos trabajan con PEM, DER, PKCS#7 o PKCS#12, Evertrust CLM gestiona la importación, conversión y distribución de certificados en cualquier formato de codificación estándar.
Emitir certificados que cumplan con los estándares: Evertrust PKI emite certificados X.509 v3 con extensiones configuradas con precisión, garantizando que su jerarquía de CA, usos de clave y restricciones sigan las mejores prácticas de la industria y sus requisitos de cumplimiento específicos.
