Añadir una CA privada al almacén de confianza del sistema en la familia RHEL y en Debian/Ubuntu

Objetivo

Hacer que un certificado de CA privada o interna sea de confianza en todo el sistema para OpenSSL, curl y otras bibliotecas que leen el almacén de confianza del sistema operativo, tanto en Linux de la familia RHEL como de la familia Debian.

Requisitos previos

Privilegios de root; el certificado de la CA en formato PEM (los anchors de la familia RHEL también aceptan DER); el paquete ca-certificates instalado (Debian/Ubuntu) o el paquete ca-certificates que proporciona update-ca-trust (RHEL, Fedora y derivadas como Rocky/Alma, RHEL 7 y posteriores).

Pasos

Familia RHEL:

1. Copia el certificado de la CA (PEM o DER; aquí el nombre y la extensión del archivo no importan) en /etc/pki/ca-trust/source/anchors/. No lo coloques en el directorio superior /etc/pki/ca-trust/source/: los certificados simples que se dejan ahí se tratan como no confiables.
2. Ejecuta update-ca-trust extract como root (update-ca-trust sin argumentos hace lo mismo). Lee el directorio de anchors junto con los valores predeterminados del proveedor y regenera los archivos consolidados en /etc/pki/ca-trust/extracted/ (bundles PEM, un keystore de Java); las aplicaciones basadas en NSS leen las mismas fuentes a través del módulo p11-kit-trust.
3. Sin interacción: el comando no pide ninguna confirmación, así que se puede usar sin riesgo en scripts de aprovisionamiento desatendidos.

Debian/Ubuntu:

1. Copia el certificado de la CA en /usr/local/share/ca-certificates/ (se permiten subdirectorios); el archivo debe terminar en .crt y debe estar en formato PEM (BEGIN CERTIFICATE): update-ca-certificates solo recoge allí los archivos .crt, y un archivo DER renombrado a .crt no se convierte en una entrada utilizable del bundle; conviértelo antes con openssl x509 -inform der.
2. Ejecuta update-ca-certificates como root. Actualiza los enlaces hash en /etc/ssl/certs, regenera /etc/ssl/certs/ca-certificates.crt y, a continuación, ejecuta los hooks de /etc/ca-certificates/update.d/.
3. En instalaciones desatendidas, DEBIAN_FRONTEND=noninteractive no tiene efecto aquí, ya que la propia herramienta no es interactiva; solo es relevante para el paso previo apt-get install ca-certificates, si el paquete no está instalado.

Resultado esperado

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt mycert.pem (Debian) o openssl verify -CAfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem mycert.pem (familia RHEL; las versiones antiguas también lo exponen en la ruta heredada /etc/pki/tls/certs/ca-bundle.crt) devuelve OK para un certificado cuya cadena termina en la nueva CA. En la familia RHEL, trust list | grep -i "<CA common name>" (p11-kit) confirma que el anchor se ha registrado; en Debian/Ubuntu el comando trust solo existe si está instalado el paquete p11-kit.

Límites y base de verificación

Un archivo .pem colocado en el directorio equivocado, o un archivo de Debian sin la extensión .crt, es ignorado en silencio por ambas herramientas: no hay ningún error, solo una cadena que sigue sin verificarse. El OpenJDK empaquetado por la distribución suele leer un keystore generado a partir de este mismo almacén (/etc/pki/java/cacerts en la familia RHEL; /etc/ssl/certs/java/cacerts mediante el hook de ca-certificates-java en Debian/Ubuntu), pero un JDK de un proveedor descomprimido desde un tarball y un certifi instalado con pip mantienen almacenes propios. Los procesos que ya cargaron el bundle conservan el conjunto anterior hasta que se reinicien. Para eliminar una CA, borra el archivo del directorio de anchors o de /usr/local/share/ca-certificates y vuelve a ejecutar el mismo comando (en Debian, update-ca-certificates --fresh reconstruye los enlaces desde cero si queda alguno obsoleto).