Creación y gestión de cadenas de certificados

Una CA raíz es un certificado autofirmado que actúa como ancla de confianza definitiva. La clave privada de la CA raíz debe mantenerse sin conexión (en un sistema aislado de toda red o en un HSM), porque su compromiso pone en riesgo toda la PKI. "openssl req -x509 -new -nodes -key root_key.pem -sha256 -days 3650 -out root_cert.pem" genera un certificado raíz autofirmado válido durante 10 años.

Las CA intermedias están firmadas por la CA raíz y se utilizan para emitir certificados en el día a día. Primero, genere la clave y la CSR de la CA intermedia: "openssl req -new -key intermediate_key.pem -out intermediate.csr". Después, la CA raíz la firma: "openssl x509 -req -in intermediate.csr -CA root_cert.pem -CAkey root_key.pem -CAcreateserial -days 1825 -out intermediate_cert.pem".

Los certificados de entidad final (certificados hoja) están firmados por la CA intermedia para servidores o clientes específicos. Genere la clave y la CSR del servidor con nombres alternativos del sujeto (SAN) y, después, fírmela con la CA intermedia: "openssl x509 -req -in server.csr -CA intermediate_cert.pem -CAkey intermediate_key.pem -CAcreateserial -extensions v3_req -days 365 -out server_cert.pem".

La clave privada de la CA raíz se mantiene sin conexión y solo se utiliza para firmar un número reducido de certificados de CA intermedias. Las CA intermedias en línea se encargan de la emisión diaria de certificados. Si una CA intermedia se ve comprometida, puede revocarse y sustituirse sin poner en riesgo la raíz. La clave raíz permanece segura porque nunca se expuso en línea.

El comando "openssl ca" proporciona un flujo de trabajo de CA más completo que "openssl x509 -req". Mantiene una base de datos de certificados (index.txt), asigna números de serie a partir de un archivo de serie y gestiona la generación de CRL. Requiere un archivo de configuración openssl.cnf adecuado, con secciones específicas de la CA que definan la política de certificados y las restricciones de longitud de ruta.

Un archivo completo de cadena de certificados para un servidor web contiene el certificado de entidad final seguido, en orden, por los certificados de las CA intermedias, y termina justo antes del certificado raíz. Los certificados raíz no se incluyen porque los navegadores ya tienen almacenes de raíces preinstalados. Orden de concatenación: "cat server_cert.pem intermediate_cert.pem > chain.pem". Un orden incorrecto provoca fallos durante el handshake TLS.

"openssl verify -CAfile root_cert.pem -untrusted intermediate_cert.pem server_cert.pem" verifica la cadena completa. La opción "-untrusted" proporciona los certificados intermedios que forman parte de la cadena, pero que todavía no son de confianza. Si la verificación se realiza correctamente, la salida es "server_cert.pem: OK". Los errores habituales indican que faltan certificados intermedios o que hay certificados expirados.

Entre los problemas frecuentes de las cadenas de certificados se incluyen: certificados intermedios ausentes (el servidor envía únicamente el certificado hoja), orden de concatenación incorrecto (el certificado hoja debe ir primero), un certificado intermedio expirado (fácil de pasar por alto, ya que se monitoriza la expiración del certificado hoja), certificados autofirmados que no están en el almacén de confianza y un desajuste de nombres (el SAN del certificado no coincide con el nombre de host). Todos pueden diagnosticarse con "openssl s_client -showcerts".

PKCS#12 (.pfx o .p12) es un formato de contenedor que agrupa la clave privada, el certificado de entidad final y los certificados intermedios en un único archivo cifrado. Para crearlo: "openssl pkcs12 -export -out bundle.pfx -inkey server_key.pem -in server_cert.pem -certfile intermediate_cert.pem". Es necesario para IIS, .NET, los almacenes de claves de Java y muchas aplicaciones empresariales.

PEM es ASCII codificado en Base64, legible, admite varios objetos en un mismo archivo y lo utilizan Apache, nginx y las herramientas de OpenSSL. DER es binario, contiene un objeto por archivo y lo utilizan Java (para importaciones en JKS), Android y algunas herramientas empresariales. PKCS#12/PFX es un contenedor binario cifrado para varios objetos, utilizado por Windows e IIS. Compruebe el formato que espera el sistema de destino antes de realizar el despliegue.

Las CA modernas deben registrar todos los certificados emitidos en registros de Transparencia de certificados (CT) antes de entregarlos. Al crear una CA privada para uso interno, no se exige el registro en CT. Sin embargo, los certificados públicos deben incluir marcas de tiempo de certificados firmados (SCT) para que Chrome confíe en ellos. Las CA privadas pueden aplicar sus propias políticas sin requisitos de CT.

Al montar un archivo de cadena de certificados TLS para un servidor nginx, ¿cuál es el orden correcto de concatenación?

Las CA raíz son autofirmadas, se mantienen sin conexión y solo firman certificados de CA intermedias. Las CA intermedias se encargan de la emisión diaria. Los archivos de cadena contienen primero el certificado hoja y después los certificados intermedios; se omite la raíz. Verifique con "openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem". Los contenedores PKCS#12 agrupan la clave y los certificados para Windows y Java. Un orden incorrecto de la cadena es una causa frecuente de fallos de despliegue que puede diagnosticarse con s_client -showcerts.