Si tienes un sólido entendimiento de lo que es un certificado X509, por favor levanta la mano. Ahora que reconocemos que nadie está levantando la mano, cambiemos eso.
Los certificados son un tema complejo y a menudo mal comprendido. Este tutorial tiene como objetivo cambiar eso mostrándote ejemplos de certificados X509, demostrando certificados de PKI y mucho más.
En este artículo, obtendrás una buena visión general de los certificados X509. Al final, comprenderás cómo funcionan a un nivel alto. No te convertirás en un experto con un solo artículo, pero al menos al final de este artículo, estarás familiarizado con la terminología adecuada.
Relacionado: Administrando Certificados con el Administrador de Certificados de Windows y PowerShell
Claves Públicas y Privadas: Protegiendo Activos
Cualquier información que explique certificados X509 estaría incompleta sin mencionar primero las claves. Puede que hayas oído hablar del concepto de claves cuando se mencionan términos como privadas y públicas. Pero, ¿qué es exactamente una clave y cómo se relaciona con los certificados?
Para facilitar la conexión, expliquemos el concepto de claves en términos de una cerradura de puerta bien antigua.
Cuando compras una nueva cerradura de puerta, esa cerradura vendrá con una llave. Esa llave es única para esa cerradura, de modo que nadie más podrá abrirla.
Piensa en la cerradura misma como una llave pública. Cuando se instala, tú, tu familia o los transeúntes pueden ver la cerradura en tu puerta. Cualquiera puede verla e incluso intentar desbloquearla, pero no tendrán éxito. Para desbloquearla, necesitarían insertar la llave única de la puerta que originalmente vino con la cerradura. La llave única que vino con la cerradura es la llave privada.
La llave privada y la llave pública juntas se denominan un par de claves.
Intercambio de Claves
Cuando se inserta la llave de la puerta en la cerradura, puedes pensar en esa acción como un intercambio de claves. La llave privada (llave de la puerta) necesita ser intercambiada con la llave pública (cerradura) para desbloquear la puerta.
En el mundo de la criptografía, darás libremente una llave pública y guardarás la llave privada para ti mismo. Después de todo, no te importa quién ve la cerradura, pero definitivamente te importa quién puede desbloquearla (intercambiar claves).
Existen algunas formas diferentes en que se intercambian las claves, llamadas algoritmos de intercambio de claves. Los algoritmos de intercambio de claves se centran en derivar y transmitir de forma segura un secreto compartido único.
Dos algoritmos de intercambio de claves populares que tal vez hayas escuchado son Diffie-Hellman (DH) y Elliptic Curve Diffie-Hellman (ECDH).
Confianza en la Clave
Si necesitas que alguien entre por la puerta, les darías la llave (o una copia de la original, única). Solo le das tu llave a aquellos en quienes confías. La persona que tiene la llave privada (llave de la puerta) ha sido confiada para desbloquear la cerradura de la puerta (llave pública).
Uso de la Clave
El uso de clave define el propósito del certificado X509, esto se alinea con los algoritmos que el certificado utilizará. El uso extendido de clave (EKU) define los propósitos previstos para la clave pública más allá del uso de clave.
Certificados X509: “Contenedores” de Clave Pública
¿Cómo se relacionan las claves privadas y públicas con el concepto de un certificado X509? Piensa en un certificado como simplemente una clave pública. Un certificado es el “encerramiento” que contiene una clave pública junto con otra información sobre la clave, como a quién se emitió la clave pública, quién firmó la clave, entre otros. Los certificados se almacenan en forma de archivos.
Más adelante veremos algunos ejemplos de buenos certificados X509.
¿Alguna vez has visto un archivo con una extensión de archivo de certificado PEM o CER? Esos son certificados (claves públicas). Aprenderás más sobre estos formatos un poco más adelante.
La clave pública por sí sola no es necesariamente un certificado por definición. Es la clave pública y los datos de atributo asociados combinados los que definen un certificado.
A certificate provides a standardized and secure format to communicate with specific systems along with the attributes to help validate a key pair trust. How certificates are built are defined within the X.509 standards, as you will read about later.
Huella digital: Identificador único de un certificado
Cada certificado X509 tiene la intención de proporcionar la identificación de un único sujeto. El certificado debe garantizar que cada clave pública sea identificable de manera única.
A certificate thumbprint or fingerprint is a way to identify a certificate, that is shorter than the entire public key. Technically, a serial number is as well but you’ll learn about that when it comes to certification authorities (CAs). The thumbprint is a hash of a DER-encoded certificate in Windows.
El concepto de identificar un conjunto de datos más grande mediante un identificador único más pequeño es el tema general de la informática conocido como “fingerprinting”. El blog de Morgan Simonson profundiza en la huella digital.
Asunto: Definición de Atributos Importantes en Certificados X509
Cada certificado X509 debe tener no solo un identificador único, sino también responder preguntas como las siguientes. El sujeto del certificado debería hacer precisamente eso.
- ¿Quién debería usar este certificado?
- ¿En qué organización se debe confiar?
- ¿Qué usuario debería presentar este certificado?
El sujeto es, sin duda, la parte más importante de un certificado. El sujeto está destinado a tener atributos, definidos por X.500, que representan a quién o qué se emite el certificado. Se representa en un formato de nombre distinguido (DN).
A certificate subject is a string value that has a corresponding attribute type. For example, the DN for State or Province is st. This attribute type contains the full name of the state or province the subject resides in (e.g. ST=California).
Estos tipos de atributos y formatos de valor están definidos por las recomendaciones ITU-T X.520. Una referencia adicional es RFC 4519 para recomendaciones específicas de tipos de atributos y formatos de valor.
Dado que los estándares de certificados X509 no son reglas, solo sugerencias sólidas, muchas personas utilizan su propio juicio al definir un sujeto. Se supone que el sujeto debe identificar específicamente la entidad final en la que confía. Si el sujeto no representa esto, ¿cómo puedes confiar en cualquier cosa que utilice la clave pública presentada?
En otras palabras, si permites que varias personas usen el mismo nombre de usuario para acceder a un sistema, no puedes responsabilizar a una persona específica por sus acciones. Esta práctica complica el modelo de confianza con el que se supone que los certificados deben alinearse.
Puedes ver un ejemplo de cómo Windows representa un certificado X509 y más específicamente el sujeto del certificado en la captura de pantalla a continuación.
Visualización de los atributos de un certificado con Cryptext.dll.
Nombre alternativo del sujeto (SAN)
A SAN is a certificate extension that allows you to use one certificate for multiple subjects that’s typically identified with a Subject Key Identifier (SKI). The example below shows some of the SANs Google uses. Adding more domains to a certificate essentially tells the certificate to trust each subject to use the same private key.
A SAN can also have several types other than DNS names called GeneralNames. GeneralNames require the client reading the certificate to support SANs using GeneralNames. Most clients such as web browsers only focus on the DNS name SAN.
Puedes ver el SAN a continuación en este ejemplo de certificado X509.
Algunos de los atributos de SAN asociados con el certificado de Google.
Comprensión de la codificación
Utilizamos muchos idiomas para comunicarnos entre nosotros, de manera similar, las computadoras tienen su propio lenguaje. Este lenguaje es binario y los diferentes métodos de codificación son la forma en que hacemos que el binario sea más utilizable para otros, así como traduciríamos el inglés a otros idiomas.
La codificación sirve a un propósito específico. Permite que los valores de extensión legibles por humanos se almacenen de manera que las computadoras también puedan usarlos. Los formatos de codificación facilitan el almacenamiento y la transferencia de certificados X509, pero también nos permiten leer sus contenidos.
Las computadoras son buenas para trabajar con enteros, la codificación te permite convertir valores numéricos en valores alfanuméricos o incluso bloques binarios. Esta conversión es fundamental para trabajar con computadoras, y los certificados dependen de la codificación para transmitir correctamente la información adecuada a las computadoras. Los formatos de codificación definen los estándares para realizar esas conversiones.
- ASN.1 – El estándar de Notación de Sintaxis Abstracta es el formato de serialización para cada uno de los campos dentro de los certificados.
- ASCII – El Código Estándar Americano para el Intercambio de Información (ASCII) define un valor binario para cada uno de los caracteres de control de computadora y caracteres imprimibles utilizados en la mayoría de las comunicaciones legibles por humanos.
- Base64 – Base64 define un esquema para codificar contenido binario dentro del conjunto de caracteres ASCII. Estos son los certificados que puedes abrir en un editor de texto y ver “BEGIN CERTIFICATE” u otro texto de referencia.
- DER – Reglas de Codificación Distinguidas (DER) define otro esquema de codificación específicamente para datos ASN.1 como octetos secuenciales. La consideración importante con DER es que la salida codificada no es visible como ASCII.
A continuación, puedes ver la diferencia en los esquemas de codificación. Observa que el archivo certificate.crt mostrado primero tiene un ——-BEGIN CERTIFICATE——-, seguido de una serie de letras y números aleatorios, y termina con ——-END CERTIFICATE——-. Todos los caracteres son legibles por humanos. El primer certificado está codificado en Base64.
Ahora echa un vistazo al segundo ejemplo del archivo certificate.cer. El contenido de este archivo se ve muy diferente al certificado Base64. Este certificado X509 está codificado en DER.
Diferencia entre archivos codificados en Base64 y DER.
Entendiendo los Tipos de Archivos de Certificados X509
Recuerda que un certificado no es más que una clave pública con algunos metadatos representados como un archivo. Encontrarás muchos tipos diferentes de archivos que representan diversos certificados. Cada tipo de archivo se diferencia por su extensión. Cuando nos referimos a un archivo KEY, por ejemplo, nos referimos a su extensión de archivo.
A continuación, encontrarás todos los tipos comunes de certificados definidos por su extensión de archivo con los que podrías trabajar y su propósito.
En la lista a continuación, notarás varias referencias a PKCS. PKCS o Public Key Cryptography Standards es un conjunto de normas para definir cómo se crean varios certificados. Para obtener más información, consulta este informativo artículo de Wikipedia.
- PFX – Estos se encuentran comúnmente en un entorno Windows, pero son un formato estándar independientemente del sistema operativo. Los archivos PFX contienen un certificado, la clave pública y extensiones, y una clave privada cifrada con una contraseña. PFX está definido por el estándar PKCS #12.
- P12 – Al igual que PFX, P12 está definido por el estándar PKCS #12. Formalmente, PKCS #12 es el sucesor del formato PFX, aunque ambos tipos de archivos representan el mismo formato en implementaciones criptográficas modernas.
- P7B – Un contenedor de certificados ASN.1, específicamente claves públicas para todos los niveles de una cadena de autoridad de certificación, como aprenderás a continuación. Un archivo PKCS #7 proporciona un solo archivo para distribuir múltiples claves públicas, a menudo utilizado para configurar manualmente la confianza con CAs en una PKI privada.
- P7C – El tipo de archivo P7C es funcionalmente igual que el P7B, pero simplemente es otra extensión común utilizada para representar un archivo PKCS #7.
- DER – Un archivo DER es una clave pública codificada en DER.
- CER – Una clave pública está codificada en DER o Base64. Un archivo CER es generalmente codificado en DER.
- CRT – Un CRT está generalmente codificado en Base64, pero no hay garantías.
- KEY – Un archivo KEY a menudo es una clave privada codificada en Base64, ya sea encriptada o no.
- PEM – Una referencia a un certificado codificado en Base64, aunque múltiples claves pueden estar en un solo archivo PEM, a menudo se asume que el archivo PEM tiene una clave privada. Más comúnmente usado para un archivo de clave privada PEM codificado en Base64, ya sea encriptado o no encriptado.
- CSR – Utilizado para enviar una clave pública a una CA para ser firmada y emitir campos adicionales como un número de serie, y está definido por PKCS #10. En la mayoría de los casos, un CSR contendrá la estructura ASN.1 para la solicitud en codificación Base64.
- REQ – Utilizado en Windows para especificar la configuración de política de inscripción utilizada al generar el CSR.
- CRL – Una CRL es un archivo específico que enumera los certificados revocados por una CA, su estado de revocación y la razón por la que fueron revocados.
Infraestructura de Clave Pública (PKI): El Ecosistema de Certificados X509
Recuerda cuando alguien tenía la llave de la puerta de un cerrojo. En ese momento, solo tenías una puerta. Pero ¿qué pasa cuando de repente te encuentras como propietario de docenas o cientos de apartamentos? ¡Gestionar todas esas llaves de puerta se va a poner feo!
Además, los inquilinos no se quedarán en ese apartamento para siempre. Habrá personas que conserven la llave o hagan copias no autorizadas. Tendrás que cambiar las cerraduras de las puertas para evitar el acceso. Ya no confías en los antiguos inquilinos.
Si tienes que gestionar cientos de apartamentos con inquilinos que entran y salen constantemente, ¿cómo gestionas todo eso? La respuesta es una Infraestructura de Clave Pública (PKI, por sus siglas en inglés).
PKI es todo un ecosistema de roles, políticas y procedimientos construidos en torno a la gestión de claves públicas. PKI representa un conjunto completo de muchas áreas diferentes de enfoque para distribuir, usar, gestionar y eliminar certificados X509. Esencialmente, es todo lo que se necesita para manejar y gestionar certificados correctamente a gran escala.
En las secciones siguientes, desglosaremos muchos de los componentes más comunes de una PKI y explicaremos el papel que desempeña cada componente.
Autoridades de Certificación (CAs, por sus siglas en inglés): Tus Padres
A PKI is primarily built around the concept of managing trust. But since it’s not economical to directly manage hundreds or thousands of trust relationships, you need a mediator.
Necesitas un tercero que ya haya sido avalado por la parte original. Estos mediadores de terceros se llaman autoridades de certificación (CAs) identificados por una extensión de Identificadores de Clave de Autoridad (AKI, por sus siglas en inglés) derivada de la clave pública utilizada para firmar el certificado dado.
Pensando en ti como un certificado X509. Probablemente te enseñaron tus padres a no confiar en desconocidos. Pero, ¿qué pasa si tus padres (a quienes confías) te presentan a un desconocido y te dicen que está bien confiar en él? Probablemente lo aceptarías y confiarías en el desconocido. Después de todo, si tus padres confían en él, tú también puedes hacerlo.
A CA plays the role of your parents. You trust your parents (a CA) and they introduce you to strangers. They do so by signing the stranger’s public key to let you know that you can trust them.
El papel principal de una Autoridad de Certificación (CA, por sus siglas en inglés) es actuar como un mediador de confianza.
Emisión de Certificados X509: Estableciendo Confianza
Siendo una entidad conocida y de confianza, una CA permite la confianza entre partes indirectas. Para habilitar la confianza entre partes, una CA “emite” certificados. Cuando hablamos de que una CA emite, realmente queremos decir que la CA está validando las extensiones solicitadas y añadiendo extensiones generadas por la CA para crear un certificado.
Cuando una CA emite un certificado X509, utiliza su propia clave privada para firmar digitalmente la clave pública del certificado. A través del proceso de firma, la CA está marcando el certificado de manera que informa a todos que confía en esta clave pública. DocuSign proporciona una buena descripción general de este concepto específico con un buen diagrama.
Otro ejemplo de una extensión generada por una CA es el número de serie de cada certificado, y cada número de serie debe ser único para esa CA según las especificaciones de diseño de RFC.
Un ejemplo de confianza no deseada en las noticias modernas es el uso malicioso de PKIs con malware. Donde los creadores recibieron certificados válidos que son implícitamente confiados por la mayoría de los sistemas, lo que dificulta que sus sistemas identifiquen los binarios de malware como maliciosos.
Revocación de certificados X509: Eliminación de confianza
La Autoridad de Certificación también es responsable de revocar los certificados X509 que ya no deben ser confiados. Estas revocaciones son publicadas por la AC en una Lista de Revocación de Certificados (CRL). La revocación es una forma para las AC de invalidar activamente un certificado, en lugar de esperar a que expire la duración de validez.
La confianza es un componente crítico para que los certificados funcionen de la manera en que están diseñados. Los puntos de distribución ayudan a garantizar la confianza al proporcionar un punto de referencia desde donde el certificado y las listas de revocación pueden ser descargadas desde el emisor y comparadas con el certificado que está utilizando.
A CRL Distribution Point (CDP) supplies the protocols and locations to obtain CRLs. Updating CRLs is a passive revocation validation method, with pulling updates at scheduled intervals. Online Certificate Status Protocol (OCSP) actively requests the revocation status of a specific certificate by maintaining caches of the CRLs.
Aunque la validación de revocación a través de CRL u OCSP está disponible, se implementa según las necesidades del cliente y no siempre es el caso.
Jerarquización
A PKI can be made up of multiple CAs or a single CA, these are commonly referred to as tiers.
Cadena de Certificados X509
Como aprendiste anteriormente, la confianza es un punto focal importante al usar certificados. Las partes involucradas deben poder confiar o validar un certificado emitido por una AC confiable.
A great example of how this scales is the The United States Federal PKI public documents. These provide a great reference into maintaining an inter-organization trust relationship using CAs.
Firma de Certificados X509
A menudo escucharás hablar de un concepto llamado certificado de firmado, pero ¿qué significa exactamente? Como ya has aprendido, los certificados se tratan de confianza. Para establecerla, un certificado X509 es firmado por una AC. Firmar un certificado asigna un hash criptográfico único al certificado, indicando a todas las partes que lo lean que pueden confiar en él. Fue firmado por una AC de confianza.
En una jerarquía de IPK, los certificados son firmados por AC, pero dónde se utilizan depende del tipo de AC que los firma.
Cuando hay una sola AC en una IPK, esa AC es la raíz. Dado que no existe otra AC, esa AC debe generar su propio certificado auto-firmado. Luego, esa AC emite certificados firmados por su propio certificado.
Si una IPK tiene más de una AC, todas las AC son firmadas por una AC raíz o una AC intermedia que se conecta a la AC raíz.
Normalmente, cuando un dispositivo utiliza la misma clave privada que corresponde a la clave pública al generar un certificado X509, se conoce como un certificado auto-firmado. Sin embargo, también puedes solicitar a una AC que utilice su propia clave privada para firmar tu certificado.
Algoritmos de Firma
Los algoritmos de firma se centran en validar la autenticidad de un mensaje de un par remoto. Una firma digital es un resumen de un mensaje de una función de hash encriptada con la clave privada del remitente. El destinatario desencripta la firma digital utilizando una copia de la clave pública del remitente. Luego, el destinatario puede comparar el resumen del mensaje recibido con el que se desencriptó de la firma digital. Cuando los resúmenes coinciden, la autenticidad del mensaje es válida.
Cifrado asimétrico es la capacidad de generar texto cifrado sin el uso de un secreto previamente conocido. La combinación de un algoritmo de intercambio de claves con un algoritmo de firma es la base del cifrado asimétrico.
A continuación se presentan los algoritmos principales utilizados para firmas digitales.
- Rivest–Shamir–Adleman (RSA)
- Algoritmo de Firma Digital (DSA)
- DSA de Curva Elíptica (ECDSA)
Solicitudes de Firma de Certificados (CSRs)
Las Autoridades Certificadoras utilizan Solicitudes de Firma de Certificados (CSR) que permiten a los clientes enviar claves públicas a las AC para su emisión. Una AC acepta un CSR y emitirá certificados X509 firmados basados en las políticas de emisión configuradas. Esto significa que cada AC en la que confías también implica confianza en las claves públicas que firma.
Hashing
El hashing es un tema complejo, y ni siquiera intentaré abordarlo completamente en esta publicación. El equipo de Computerphile tiene una buena descripción general en su canal de YouTube. El hashing se centra en tomar un objeto de entrada y crear un hash de salida único para esa entrada única. El hash de salida se conoce como digest. Cambiar el objeto de entrada de la manera más mínima creará un digest único e no relacionado.
Las implementaciones modernas se centrarán en los algoritmos de la familia del Algoritmo de Hash Seguro (SHA) 2. Como nota, SHA 256, SHA 384 y SHA 512 se conocen como SHA 2.
A continuación se muestra una lista de algoritmos de hashing comunes que verás.
- SHA 256
- SHA 384
- SHA 512
- Resumen de Mensajes (MD) 5
Políticas de Certificado
La extensión de la política de certificados (CP) proporciona la referencia a la organización que mantiene la AC, documentando sus políticas reales para el PKI dado y debería estar alineada como una Declaración de Prácticas de Certificación (CPS) que proporciona la política de la organización para mantener el PKI dado.
Puntos de Distribución
Otro tipo de punto de distribución identificado dentro de los certificados son los Accesos de Información de Autoridad (AIA). Estos AIA suministran los protocolos y ubicaciones para obtener copias de la información de los emisores de certificados, lo más comúnmente significa la clave pública de la CA emisora.
Resumen
Con suerte, ahora, cuando se le haga una pregunta como al inicio de este artículo, se sentirá más cómodo levantando la mano, lentamente. Sin embargo, en toda honestidad, con suerte, este artículo le haya ayudado a ver las complejidades con los certificados X509, y en la implementación de estos estándares en Windows. Ayudándole a comprender algunos de los componentes básicos que le ayudarán en el futuro al trabajar con certificados.
Al menos ahora, cuando alguien pida una clave pública de su certificado, puede confirmar que quieren codificación DER o Base64, y ellos no lo sabrán, así que aún les enviará ambas de todos modos.