Gestión de certificados e infraestructura de claves públicas en Oracle Linux

Explica cómo los pares de claves asimétricas, las autoridades de certificación y las sesiones TLS protegen las comunicaciones.

La criptografía de clave pública es una técnica de cifrado que se utiliza para permitir comunicaciones seguras en una red pública insegura y también para verificar la identidad de la entidad en el otro extremo de una conexión de red. La criptografía de clave pública funciona mediante el establecimiento de un par asimétrico de claves. Los datos cifrados por una clave se descifran mediante la otra clave. Una clave se mantiene como privada y la otra se convierte en pública. Alguien que descifra los datos mediante la clave pública puede estar seguro de que los datos fueron cifrados por alguien que tiene acceso a la clave privada. Del mismo modo, alguien que cifra datos mediante la clave pública puede estar seguro de que los datos solo pueden ser descifrados por alguien que tenga acceso a la clave privada.

Ninguna de las claves por sí sola puede establecer la identidad del remitente de los datos. Para ello, normalmente se firma una clave pública para demostrar que pertenece al propietario de la clave privada correspondiente. Este proceso de firma es realizado por un tercero de confianza, a menudo llamado Autoridad de Certificación (CA). El creador de un par de claves pública-privada envía la clave pública, junto con la información de identificación relevante, a la CA en forma de solicitud de firma de certificado. La CA utiliza su propia clave privada para firmar un certificado digital, que contiene una versión codificada de la clave pública del sujeto, información sobre el sujeto y el emisor, el período de validez y detalles sobre los algoritmos criptográficos en uso. Este certificado puede hacerse público o proporcionarse a cualquier parte que necesite verificar la asociación entre el sujeto y la clave pública.

Los clientes que confían en la CA también pueden confiar en la clave pública almacenada en el certificado. Al verificar la firma del certificado con el certificado de CA, se obtiene la clave pública que se puede utilizar para crear un canal de comunicación seguro que mantenga la confidencialidad de los datos y que se puede utilizar para establecer la identidad del originador de los datos que se mueven por el canal.

Para Internet, existen muchas CA de nivel superior o root públicas y CA intermediarias en las que una CA raíz confía para emitir certificados en nombre de entidades. Una autoridad de certificación intermediaria devuelve una cadena de certificados, en la que cada certificado de la cadena autentica la clave pública del firmante del certificado anterior en la cadena hasta una autoridad de certificación raíz incluida.

Los certificados de CA solo se utilizan para establecer la identidad de una clave pública y el período durante el cual la clave pública se considera válida. Cuando caduca el certificado, los datos cifrados mediante la clave pública se pueden descifrar mediante la clave privada. Esto significa que la clave privada debe mantenerse segura para que las comunicaciones siempre se consideren seguras. También existe un mecanismo dentro de la criptografía de clave pública que se puede utilizar para ayudar a mitigar los compromisos de clave privada. Este mecanismo se conoce como Perfect Forward Secrecy (PFS) y utiliza un algoritmo de intercambio de claves para acordar de forma segura una clave de sesión aleatoria y desechable que se puede utilizar con un cifrado simétrico para cifrar datos. La ventaja de este enfoque es que si la clave de sesión se ve comprometida, solo se exponen las comunicaciones en esa sesión de comunicación en particular. Igualmente, si la clave privada se ve comprometida, todas las sesiones de comunicación reales tampoco se exponen automáticamente.

Otra ventaja adicional de PFS es que simplifica el proceso computacionalmente costoso y lento de descifrar y validar cada pieza de información utilizando el par de claves asimétricas y el certificado de CA. En realidad, el proceso de descifrar la clave pública y validarla con el certificado de CA y, a continuación, utilizarla para descifrar datos dentro de una sesión de comunicación solo se realiza al principio de la sesión, hasta que se establece PFS. El algoritmo para crear y compartir la clave de sesión aleatoria suele ser el intercambio de claves Diffie-Hellman. A continuación, la clave de sesión utiliza un cifrado simétrico para realizar un cifrado y un descifrado de datos más rápidos durante el resto de la sesión. El cifrado más utilizado para este propósito es AES, que puede aprovechar el hardware para hacer que el cifrado y la comunicación en texto cifrado sean casi tan rápidos como la comunicación con texto sin formato.

El manejo del canal de comunicación y la negociación donde el cliente y el servidor cambian de criptografía asimétrica a simétrica se logran utilizando los protocolos criptográficos de seguridad de capa de transporte (TLS) o capa de conexión segura (SSL).

