Integrando FreeIPA como Sub-CA en mi PKI
Hoy tuve un problemón bien gacho en el lab intentando que los certificados de FreeIPA se llevaran chido con el resto de mi infraestructura. FreeIPA es un sistema de identidad bien chingón, la neta, pero de fábrica viene muy chiquión: se monta su propia Autoridad Certificadora (CA) autofirmada y se la pasa generando alertas de "certificado no confiable" a menos que andes copiando su maldito certificado raíz en cada pinche máquina cliente. ¡Qué hueva, compa!
Por suerte, encontré una forma muy suave de arreglar este desmadre: integrar FreeIPA como una Sub-CA subordinada de mi propia PKI de EVALinux. Así, cualquier certificado que emita FreeIPA ya viene con la bendición de mi CA Raíz y todos los clientes confían en él automáticamente. ¿A poco no está chido, no?!
Mi Arquitectura PKI
Mi PKI en EVALinux sigue una jerarquía clásica de dos niveles para mantener la seguridad bien cabrona sin perder flexibilidad operativa:
- La CA Raíz (Nivel 1):
- Ubicada en root/. Es una CA que mantengo estrictamente offline, bien resguardada, y que nomás sirve para firmar a las CAs subordinadas. Jamás emite certificados para servidores o usuarios finales directamente. ¡Seguridad primero, compa!
- CAs Subordinadas (Nivel 2):
- Ubicadas en clients/. Estas son las que se fletan el jale diario. Cada cliente o entorno (como evalinux o g02) tiene su propia CA subordinada aislada, con su propia base de datos y lista de revocación (CRL).
Cómo Administro esta Onda
Para no andar batallando, tengo todo automatizado con un GNUmakefile global que es la pura sabrosura.
- Creando una nueva Sub-CA:
Si me llega un cliente nuevo (digamos, acme), nomás corro un comando para crearlo:
# Creación de la CA subordinada para el cliente acme make new-client client=acme
Este comando automatiza todo el jale: crea el directorio clients/acme/, genera la configuración de OpenSSL con plantillas y firma el certificado de la Sub-CA usando mi CA Raíz de EVALinux.
- Emitiendo Certificados Finales:
Ya que la CA del cliente está lista, me meto a su directorio para emitir certificados para servidores u otros dispositivos:
# Generación de un certificado de host en clients/acme cd clients/acme make cert host=web01.acme.com
La automatización se encarga de meter los nombres alternativos (SAN) correctos y, para evitar broncas con fierros viejos, convierte las llaves privadas al formato RSA tradicional. ¡Una chulada!
El Workflow de Integración con FreeIPA
Integrar FreeIPA como Sub-CA sigue la misma lógica, pero requiere un pequeño "apretón de manos" entre ambos sistemas:
Generar el CSR desde FreeIPA: Le digo a FreeIPA que pause su CA interna y me genere una solicitud de firma (CSR) para una CA externa:
# Comando para generar la solicitud CSR en FreeIPA ipa-cacert-manage renew --external-ca
Firmar el CSR con mi PKI de EVALinux: Me llevo el archivo CSR al servidor de mi PKI y lo firmo usando el perfil especial sub_ca_ext dentro del directorio del cliente correspondiente:
# Firmado de la solicitud CSR de FreeIPA usando mi PKI cd clients/g02 make certs/ipa-ca.crt ext=sub_ca_ext
Importar y actualizar todo el desmadre: Regreso el certificado firmado y toda la cadena de confianza a FreeIPA para terminar la renovación:
# Comando para importar la cadena firmada y aplicar cambios en FreeIPA ipa-cacert-manage renew \ --external-cert-file=ipa-ca.crt \ --external-cert-file=g02.crt \ --external-cert-file=root.crt ipa-certupdate
La Neta sobre los Dolores de Cabeza
En el papel todo se ve muy chido, pero a la hora de la hora me topé con dos broncas perras. Aquí te paso los tips para que no sufras como yo.
- Pitfall #1: El loop infinito del AKI:
La solicitud CSR que genera FreeIPA suele traer una extensión llamada Authority Key Identifier (AKI) que apunta a sí misma. Si tu CA firma el certificado copiando todas las extensiones tal cual, se genera una referencia circular bien gacha que rompe la validación criptográfica. ¡STAY AWAY! de copiar extensiones a lo loco.
Tip
La solución fue actualizar mi archivo client.cnf para meterle la directiva copy_extensions = none cuando firmo peticiones de Sub-CAs. Así obligo a que mi CA corporativa defina la autoridad y no el solicitante caprichoso.
- Pitfall #2: El cochinero en el directorio LDAP:
A la herramienta ipa-cacert-manage le encanta ir amontonando los nuevos certificados en LDAP sin limpiar los viejos. Si tu nueva Sub-CA se llama igual que el viejo root autorfirmado, Apache se confunde y sirve la cadena vieja e inválida. ¡Qué pinche coraje!
Warning
No te metas a borrar cosas a lo tonto en LDAP si no estás seguro.
Para solucionar este desmadre, tuve que aplicar una cirugía LDAP bien precisa. Usé ldapmodify para borrar manualmente los valores en base64 de los certificados viejos del atributo cACertificate;binary dentro de la ruta cn=ipa,cn=etc. ¡Santo remedio!
Conclusión
A final de cuentas, meter a FreeIPA bajo el paraguas de mi PKI me quitó el dolor de cabeza de andar lidiando con alertas de seguridad en los navegadores. Con una jerarquía limpia de dos niveles y un poquito de automatización chida, todo el entorno Linux camina sobre rieles. ¿Te ha tocado pelearte con FreeIPA y OpenSSL? Cuéntame tu experiencia. ¡A la orden, compa!