OpenSSL, GnuTLS y Network Security Services (NSS) proporcionan implementaciones de código abierto de los protocolos TLS y SSL. También puede utilizar el comando keytool proporcionado con el paquete OpenJDK para gestionar los almacenes de claves Java, que suelen utilizar las aplicaciones basadas en Java. Si una jerarquía de confianza se limita a la intranet de la organización, puede utilizar estas implantaciones para generar un certificado raíz y configurar una CA para ese dominio. Sin embargo, a menos que instale este certificado raíz autofirmado en cada sistema de la organización, los exploradores, la autenticación LDAP o IPA y otro software que utilice certificados, se le pedirá al usuario información sobre la posible relación de confianza.

Normalmente, los certificados TLS/SSL caducan después de un año. Otros certificados, incluidos los certificados raíz que se distribuyen con navegadores web y que son emitidos por CA raíz e intermediaria, caducan después de un período de cinco a 10 años. Para evitar que las aplicaciones muestren advertencias sobre certificados desactualizados, planifique reemplazar los certificados TLS/SSL antes de que caduquen. Para los certificados raíz, normalmente debe actualizar el software antes de que caduque el certificado.

Si solicita un certificado firmado de una CA para la que aún no existe en el sistema un certificado raíz o una cadena de certificados que autentique la clave pública de la CA, obtenga un certificado raíz de confianza de la CA. Para evitar un posible ataque "man-in-the-middle", verifique la autenticidad del certificado raíz antes de importarlo. Compruebe que la huella del certificado coincida con la huella que publica la CA.

Acerca de SSL y TLS

Tanto Secure Sockets Layer (SSL) como Transport Layer Security (TLS) son protocolos de comunicación que garantizan conexiones e intercambios seguros entre los sistemas cliente y servidor. Ambos protocolos proporcionan cifrado y autenticación para proteger las comunicaciones de red. Sin embargo, SSL es una tecnología más antigua y ha sido reemplazada por TLS. La criptografía utilizada por TLS es más compleja, avanzada, robusta y segura. La autenticación con TLS es más rápida y se mejoran los mensajes de alerta.

A pesar de este cambio en el protocolo subyacente, el proyecto OpenSSL conserva su nombre y la terminología SSL se utiliza a menudo indistintamente para describir la funcionalidad de TLS. En el contexto de las comunicaciones seguras, SSL ahora se entiende como referencia al protocolo TLS y los certificados TLS. Cualquier referencia a SSL en esta documentación debe entenderse en el contexto de TLS.

Describe cómo ACME automatiza la validación de dominios y la emisión de certificados para los servicios TLS.

El entorno de gestión automática de certificados (ACME) es un protocolo y una estructura que publica IETF en RFC 8555 y que se puede utilizar para la firma y creación de certificados en los que se requiere validación de dominio.

El protocolo utiliza mensajes con formato JSON a través de HTTPS con una CA para manejar la validación de la propiedad del dominio automáticamente haciendo que el cliente ACME realice una acción que solo se puede realizar con el control del nombre de dominio. Por ejemplo, la CA puede solicitar el aprovisionamiento de un registro DNS o puede solicitar que un recurso HTTP específico esté disponible en un servidor web con el nombre de dominio.

Una vez que la autoridad de certificación valida que la entidad que solicita un certificado tiene la propiedad del dominio, la autoridad de certificación puede firmar el certificado que le envía el cliente ACME. Normalmente, el cliente puede instalar automáticamente el certificado en una ubicación que los servicios que se ejecutan en el sistema pueden utilizar.

ACME reduce el costo y la complejidad asociados con la gestión de la infraestructura de clave pública. En ocasiones, la obtención de certificados firmados para sistemas dentro de dominios puede ser gratuita, según la selección de CA. Por ejemplo, Vamos a Cifrar, el originador del protocolo ACME, proporciona un servicio de CA abierto y gratuito. Otras CA comerciales también están empezando a ofrecer certificados basados en ACME gratuitos.

Mientras que la primera versión del protocolo ACME se puede utilizar para crear solo certificados de dominio único, ACME v2 se puede utilizar para la creación y firma de certificados con dominios comodín, como *.example.com. Por lo tanto, puede utilizar un único certificado en todos los subdominios. ACME solo valida los dominios. Si necesita certificados que requieran más validaciones, es posible que necesite certificados firmados de una CA establecida que ofrezca servicios más allá de ACME.

Si necesita crear y emitir certificados en una infraestructura para utilizar servicios protegidos por TLS/SSL, considere el uso de una CA que funcione con ACME y el uso de un cliente ACME. ACME puede generar automáticamente los pares de claves y la CSR, enviar la CSR a una CA para su validación, realizar cualquier paso de validación para la CA, obtener el certificado firmado y almacenarlo en algún lugar al que puedan acceder los servicios y las aplicaciones. Muchos clientes definen automáticamente tareas cron periódicas para comprobar la caducidad del certificado y solicitar automáticamente un nuevo certificado antes de que caduque el certificado actual.