Capítulo 1: Criptografía, Estructura PKI y Fundamentos

Antes de Empezar: Este capítulo construye la base conceptual que necesitas antes de tocar un solo certificado. Al finalizar, entenderás por qué existe la criptografía, cómo funciona a nivel práctico, y qué ocurre detrás de escena cuando dos máquinas establecen una conexión segura.

1.1 ¿Por Qué Usar Criptografía?

Imagina enviar una postal. Cualquier persona que la manipule—carteros, vecinos, desconocidos—puede leerla. Ahora imagina que la postal contiene tu contraseña bancaria. Así es como se ve el tráfico de red sin cifrar.

Cada paquete que viaja por una red puede ser interceptado, leído, modificado o falsificado. Sin criptografía:

La criptografía resuelve los cuatro problemas. No es opcional en sistemas modernos—es la base de toda comunicación segura.

1.2 Los Cuatro Pilares de la Seguridad de la Información

La criptografía proporciona cuatro garantías fundamentales. Todo sistema seguro depende de una combinación de estas:

Confidencialidad — “Solo tú puedes leer esto”

La confidencialidad asegura que los datos son legibles únicamente por el destinatario previsto. Incluso si un atacante intercepta los datos, solo ve ruido sin sentido.

Cómo se implementa:

• Cifrado simétrico (AES-256): La misma clave cifra y descifra. Rápido, usado para datos masivos.
• Cifrado asimétrico (RSA, ECC): La clave pública cifra, la clave privada descifra. Usado para intercambio de claves.

Contra qué protege: Espionaje.

Integridad — “Esto no ha sido alterado”

La integridad garantiza que los datos no han sido alterados entre remitente y destinatario. Si un solo bit cambia, la modificación se detecta.

Cómo se implementa:

• Funciones hash (SHA-256): Producen una huella digital de tamaño fijo de los datos.
• HMAC: Hash combinado con una clave secreta para integridad autenticada.
• Firmas digitales: Hash firmado con una clave privada.

 Original:  "Transferir $100 a Bob"  → SHA-256 → a1b2c3d4...
 Alterado:  "Transferir $900 a Bob"  → SHA-256 → f7e8d9c0...  ← ¡DIFERENTE!

Contra qué protege: Alteración.

Autenticidad — “Eres quien dices ser”

La autenticidad prueba la identidad de la parte comunicante. Cuando te conectas al sitio de tu banco, necesitas la seguridad de que realmente es tu banco, no un impostor.

Cómo se implementa:

• Certificados digitales (X.509): Vinculan una clave pública a una identidad.
• Autoridades Certificadoras (CAs): Terceros de confianza que verifican identidades.
• Firmas digitales: Prueban que un mensaje fue creado por el remitente declarado.

Contra qué protege: Suplantación.

No Repudio — “No puedes negar esto”

El no repudio asegura que el remitente no puede negar haber enviado un mensaje o realizado una acción. Es el equivalente digital de una firma manuscrita en un contrato.

Cómo se implementa:

• Firmas digitales con claves privadas: Solo el poseedor de la clave puede producir la firma.
• Sellado de tiempo: Prueba cuándo ocurrió una acción.
• Registros de auditoría con integridad criptográfica: Registros a prueba de manipulación.

Contra qué protege: Repudio (negar responsabilidad).

Resumen: Los Cuatro Pilares

1.3 Funciones Hash: Huellas Digitales de Datos

Una función hash toma una entrada de cualquier tamaño y produce una salida de tamaño fijo. Piensa en ella como una huella dactilar para datos.

Propiedades y Ejemplos

1. Determinista — La misma entrada siempre produce la misma salida.

SHA-256("Hello") → 185f8db32271...  (siempre)
SHA-256("Hello") → 185f8db32271...  (siempre)

2. Unidireccional (Resistencia a Preimagen) — No es posible descubrir la entrada a partir de la salida.

185f8db32271... → ???  (computacionalmente inviable encontrar la entrada)

3. Resistente a Colisiones — Es prácticamente imposible encontrar dos entradas diferentes que produzcan la misma salida.

SHA-256("entrada A") → hash1
SHA-256("entrada B") → hash2
hash1 ≠ hash2  (con probabilidad abrumadora)

4. Efecto Avalancha — Un cambio mínimo en la entrada produce una salida completamente diferente.

SHA-256("Hello World")  → a591a6d40bf420404a011733cfb7b190...
SHA-256("Hello World!") → 7f83b1657ff1fc53b92dc18148a1d65d...
                                     ↑ ¡completamente diferente!

¿Son Seguros los Hashes?

No todos los algoritmos hash son iguales. Algunos han sido rotos:

“Roto” significa: Un atacante puede encontrar dos entradas diferentes que producen el mismo hash (colisión). Esto permite falsificar documentos, certificados o firmas.

# Verifícalo tú mismo — calcula hashes en cualquier sistema RHEL:
echo -n "Hello World" | sha256sum
# a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e

echo -n "Hello World" | md5sum
# b10a8db164e0754105b7a99be72e3fe5  ← ¡NO confíes en esto para seguridad!

Usos Reales de los Hashes

1.4 Criptografía Simétrica vs Asimétrica

Simétrica: Una Clave para Todo

Remitente y destinatario comparten la misma clave secreta. Como un candado donde ambas partes tienen una copia de la misma llave.

Asimétrica: Dos Claves, Dos Roles

Cada parte tiene un par de claves: una clave pública (comparte libremente) y una clave privada (nunca la compartas).

Por Qué Necesitamos Ambas: Cifrado Híbrido

La criptografía asimétrica resuelve el problema de distribución de claves, pero es demasiado lenta para datos masivos. La solución: usar asimétrica para intercambiar una clave simétrica, luego usar simétrica para los datos.

Esto es exactamente lo que ocurre en cada conexión HTTPS.

1.5 Entendiendo el Intercambio de Claves: La Analogía de Mezcla de Colores

Antes de sumergirnos en el handshake TLS/RSA real, construyamos una intuición con una analogía visual. Esto explica el intercambio de claves Diffie-Hellman, el mecanismo usado en TLS moderno para establecer un secreto compartido.

El Problema

Alice y Bob quieren acordar un color secreto compartido que Eve (la espía) no pueda descifrar, aunque Eve pueda ver todo lo que se envían entre sí.

Por Qué Eve No Puede Hacer Trampa

Mezclar pintura es fácil de hacer pero imposible de revertir. No se puede separar pintura mezclada en sus componentes originales. En matemáticas, esto es análogo a:

• Fácil: Multiplicar dos primos grandes → obtener un producto (mezclar)
• Difícil: Factorizar un producto grande → encontrar los primos (separar)

Esta es la función unidireccional que hace funcionar la criptografía.

De Colores a Números

1.6 El Handshake TLS: Cómo Funciona Realmente una Conexión Segura

Ahora veamos qué ocurre realmente cuando tu navegador se conecta a https://banco.com. Esto combina todo lo que hemos aprendido: hashes, criptografía asimétrica, criptografía simétrica, certificados e intercambio de claves.

Recorrido Paso a Paso

Pasos 1-2 (Hello): Cliente y servidor intercambian capacidades y números aleatorios. Estos números aleatorios añaden frescura — garantizan que cada sesión es única, incluso entre las mismas partes.

Paso 3 (Certificate): El servidor prueba su identidad enviando su certificado X.509 que contiene su clave pública.

Paso 4 (Verificación): Este es el paso crítico de confianza. El cliente recorre la cadena de confianza:

Cada firma se verifica usando la clave pública del emisor. Si cualquier eslabón se rompe, el handshake falla.

Paso 5 (Intercambio de Claves): El cliente genera 48 bytes aleatorios (PreMasterSecret), los cifra con la clave pública RSA del servidor y los envía. Solo la clave privada del servidor puede descifrar — esta es la magia asimétrica.

Paso 6 (Derivación de Claves): Ambos lados calculan independientemente las mismas claves de sesión usando una Función Pseudo-Aleatoria (PRF). Aquí es donde transitamos de asimétrica lenta a simétrica rápida.

Pasos 7-9 (Comunicación Cifrada): A partir de aquí, todo se cifra con AES-256 — miles de veces más rápido que RSA.

TLS 1.3 Moderno: Más Simple y Rápido

TLS 1.3 simplificó el handshake eliminando el intercambio de claves RSA (el secreto perfecto hacia adelante ahora es obligatorio) y reduciendo viajes de ida y vuelta:

1.7 Estructura PKI: La Arquitectura de Confianza

Infraestructura de Clave Pública (PKI) es el sistema que gestiona certificados digitales y claves públicas. Responde a la pregunta: “¿Cómo sé que esta clave pública realmente pertenece a banco.com?”

¿Por Qué una Cadena?

Las CAs Raíz son extremadamente valiosas — si se comprometen, cada certificado que hayan firmado se vuelve no confiable. Por eso las CAs Raíz son:

• Almacenadas en módulos de seguridad de hardware (HSMs) fuera de línea, aislados de la red
• Usadas solo para firmar certificados de CAs Intermedias
• Válidas por 20-30 años

Las CAs Intermedias hacen el trabajo diario de emitir certificados. Si se comprometen:

• Solo los certificados de esa Intermedia se ven afectados
• La Raíz puede revocar la Intermedia y crear una nueva
• El daño queda contenido

Revocación: Qué Ocurre Cuando la Confianza se Rompe

Cuando una clave privada se compromete o un certificado ya no debe ser confiable:

1.8 Uniendo Todo: Un Ejemplo Completo

Rastreemos una conexión HTTPS completa de principio a fin, viendo cada concepto en acción:

1.9 Conclusiones Principales

Antes de avanzar a la gestión de certificados específica de RHEL, asegúrate de entender:

Navegación del Capítulo

Capítulo 2: Introducción a los Certificados en RHEL

¡Bienvenido! Este tutorial te llevará desde no saber nada sobre certificados digitales hasta resolver problemas de certificados con confianza en sistemas Red Hat Enterprise Linux.

2.1 ¿Por Qué Este Tutorial?

Eres un administrador de RHEL. Un día, algo se rompe:

• Apache se niega a iniciar: SSL_CTX_use_certificate:ca md too weak
• Las conexiones LDAP fallan: TLS: hostname does not match CN
• certmonger muestra: CA_UNREACHABLE
• curl retorna: SSL certificate problem: unable to get local issuer certificate

¿Te suena familiar? Estos son problemas de certificados, y están en todas partes en los sistemas Linux modernos.

Este tutorial te enseña a:

• ✅ Entender qué son los certificados (perspectiva RHEL)
• ✅ Configurar certificados para servicios comunes de RHEL
• ✅ Resolver problemas de certificados (¡objetivo principal!)
• ✅ Automatizar el ciclo de vida de certificados con herramientas RHEL
• ✅ Manejar diferencias de versiones de RHEL (7, 8, 9, 10)
• ✅ Pasar auditorías (FIPS, STIG, cumplimiento)

2.2 ¿Para Quién es Este Tutorial?

Audiencia Principal:

• Administradores e ingenieros RHEL
• Ingenieros de soporte que resuelven problemas de certificados
• Cualquiera que gestione sistemas RHEL con HTTPS, LDAPS o TLS

Prerrequisitos:

• Conocimientos básicos de línea de comandos Linux
• Acceso a sistemas RHEL (7, 8, 9 o 10)
• ¡No se necesita conocimiento previo de certificados!

2.3 ¿Qué Son los Certificados? (En 60 Segundos)

Imagina que visitas https://example.com. ¿Cómo sabe tu navegador que realmente está hablando con example.com y no con un impostor?

Respuesta: Certificados digitales.

Un certificado es como una tarjeta de identificación digital que:

1. Prueba identidad (“Soy example.com”)
2. Habilita cifrado (comunicación segura)
3. Está firmado por una autoridad confiable (como una CA)

En Sistemas RHEL

Los certificados se usan en todas partes:

• Servidores web (Apache, NGINX) → HTTPS
• Servicios de directorio (OpenLDAP, FreeIPA) → LDAPS
• Servidores de correo (Postfix, Dovecot) → SMTPS/IMAPS
• Bases de datos (PostgreSQL, MySQL) → Conexiones TLS
• APIs y servicios (REST, microservicios) → mTLS
• Túneles VPN → Conexiones seguras
• Registros de contenedores → Imágenes seguras

Conclusión: Si está en red y es seguro en RHEL, probablemente usa certificados.

2.4 Tu Primera Inspección de Certificado

Vamos a hacerlo práctico inmediatamente. Conéctate por SSH a cualquier sistema RHEL y ejecuta:

# Ver el certificado del servidor SSH de tu sistema
sudo openssl s_client -connect localhost:22 -starttls smtp 2>/dev/null | openssl x509 -noout -text

# Mejor ejemplo: Verificar un certificado web
echo | openssl s_client -connect access.redhat.com:443 2>/dev/null | openssl x509 -noout -text | head -20

Verás una salida como:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0a:5d:d2:48:fc:4e:2f:e2:99:81:09:74:2d:4c:d5:69
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C=US, O=DigiCert Inc, CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1
        Validity
            Not Before: Oct 30 00:00:00 2025 GMT
            Not After : Oct 27 23:59:59 2026 GMT
        Subject: C=US, ST=North Carolina, L=Raleigh, O=Red Hat, Inc., CN=access.redhat.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:fc:08:bf:d2:d8:63:0c:84:a4:c8:dd:04:9c:8c:
                    99:4f:cb:93:31:7f:9e:64:27:ea:3d:a7:18:fd:3e:
                    4c:c2:58:8b:cb:f2:5c:6e:95:bf:f3:97:ba:b8:2b:
                    49:c6:51:30:f4:71:88:e3:fa:d4:f1:73:74:1d:e3:
                    2b:49:bc:9e:6e

Lo que estás viendo:

• Issuer: Quién firmó este certificado
• Subject: A quién pertenece este certificado
• Validity: Cuándo es válido (expira el 15 de marzo de 2025)
• Signature Algorithm: Cómo está asegurado (SHA-256 con RSA)

🎉 ¡Felicitaciones! Acabas de inspeccionar tu primer certificado.

2.5 Cómo Funcionan los Certificados (Contexto RHEL)

Los Tres Componentes Clave

1. Certificado (.crt, .pem)

   • Información pública: “Soy server.example.com”
   • Contiene la clave pública
   • Almacenado en /etc/pki/tls/certs/ en RHEL

2. Clave Privada (.key, .pem)

   • ¡Secreto! Nunca compartas esto
   • Se usa para probar que posees el certificado
   • Almacenado en /etc/pki/tls/private/ en RHEL (¡modo 600!)

3. Autoridad Certificadora (CA)

   • Emite y firma certificados
   • Puede ser pública (Let’s Encrypt, DigiCert)
   • O interna (FreeIPA, CA corporativa)
   • CAs confiables almacenadas en /etc/pki/ca-trust/ en RHEL

La Cadena de Confianza

CA Raíz (confiable para el sistema RHEL)
  └─ CA Intermedia
      └─ Certificado del Servidor (tu servidor web)

Cuando alguien se conecta a tu servidor RHEL:

1. El servidor envía su certificado
2. El cliente verifica la cadena de firmas hasta una CA raíz confiable
3. Si la cadena es válida → la conexión procede
4. Si la cadena se rompe → error (¡y tú recibes la llamada de soporte!)

2.6 Arquitectura de Certificados de RHEL

Directorios Clave

/etc/pki/
├── ca-trust/
│   ├── source/anchors/      ← Pon aquí los certificados CA personalizados
│   └── extracted/           ← Almacén de confianza del sistema
│       ├── pem/             ← CAs en formato PEM
│       ├── openssl/         ← Confianza OpenSSL
│       └── java/            ← Confianza Java (cacerts)
├── tls/
│   ├── certs/               ← Certificados de servidor
│   ├── private/             ← Claves privadas (¡modo 700!)
│   └── cert.pem             ← Enlace simbólico de certificado predeterminado
└── nssdb/                   ← Base de datos NSS (Firefox, etc.)

Herramientas Clave

# OpenSSL - Navaja suiza de certificados
openssl version  # Verifica tu versión

# Herramientas NSS - Para bases de datos NSS
certutil -L -d /etc/pki/nssdb

# Gestión de Confianza - Agregar/eliminar CAs
update-ca-trust  # Actualizador del almacén de confianza de RHEL

# Gestor de Certificados - Renovación automática (RHEL 7+)
getcert list  # Mostrar certificados rastreados

# Crypto-Policies - Seguridad en todo el sistema (RHEL 8+)
update-crypto-policies --show  # Verificar política actual

2.7 Un Día en la Vida: Escenarios de Certificados

Escenario 1: Agregar una CA Personalizada

# Tienes una CA corporativa que firmó tus servidores internos
sudo cp corporate-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

# ¡Ahora RHEL confía en certificados firmados por tu CA corporativa!

Escenario 2: Configurar Apache HTTPS

# Instalar Apache con SSL/TLS
sudo dnf install httpd mod_ssl

# Generar una clave privada
sudo openssl genpkey -algorithm RSA -out /etc/pki/tls/private/server.key \
  -pkeyopt rsa_keygen_bits:2048

# Generar una solicitud de firma de certificado (CSR)
sudo openssl req -new -key /etc/pki/tls/private/server.key \
  -out /tmp/server.csr \
  -subj "/CN=web.example.com"

# Enviar CSR a CA, obtener certificado de vuelta, instalarlo
sudo cp server.crt /etc/pki/tls/certs/

# Configurar Apache, reiniciar
sudo systemctl restart httpd

Escenario 3: Resolver un Certificado Expirado

# El servicio falla con: "certificate has expired"
# Verificar expiración del certificado
sudo openssl x509 -in /etc/pki/tls/certs/server.crt -noout -dates

# La salida muestra:
# notAfter=Jan 15 23:59:59 2024 GMT  ← ¡Ups, expirado!

# Renovar certificado, reemplazar archivo, reiniciar servicio

2.8 Diferencias de Versiones RHEL (Vista Previa)

La gestión de certificados ha evolucionado significativamente a través de las versiones de RHEL:

¡No te preocupes! El Capítulo 8 cubre estas diferencias de versión en detalle.

2.9 Problemas Comunes de Certificados (Vista Previa)

Aprenderás a resolver:

Problemas de Configuración:

• Desajuste certificado/clave
• Permisos de archivo incorrectos
• Rutas incorrectas en archivos de configuración

Problemas de Confianza:

• Certificados autofirmados rechazados
• Errores de CA desconocida
• Fallos de validación de cadena

Problemas de Expiración:

• Certificados expirados
• Problemas de desfase de reloj
• Fallos de renovación

Problemas de Versión:

• Desajustes de versión TLS
• Problemas de conjunto de cifrado
• Conflictos de crypto-policy (RHEL 8+)
• Compatibilidad OpenSSL 3.x (RHEL 9+)

Específicos de Servicio:

• Apache: Errores de SSLCertificateFile
• NGINX: Problemas de ssl_certificate
• Postfix: Fallos de handshake TLS
• LDAP: TLS: hostname does not match

2.10 Resumen del Camino de Aprendizaje

Este tutorial está organizado para administradores RHEL:

Parte 1: Fundamentos (Capítulos 1-7)

Comienza aquí. Aprende los conceptos básicos de certificados en contexto RHEL.

Parte 2: Específico por Versión (Capítulos 8-13)

Inmersión Profunda en diferencias de RHEL 7, 8, 9, 10.

Parte 3: Servicios (Capítulos 14-21)

Configura certificados para Apache, NGINX, Postfix, LDAP, etc.

Parte 4: Automatización (Capítulos 22-26)

Domina certmonger, crypto-policies, Let’s Encrypt, Ansible.

Parte 5: Solución de Problemas (Capítulos 27-33) ⭐

¡Aquí es donde te conviertes en un experto! Resolución sistemática de problemas, errores comunes, procedimientos de emergencia.

Parte 6: Migración (Capítulos 34-37)

Actualizaciones de versiones RHEL y migración de certificados.

Parte 7: Seguridad (Capítulos 38-41)

Modo FIPS, cumplimiento, fortalecimiento, auditoría.

Apéndices

Temas avanzados opcionales (Kubernetes, Vault, Zero Trust, etc.)

2.11 Cómo Usar Este Tutorial

Para Usuarios Nuevos

📖 Lee los capítulos en orden. Cada uno se basa en el conocimiento previo.

Para Usuarios Experimentados

🎯 Salta a solución de problemas (Parte 5) o servicios específicos (Parte 3).

Para Ingenieros de Soporte

🚨 Comienza con el Capítulo 27 (Metodología de Solución de Problemas de Certificados RHEL), luego profundiza en detalles.

Laboratorios Prácticos

Cada capítulo incluye ejemplos prácticos. Necesitarás:

• Un sistema RHEL (una VM o contenedor está bien)
• Acceso root o sudo
• Conectividad a Internet (para instalaciones de paquetes)

2.12 Conceptos Clave a Dominar

Al final de este tutorial, entenderás:

• ✅ Qué son los certificados y por qué RHEL los usa
• ✅ Cómo funciona la confianza en sistemas RHEL
• ✅ Dónde viven los certificados (/etc/pki/)
• ✅ Qué herramientas usar (openssl, certutil, certmonger)
• ✅ Diferencias de versión (RHEL 7 vs 8 vs 9 vs 10)
• ✅ Cómo resolver problemas de cualquier certificado
• ✅ Cómo automatizar el ciclo de vida de certificados
• ✅ Cómo asegurar sistemas (FIPS, cumplimiento)

2.13 Impacto en el Mundo Real

Los problemas de certificados causan:

• ❌ Interrupciones de servicio (certificados expirados)
• ❌ Vulnerabilidades de seguridad (cifrados débiles)
• ❌ Migraciones fallidas (actualizaciones de RHEL)
• ❌ Fallos de cumplimiento (rechazos de auditoría)
• ❌ Pérdida de productividad (tiempo de solución de problemas)

Después de este tutorial:

• ✅ Prevenir problemas antes de que sucedan
• ✅ Resolver problemas en minutos, no horas
• ✅ Automatizar la gestión de certificados
• ✅ Pasar auditorías de seguridad
• ✅ Migrar versiones de RHEL con confianza

2.14 Tu Primer Ejercicio

Vamos a verificar que tu sistema RHEL está listo:

# Verificar versión de RHEL
cat /etc/redhat-release

# Verificar OpenSSL
openssl version

# Verificar si certmonger está instalado
rpm -q certmonger

# Verificar si puedes usar sudo
sudo whoami

# Verificar conectividad a Internet (para instalaciones de paquetes)
ping -c 3 access.redhat.com

# Listar CAs confiables actuales (muestra)
trust list | head -20

✅ ¡Si todos los comandos funcionan, estás listo para continuar!

2.15 ¡Comencemos!

Ahora entiendes:

• Qué son los certificados
• Por qué importan en RHEL
• Dónde viven en el sistema de archivos
• Qué herramientas usarás
• Qué aprenderás en este tutorial

¿Listo para profundizar más?

Referencia Rápida

┌─────────────────────────────────────────────────────────────────┐
│ INICIO RÁPIDO DE CERTIFICADOS (RHEL)                            │
├─────────────────────────────────────────────────────────────────┤
│ Ver cert:           openssl x509 -in cert.crt -noout -text      │
│ Ver expiración:     openssl x509 -in cert.crt -noout -dates     │
│ Agregar CA:         cp ca.crt /etc/pki/ca-trust/source/anchors/ │
│                     sudo update-ca-trust                        │
│ Listar rastreados:  getcert list                                │
│ Ver política:       update-crypto-policies --show  (RHEL 8+)    │
└─────────────────────────────────────────────────────────────────┘

Ubicación cert:  /etc/pki/tls/certs/
Ubicación key:   /etc/pki/tls/private/  (¡modo 600!)
Confianza CA:    /etc/pki/ca-trust/

🧪 Laboratorio Práctico

Lab 01: Configuración del Entorno

Valida tu entorno RHEL e instala herramientas esenciales de gestión de certificados

• 📁 Ubicación: labs/es_ES/01-environment-setup/
• ⏱️ Tiempo: 15-20 minutos
• 🎯 Nivel: Principiante

Navegación del Capítulo

Capítulo 3: Resumen de Herramientas de Certificados en RHEL

Objetivo de Aprendizaje: Familiarízate con las herramientas esenciales para gestionar certificados en RHEL para que sepas qué herramienta usar para cada tarea.

3.1 Tu Caja de Herramientas de Certificados

Al trabajar con certificados en RHEL, usarás estas herramientas principales:

3.2 OpenSSL - La Navaja Suiza

Disponible: Todas las versiones de RHEL Paquete: openssl

Diferencias de Versión

# Verificar tu versión
openssl version

# RHEL 7: OpenSSL 1.0.2k-26
# RHEL 8: OpenSSL 1.1.1k-14
# RHEL 9: OpenSSL 3.5.5-2
# RHEL 10: OpenSSL 3.5.5-2

Usos Comunes

#============================================#
# INSPECCIONAR CERTIFICADOS
#============================================#

# Ver detalles del certificado
openssl x509 -in cert.crt -noout -text

# Verificar expiración
openssl x509 -in cert.crt -noout -dates
openssl x509 -in cert.crt -noout -checkend 86400  # Verificar si expira en 24h

# Ver asunto del certificado
openssl x509 -in cert.crt -noout -subject -issuer


#============================================#
# GENERAR CLAVES
#============================================#

# Estilo RHEL 7 (aún funciona en todas las versiones)
openssl genrsa -out server.key 2048

# Estilo moderno RHEL 8+ (recomendado)
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

# Clave EC RHEL 9+ (curva elíptica)
openssl genpkey -algorithm EC -out ec.key -pkeyopt ec_paramgen_curve:P-256


#============================================#
# CREAR CSR (Solicitud de Firma de Certificado)
#============================================#

# CSR básico
openssl req -new -key server.key -out server.csr \
  -subj "/C=US/ST=State/L=City/O=Organization/CN=server.example.com"

# CSR con SANs (¡requerido para navegadores modernos!)
openssl req -new -key server.key -out server.csr \
  -subj "/CN=server.example.com" \
  -addext "subjectAltName=DNS:server.example.com,DNS:www.example.com"


#============================================#
# PROBAR CONEXIONES
#============================================#

# Probar HTTPS
openssl s_client -connect server.example.com:443 -servername server.example.com

# Probar versión TLS específica
openssl s_client -connect server.example.com:443 -tls1_2
openssl s_client -connect server.example.com:443 -tls1_3

# Probar LDAPS
openssl s_client -connect ldap.example.com:636

# Probar SMTP con STARTTLS
openssl s_client -connect mail.example.com:25 -starttls smtp

Diferencias Específicas por Versión

RHEL 7 (OpenSSL 1.0.2k):

• ✅ Estable y bien probado
• ❌ Sin soporte TLS 1.3
• ❌ Sintaxis de comando antigua

RHEL 8 (OpenSSL 1.1.1k):

• ✅ Soporte TLS 1.3
• ✅ Sintaxis de comando moderna
• ✅ Mejores valores predeterminados

RHEL 9/10 (OpenSSL 3.5.5):

• ✅ Arquitectura de proveedores
• ✅ Soporte FIPS mejorado
• ⚠️ Cambios en API (afecta apps personalizadas)
• ⚠️ Algoritmos heredados requieren -provider legacy

3.3 certutil - Herramienta de Base de Datos NSS

Disponible: Todas las versiones de RHEL Paquete: nss-tools

Usado para bases de datos de certificados estilo Mozilla/Firefox.

Usos Comunes

#============================================#
# GESTIONAR BASE DE DATOS NSS
#============================================#

# Crear nueva base de datos
certutil -N -d /etc/pki/nssdb

# Listar certificados
certutil -L -d /etc/pki/nssdb

# Agregar certificado CA
certutil -A -n "My CA" -t "CT,C,C" -d /etc/pki/nssdb -i ca.crt

# Eliminar certificado
certutil -D -n "Certificate Name" -d /etc/pki/nssdb

# Exportar certificado
certutil -L -n "Certificate Name" -d /etc/pki/nssdb -a > exported.crt

Cuándo Usar certutil

• Gestionar certificados de Firefox/Thunderbird
• Trabajar con aplicaciones que usan NSS (muchos servicios Red Hat)
• Cuando veas archivos .db en /etc/pki/nssdb/

3.4 update-ca-trust - Gestión del Almacén de Confianza

Disponible: Todas las versiones de RHEL Paquete: ca-certificates (instalado por defecto)

Gestiona qué Autoridades Certificadoras (CAs) confía tu sistema.

Cómo Funciona

Tus CAs Personalizadas
  ↓
/etc/pki/ca-trust/source/anchors/
  ↓
update-ca-trust extract
  ↓
/etc/pki/ca-trust/extracted/
  ├── pem/tls-ca-bundle.pem       (OpenSSL/Python/Ruby)
  ├── openssl/ca-bundle.trust.crt (Específico de OpenSSL)
  └── java/cacerts                (Aplicaciones Java)

Usos Comunes

#============================================#
# AGREGAR CA PERSONALIZADA
#============================================#

# Paso 1: Copiar certificado CA
sudo cp corporate-ca.crt /etc/pki/ca-trust/source/anchors/

# Paso 2: Actualizar almacén de confianza
sudo update-ca-trust extract

# ¡Eso es todo! Ahora todas las aplicaciones confían en esta CA


#============================================#
# ELIMINAR/PONER EN LISTA NEGRA CA (RHEL 8+)
#============================================#

# Poner en lista negra una CA comprometida
sudo cp compromised-ca.crt /etc/pki/ca-trust/source/blacklist/
sudo update-ca-trust extract


#============================================#
# VERIFICAR CONFIANZA
#============================================#

# Verificar si el certificado es confiable
openssl verify /path/to/cert.crt

# Listar todas las CAs confiables
trust list | grep "certificate-authority"

# Buscar CA específica
trust list | grep -i "Let's Encrypt"

Directorios Clave

/etc/pki/ca-trust/
├── source/
│   ├── anchors/          ← Agrega tus CAs confiables aquí
│   └── blacklist/        ← Lista negra de CAs (RHEL 8+)
└── extracted/
    ├── pem/              ← Usado por la mayoría de apps
    ├── openssl/          ← Específico de OpenSSL
    └── java/             ← Aplicaciones Java

3.5 certmonger - Renovación Automática de Certificados

Disponible: Todas las versiones de RHEL Paquete: certmonger

La herramienta “configúralo y olvídate” para certificados.

Qué Hace

certmonger:

• Rastrea fechas de expiración de certificados
• Renueva automáticamente antes de expirar
• Funciona con múltiples CAs (IPA, Let’s Encrypt, externa)
• Ejecuta comandos post-renovación (ej: reiniciar servicios)

Flujo de Trabajo Básico

#============================================#
# INSTALACIÓN
#============================================#

sudo dnf install certmonger
sudo systemctl enable --now certmonger


#============================================#
# SOLICITAR CERTIFICADO
#============================================#

# Desde FreeIPA
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/web.crt \
  -k /etc/pki/tls/private/web.key \
  -D web.example.com \
  -K host/web.example.com@REALM

# Autofirmado (para pruebas)
sudo getcert request \
  -f /etc/pki/tls/certs/test.crt \
  -k /etc/pki/tls/private/test.key


#============================================#
# MONITOREAR CERTIFICADOS
#============================================#

# Listar todos los certificados rastreados
sudo getcert list

# Verificar certificado específico
sudo getcert list -f /etc/pki/tls/certs/web.crt

# Observar renovación
sudo journalctl -u certmonger -f

Características Clave por Versión

RHEL 7:

• Rastreo y renovación básicos
• Integración con IPA
• Configuración manual

RHEL 8:

• Integración mejorada con IPA
• Mejor reporte de errores
• Comandos post-guardado

RHEL 9:

• Soporte ACME (¡Let’s Encrypt!)
• Monitoreo mejorado
• Mejor reporte de estado

# RHEL 9 - Integración con Let's Encrypt
sudo getcert request \
  -f /etc/pki/tls/certs/acme.crt \
  -k /etc/pki/tls/private/acme.key \
  -D example.com \
  -c acme-letsencrypt \
  -C "systemctl reload httpd"

3.6 crypto-policies - Seguridad en Todo el Sistema (RHEL 8+)

Disponible: Solo RHEL 8, 9, 10 Paquete: crypto-policies (instalado por defecto)

CAMBIO DE JUEGO: ¡Controla versiones TLS, cifrados y tamaños de clave en todo el sistema!

La Gran Idea

En lugar de configurar cada aplicación individualmente:

❌ FORMA ANTIGUA (RHEL 7):
- Configurar cifrados SSL de Apache
- Configurar cifrados SSL de NGINX
- Configurar ajustes TLS de Postfix
- Configurar ajustes TLS de OpenLDAP
- Configurar cada aplicación...

✅ FORMA NUEVA (RHEL 8+):
- Establecer UNA política del sistema
- ¡Todas las aplicaciones la siguen automáticamente!

Políticas Disponibles

# Verificar política actual
update-crypto-policies --show

# Políticas:
# DEFAULT  - Seguridad equilibrada (TLS 1.2+, RSA 2048+)
# LEGACY   - Modo de compatibilidad (permite TLS 1.0/1.1)
# FUTURE   - Seguridad más estricta (TLS 1.2+, RSA 3072+)
# FIPS     - Modo de cumplimiento federal

Comparación de Políticas

Usos Comunes

#============================================#
# CAMBIAR POLÍTICA
#============================================#

# Establecer política FUTURE (más estricta)
sudo update-crypto-policies --set FUTURE
# Reiniciar o reiniciar servicios

# Usar temporalmente LEGACY (para sistemas antiguos)
sudo update-crypto-policies --set LEGACY
# Nota: ¡LEGACY debe ser temporal!


#============================================#
# POLÍTICAS PERSONALIZADAS (RHEL 9+)
#============================================#

# Subpolíticas - modificar política existente
sudo update-crypto-policies --set DEFAULT:NO-SHA1
sudo update-crypto-policies --set FUTURE:AD-SUPPORT


#============================================#
# RESOLVER PROBLEMAS DE POLÍTICA
#============================================#

# Si el servicio falla después del cambio de política:
# 1. Verificar política actual
update-crypto-policies --show

# 2. Verificar configuración de aplicación
cat /etc/crypto-policies/back-ends/opensslcnf.config

# 3. Probar con LEGACY temporalmente
sudo update-crypto-policies --set LEGACY
sudo systemctl restart <service>

Qué Controla crypto-policies

Configura automáticamente:

• OpenSSL
• GnuTLS
• NSS
• OpenJDK/Java
• BIND
• Kerberos
• OpenSSH
• ¡Y más!

Conclusión: Cambia un ajuste, actualiza la seguridad de todo el sistema. ¡Brillante!

3.7 Guía de Selección de Herramientas

“¿Qué herramienta debo usar?”

┌─────────────────────────────────────────────────────────────┐
│ ÁRBOL DE DECISIÓN DE HERRAMIENTAS DE CERTIFICADOS           │
└─────────────────────────────────────────────────────────────┘

Necesito...
│
├─ Inspeccionar un certificado
│  └─ Usar: openssl x509 -in cert.crt -noout -text
│
├─ Generar una clave/CSR
│  └─ Usar: openssl genpkey / openssl req
│
├─ Probar una conexión TLS
│  └─ Usar: openssl s_client -connect host:port
│
├─ Agregar una CA confiable en todo el sistema
│  └─ Usar: copiar a /etc/pki/ca-trust/source/anchors/
│          luego: update-ca-trust
│
├─ Renovar certificados automáticamente
│  └─ Usar: certmonger (getcert/ipa-getcert)
│
├─ Cambiar política TLS del sistema (RHEL 8+)
│  └─ Usar: update-crypto-policies --set <POLICY>
│
├─ Trabajar con bases de datos Firefox/NSS
│  └─ Usar: certutil
│
└─ Resolver problemas de certificados
   └─ Usar: ¡Metodología del Capítulo 27!

3.8 Matriz de Disponibilidad de Herramientas

3.9 Verificación de Instalación

Verifica que tienes las herramientas esenciales:

#============================================#
# VERIFICAR HERRAMIENTAS INSTALADAS
#============================================#

# OpenSSL (debe estar instalado por defecto)
openssl version

# Herramientas NSS
rpm -q nss-tools || echo "Instalar con: sudo dnf install nss-tools"

# certmonger
rpm -q certmonger || echo "Instalar con: sudo dnf install certmonger"

# Verificar crypto-policies (solo RHEL 8+)
which update-crypto-policies &>/dev/null && \
  echo "Crypto-policies disponible: $(update-crypto-policies --show)" || \
  echo "Crypto-policies no disponible (RHEL 7 o anterior)"

3.10 Comandos de Referencia Rápida

# === OpenSSL ===
openssl version                          # Verificar versión
openssl x509 -in cert.crt -noout -text   # Inspeccionar certificado
openssl s_client -connect host:443       # Probar HTTPS

# === Almacén de Confianza ===
sudo cp ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust                     # Agregar CA confiable

# === certmonger ===
sudo getcert list                        # Listar certs rastreados
sudo getcert list -f /path/to/cert.crt   # Verificar cert específico
sudo journalctl -u certmonger -f         # Ver logs

# === Crypto-Policies (RHEL 8+) ===
update-crypto-policies --show            # Política actual
sudo update-crypto-policies --set <POL>  # Cambiar política

# === NSS ===
certutil -L -d /etc/pki/nssdb            # Listar certs NSS

3.11 ¿Qué Sigue?

Ahora que conoces las herramientas, aprenderás:

• Capítulo 4: Conceptos básicos de criptografía
• Capítulo 5: Entender certificados X.509
• Capítulo 6: Inmersión Profunda en almacén de confianza RHEL
• Capítulo 22: Dominio de certmonger (detallado)
• Capítulo 23: Inmersión Profunda en Crypto-policies (detallado)

Tarjeta de Referencia Rápida

┌────────────────────────────────────────────────────────────┐
│ HOJA DE TRUCOS DE HERRAMIENTAS DE CERTIFICADOS RHEL        │
├────────────────────────────────────────────────────────────┤
│ Inspeccionar:  openssl x509 -in cert.crt -noout -text      │
│ Probar:        openssl s_client -connect host:443          │
│ Agregar CA:    cp ca.crt /etc/pki/ca-trust/source/anchors/ │
│                sudo update-ca-trust                        │
│ Renovar auto:  sudo getcert list                           │
│ Política:      update-crypto-policies --show  (RHEL 8+)    │
│ NSS:           certutil -L -d /etc/pki/nssdb               │
└────────────────────────────────────────────────────────────┘

Navegación del Capítulo

Capítulo 4: Criptografía Básica para Administradores RHEL

Enfoque Práctico: Aprende los conceptos de criptografía que necesitas para gestionar certificados en RHEL - ¡no se requiere un doctorado!

4.1 Simétrica vs Asimétrica

La criptografía simétrica (ej. AES) se basa en un único secreto compartido. En contraste, la criptografía asimétrica proporciona dos claves complementarias:

• Clave pública — compártela libremente, usada para cifrado o verificación de firma.
• Clave privada — mantenla secreta, usada para descifrado o firma.

4.2 RSA en Pocas Palabras

1. Selecciona dos números primos grandes p y q.
2. Calcula el módulo n = p × q.
3. Deriva el exponente público e y el exponente privado d tal que e × d ≡ 1 (mod φ(n)).
4. El par (n, e) es público; (n, d) es privado.

La fortaleza deriva de la dificultad de factorizar n.

4.3 Criptografía de Curva Elíptica (ECC)

ECC ofrece seguridad comparable con tamaños de clave mucho más pequeños al operar sobre puntos en curvas elípticas. Las curvas populares incluyen secp256r1 (P-256) y Curve25519.

4.4 Laboratorio de Generación de Claves (OpenSSL)

# Generar clave privada RSA de 3072 bits
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out rsa.key.pem

# Extraer clave pública
openssl pkey -in rsa.key.pem -pubout -out rsa.pub.pem

# Generar par de claves EC P-256
openssl ecparam -genkey -name prime256v1 -out ec.key.pem
openssl pkey -in ec.key.pem -pubout -out ec.pub.pem

Reutilizaremos estas claves en capítulos posteriores para crear certificados.

4.5 Cifrado Híbrido

En TLS, una clave de sesión simétrica se intercambia usando criptografía asimétrica (RSA o ECDHE). Esto proporciona lo mejor de ambos mundos: eficiencia e intercambio seguro de claves.

4.6 Consideraciones Específicas de RHEL

Generación de Claves en RHEL por Versión

RHEL 7 (OpenSSL 1.0.2k):

# Estilo antiguo (aún funciona en todas las versiones)
openssl genrsa -out server.key 2048

# Extraer clave pública
openssl rsa -in server.key -pubout -out server.pub

RHEL 8+ (OpenSSL 1.1.1k / 3.5.5):

# Estilo moderno (recomendado)
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

# Extraer clave pública
openssl pkey -in server.key -pubout -out server.pub

Tamaños Mínimos de Clave por Versión de RHEL

Recomendación: ¡Siempre usa RSA 2048+ o ECC P-256+ para compatibilidad!

Pruebas en RHEL

# Generar par de claves de prueba (RHEL 8+)
openssl genpkey -algorithm RSA -out test.key -pkeyopt rsa_keygen_bits:2048

# Verificar clave
openssl pkey -in test.key -text -noout

# Crear datos de prueba
echo "Hola RHEL" > message.txt

# Firmar con clave privada
openssl dgst -sha256 -sign test.key -out message.sig message.txt

# Verificar con clave pública
openssl dgst -sha256 -verify test.pub -signature message.sig message.txt
# Verified OK

Referencia Rápida

┌─────────────────────────────────────────────────────────────┐
│ CRIPTOGRAFÍA PARA ADMINISTRADORES RHEL                      │
├─────────────────────────────────────────────────────────────┤
│ Asimétrica:   Clave pública (compartir) + Privada (secreta) │
│ Algoritmos:   RSA, ECC (Curva Elíptica)                     │
│                                                             │
│ Tamaños RSA:  2048 bits (mínimo en RHEL 8+)                 │
│               4096 bits (recomendado)                       │
│                                                             │
│ Curvas ECC:   P-256 (secp256r1) - mínimo                    │
│               P-384 (secp384r1) - recomendado               │
│                                                             │
│ RHEL 7:       openssl genrsa -out key 2048                  │
│ RHEL 8/9/10:  openssl genpkey -algorithm RSA -out key       │
│                                                             │
│ Caso de uso:  Certificados TLS/SSL                          │
│ Seguridad:    Clave privada DEBE protegerse (chmod 600)     │
└─────────────────────────────────────────────────────────────┘

🧪 Laboratorio Práctico

Lab 02: Generación de Claves

Practica la generación de pares de claves criptográficas en este ejercicio práctico

• 📁 Ubicación: labs/es_ES/02-key-generation/
• ⏱️ Tiempo: 20-25 minutos
• 🎯 Nivel: Principiante

Navegación del Capítulo

Capítulo 5: Certificados X.509 en RHEL

Formato Estándar: X.509 es el estándar de certificados usado en todas partes en RHEL. Aprende su estructura y cómo trabajar con él en sistemas Red Hat.

5.1 Orígenes del Estándar

X.509 surgió del proyecto de directorio X.500 (ITU-T, 1988) para definir un certificado de identidad estándar—un documento que vincula una clave pública a un nombre de sujeto, firmado por una autoridad confiable.

5.2 Anatomía del Certificado

5.3 Extensiones Comunes

• Subject Alternative Name (SAN) — Hosts/IPs vinculados al cert.
• Key Usage / Extended Key Usage — Operaciones permitidas (servidor TLS, firma de código…).
• Basic Constraints — Indica si el cert puede firmar otros (CA:TRUE).

5.4 Ver un Certificado

openssl x509 -in server.crt -noout -text

Observa que cada sección coincide con la tabla anterior.

5.5 Codificaciones PEM vs DER

• PEM — Base64 + encabezados -----BEGIN CERTIFICATE----- (más común en RHEL).
• DER — ASN.1 binario, útil para dispositivos embebidos.

5.6 X.509 en Sistemas RHEL

Ubicaciones de Certificados en RHEL

# Ubicaciones estándar de certificados en RHEL
/etc/pki/tls/certs/          # Certificados de servidor (públicos)
/etc/pki/tls/private/        # Claves privadas (¡modo 600!)
/etc/pki/ca-trust/           # Certificados CA confiables
/etc/pki/nssdb/              # Base de datos NSS (Firefox, etc.)

# Ubicaciones específicas de servicios
/etc/httpd/conf/ssl.crt/     # Apache (alternativa)
/etc/nginx/certs/            # NGINX (personalizado)
/var/lib/pgsql/data/         # PostgreSQL
/etc/openldap/certs/         # OpenLDAP

Ver Certificados en RHEL

# Ver detalles completos del certificado
openssl x509 -in /etc/pki/tls/certs/server.crt -noout -text

# Verificaciones rápidas (enfoque sysadmin RHEL)
openssl x509 -in server.crt -noout -subject             # ¿Para quién es?
openssl x509 -in server.crt -noout -issuer              # ¿Quién lo firmó?
openssl x509 -in server.crt -noout -dates               # ¿Cuándo es válido?
openssl x509 -in server.crt -noout -ext subjectAltName  # SANs (¡crítico!)

# Verificar si expiró
openssl x509 -in server.crt -noout -checkend 0
# Exit 0 = válido, Exit 1 = expirado

Diferencias de Versión RHEL para X.509

Punto Clave: Los navegadores modernos y RHEL 9+ requieren SANs (Subject Alternative Names)!

Crear Certificados X.509 en RHEL

# Flujo de trabajo completo en RHEL

# Paso 1: Generar clave privada
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

# Paso 2: Crear CSR (Solicitud de Firma de Certificado)
openssl req -new -key server.key -out server.csr \
  -subj "/C=US/ST=State/O=Company/CN=server.example.com" \
  -addext "subjectAltName=DNS:server.example.com,DNS:www.example.com"

# Paso 3: Autofirmado (¡solo para pruebas!)
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

# Paso 4: Ver tu certificado X.509
openssl x509 -in server.crt -noout -text

# Paso 5: Instalar en RHEL
sudo cp server.crt /etc/pki/tls/certs/
sudo cp server.key /etc/pki/tls/private/
sudo chmod 600 /etc/pki/tls/private/server.key

Referencia Rápida

┌─────────────────────────────────────────────────────────────────────┐
│ CERTIFICADOS X.509 EN RHEL                                          │
├─────────────────────────────────────────────────────────────────────┤
│ Estándar:      X.509 v3 (con extensiones)                           │
│ Codificación:  PEM (Base64, legible por humanos)                    │
│                                                                     │
│ Ver:           openssl x509 -in cert.crt -noout -text               │
│ Sujeto:        openssl x509 -in cert.crt -noout -subject            │
│ Expiración:    openssl x509 -in cert.crt -noout -dates              │
│ SANs:          openssl x509 -in cert.crt -noout -ext subjectAltName │
│                                                                     │
│ Ubicación:     /etc/pki/tls/certs/ (certificados)                   │
│                /etc/pki/tls/private/ (claves, ¡modo 600!)           │
│                                                                     │
│ Crítico:       SANs son REQUERIDOS en RHEL 9+                       │
│                Firma SHA-256+ requerida en RHEL 8+                  │
└─────────────────────────────────────────────────────────────────────┘

🧪 Laboratorio Práctico

Lab 04: Certificados X.509

Crea certificados autofirmados, genera CSRs, inspecciona certificados y convierte formatos

• 📁 Ubicación: labs/es_ES/04-x509-certificates/
• ⏱️ Tiempo: 25-30 minutos
• 🎯 Nivel: Principiante

Navegación del Capítulo

Capítulo 6: Inmersión Profunda en el Almacén de Confianza de RHEL

Arquitectura de Confianza: Entender cómo RHEL valida certificados y gestiona CAs confiables es esencial para resolver problemas de certificados. Este capítulo va más allá de lo básico: cubre la mecánica interna de update-ca-trust, cómo p11-kit procesa las fuentes de confianza, qué sucede con los certificados duplicados y cómo depurar problemas de confianza con trust list.

6.1 Arquitectura del Almacén de Confianza de RHEL

Cómo RHEL Valida Certificados

Cuando cualquier aplicación en RHEL valida un certificado:

1. Verificar firma del certificado usando la clave pública del emisor
2. Encontrar certificado del emisor en el almacén de confianza
3. Repetir hasta alcanzar la CA raíz confiable
4. Verificar que la CA raíz es confiable por el sistema RHEL

Ubicación del almacén de confianza: /etc/pki/ca-trust/

El Rol de p11-kit

El almacén de confianza de RHEL no es un archivo plano que las aplicaciones leen directamente. Es un sistema gestionado construido sobre p11-kit, que proporciona un módulo de confianza PKCS#11. Los componentes clave son:

Aplicaciones como curl, wget, OpenSSL, GnuTLS y NSS consumen los paquetes extraídos. Nunca leen los directorios fuente directamente.

6.2 Estructura de Directorios del Almacén de Confianza

RHEL 7/8:

/etc/pki/ca-trust/
├── source/
│   ├── anchors/                   ← Certificados CA confiables agregados por el administrador
│   ├── blacklist/                 ← Certificados desconfiados agregados por el administrador
│   └── ca-bundle.legacy.crt       ← Paquete heredado (solo compatibilidad)
├── extracted/
│   ├── pem/
│   │   ├── tls-ca-bundle.pem      ← Para clientes TLS (curl, wget, Python...)
│   │   ├── email-ca-bundle.pem    ← Para validación de correo S/MIME
│   │   └── objsign-ca-bundle.pem  ← Para verificación de firma de código
│   ├── openssl/
│   │   └── ca-bundle.trust.crt    ← Formato "certificado confiable" de OpenSSL
│   ├── java/
│   │   └── cacerts                ← Keystore JKS de Java
│   └── edk2/
│       └── cacerts.bin            ← Formato de firmware UEFI
└── README

/usr/share/pki/ca-trust-source/
├── anchors/                       ← Anclas de confianza provistas por paquetes (desde RPMs)
├── blacklist/                     ← Certificados desconfiados provistos por paquetes
└── ca-bundle.trust.p11-kit        ← Paquete de CAs de Mozilla incluido por el RPM ca-certificates

RHEL 9/10+: El directorio blacklist/ fue renombrado a blocklist/:

/etc/pki/ca-trust/
├── source/
│   ├── anchors/                   ← Certificados CA confiables agregados por el administrador
│   ├── blocklist/                 ← Certificados desconfiados agregados por el administrador
│   └── ca-bundle.legacy.crt       ← Paquete heredado (solo compatibilidad)
├── extracted/
│   └── (misma estructura que arriba)
└── README

/usr/share/pki/ca-trust-source/
├── anchors/                       ← Anclas de confianza provistas por paquetes (desde RPMs)
├── blocklist/                     ← Certificados desconfiados provistos por paquetes
└── ca-bundle.trust.p11-kit        ← Paquete de CAs de Mozilla incluido por el RPM ca-certificates

Convención de nombres: A lo largo de este capítulo, blacklist/ se refiere al nombre de directorio en RHEL 7/8 y blocklist/ se refiere al nombre de directorio en RHEL 9/10+. Ambos cumplen el mismo propósito. Cuando veas una ruta como source/blacklist/, sustitúyela por source/blocklist/ en RHEL 9+.

Prioridad de Directorios Fuente

La cadena de procesamiento de update-ca-trust lee certificados de múltiples directorios fuente, procesados en un orden definido:

Dentro de cada ubicación:

• anchors/ — Los certificados colocados aquí se tratan como CAs confiables
• blacklist/ (RHEL 7/8) o blocklist/ (RHEL 9+) — Los certificados colocados aquí se tratan como explícitamente desconfiados

Las rutas en /etc/pki/ siempre anulan las rutas en /usr/share/pki/. Esto sigue la convención estándar de RHEL: /usr/share/ contiene los valores predeterminados de paquetes, /etc/ contiene las personalizaciones del administrador.

6.3 Qué Sucede Cuando Ejecutas update-ca-trust

La Cadena de Ejecución

update-ca-trust es un script de shell (inspecciónalo tú mismo: cat /usr/bin/update-ca-trust). Cuando ejecutas sudo update-ca-trust, ocurre la siguiente secuencia:

Paso 1: Recopilar todas las fuentes de confianza

p11-kit lee cada archivo de certificado de estos directorios:

/usr/share/pki/ca-trust-source/anchors/
/usr/share/pki/ca-trust-source/blacklist/    ← RHEL 7/8
/usr/share/pki/ca-trust-source/blocklist/    ← RHEL 9+
/usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit
/etc/pki/ca-trust/source/anchors/
/etc/pki/ca-trust/source/blacklist/          ← RHEL 7/8
/etc/pki/ca-trust/source/blocklist/          ← RHEL 9+

Acepta formatos PEM (.pem, .crt), DER (.der) y objetos de confianza p11-kit (.p11-kit).

Paso 2: Analizar atributos de confianza

Para cada certificado, p11-kit determina su disposición de confianza. El formato PEM del archivo de certificado es relevante:

• -----BEGIN TRUSTED CERTIFICATE----- (formato “confiable” de OpenSSL) — Contiene el certificado más datos auxiliares de confianza: listas explícitas de OIDs de uso de clave confiados y rechazados. p11-kit lee estos atributos embebidos de confianza/rechazo directamente.
• -----BEGIN CERTIFICATE----- (PEM simple) o DER — Contiene solo el certificado sin metadatos de confianza. p11-kit asigna la confianza basándose únicamente en el directorio donde se coloca el archivo (anchors/ = confiable, blacklist//blocklist/ = desconfiado).
• Archivos en formato .p11-kit — Contienen objetos de confianza PKCS#11 con atributos de grano fino (trusted, x-distrusted, OIDs de propósito). Utilizados por el archivo ca-bundle.trust.p11-kit incluido con el paquete ca-certificates.

Crítico: Los formatos BEGIN TRUSTED CERTIFICATE y BEGIN CERTIFICATE no son intercambiables. Un archivo BEGIN TRUSTED CERTIFICATE lleva datos auxiliares de confianza — listas explícitas de OIDs de uso confiable y/o rechazado. Cuando no se listan usos (atributos de confianza vacíos), p11-kit lo interpreta como “confiable para nada” — efectivamente desconfiado. Si el mismo certificado también existe como BEGIN CERTIFICATE simple (que implica confianza para todos los propósitos), p11-kit detecta aserciones de confianza contradictorias y marca el certificado como desconfiado. Este conflicto ocurre en dos casos: (1) el BEGIN TRUSTED CERTIFICATE tiene usos rechazados explícitos, o (2) tiene atributos de confianza vacíos (ningún uso confiable, ningún uso rechazado). Ver Sección 6.6 para detalles.

Paso 3: Fusionar y resolver conflictos

Cuando el mismo certificado (identificado por su contenido codificado en DER) aparece en múltiples ubicaciones fuente, p11-kit aplica reglas de fusión:

1. La desconfianza prevalece sobre la confianza. Si un certificado aparece tanto en anchors/ como en blacklist//blocklist/, se desconfía de él.

2. El administrador anula los paquetes. Los atributos de confianza establecidos en /etc/pki/ca-trust/source/ anulan los de /usr/share/pki/ca-trust-source/.

3. Los atributos explícitos anulan los predeterminados. Un archivo .p11-kit con restricciones de propósito específicas anula la confianza general otorgada a un PEM simple en anchors/.

4. Los formatos de confianza en conflicto causan desconfianza. Si el mismo certificado (huella digital idéntica) aparece como BEGIN TRUSTED CERTIFICATE (o .p11-kit) y como BEGIN CERTIFICATE, la desconfianza ocurre en dos casos:

   • El BEGIN TRUSTED CERTIFICATE tiene usos rechazados explícitos — el rechazo contradice la confianza implícita total del PEM simple.
   • El BEGIN TRUSTED CERTIFICATE tiene atributos de confianza vacíos (ningún uso confiable, ningún uso rechazado) — p11-kit interpreta “ningún uso listado” como “confiable para nada”, lo que contradice el implícito “confiable para todos los propósitos” del PEM simple.

   En ambos casos, p11-kit marca el certificado como desconfiado.

Esta es la causa más común de desconfianza inesperada. Un administrador copia un archivo PEM simple en source/anchors/ sin darse cuenta de que el mismo certificado ya existe en ca-bundle.trust.p11-kit con atributos de uso rechazado o confianza vacía. El resultado: la CA queda desconfiada después de update-ca-trust, y los servicios que dependen de ella fallan silenciosamente.

Paso 4: Extraer a paquetes específicos por formato

p11-kit ejecuta comandos de extracción para cada formato de salida:

# Paquete PEM para TLS (el más comúnmente consumido)
p11-kit extract --format=pem-bundle \
    --filter=ca-anchors \
    --overwrite \
    --purpose=server-auth \
    /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

# Paquete PEM para correo (S/MIME)
p11-kit extract --format=pem-bundle \
    --filter=ca-anchors \
    --overwrite \
    --purpose=email-protection \
    /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem

# Paquete PEM para firma de código
p11-kit extract --format=pem-bundle \
    --filter=ca-anchors \
    --overwrite \
    --purpose=code-signing \
    /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem

# Formato "certificado confiable" de OpenSSL (incluye atributos de confianza/rechazo)
p11-kit extract --format=openssl-bundle \
    --filter=certificates \
    --overwrite \
    /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt

# Keystore de Java
p11-kit extract --format=java-cacerts \
    --filter=ca-anchors \
    --overwrite \
    --purpose=server-auth \
    /etc/pki/ca-trust/extracted/java/cacerts

# Formato UEFI EDK2
p11-kit extract --format=edk2-cacerts \
    --filter=ca-anchors \
    --overwrite \
    --purpose=server-auth \
    /etc/pki/ca-trust/extracted/edk2/cacerts.bin

Paso 5: Actualizar enlaces simbólicos de compatibilidad

El sistema mantiene enlaces simbólicos para que las rutas heredadas apunten a los paquetes extraídos:

/etc/pki/tls/certs/ca-bundle.crt → /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
/etc/pki/tls/certs/ca-bundle.trust.crt → /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
/etc/pki/java/cacerts → /etc/pki/ca-trust/extracted/java/cacerts

update-ca-trust vs update-ca-trust extract

Son funcionalmente idénticos. El script update-ca-trust acepta extract como subcomando, pero ejecutar update-ca-trust sin argumentos utiliza por defecto la acción extract. No hay diferencia en el comportamiento.

# Estos dos comandos producen resultados idénticos:
sudo update-ca-trust
sudo update-ca-trust extract

El subcomando extract existe para mayor explicitud en scripts y documentación. Históricamente, update-ca-trust también soportaba los subcomandos enable y disable (para alternar entre el nuevo almacén de confianza gestionado por p11-kit y el enfoque heredado de archivo plano), pero ya no son relevantes en sistemas RHEL modernos donde la gestión por p11-kit está siempre activa.

# Verificar estado actual (solo informativo en RHEL moderno)
update-ca-trust check

Verificar Qué Cambió

Después de ejecutar update-ca-trust, puedes verificar el resultado:

# Contar CAs confiables en el paquete PEM
grep -c '^-----BEGIN CERTIFICATE-----' /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

# Listar todas las CAs confiables vía p11-kit
trust list --filter=ca-anchors | grep "label:" | wc -l

# Verificar si una CA específica está presente
trust list | grep -A 4 "My Company CA"

6.4 Agregar Certificados CA Personalizados

Paso a Paso

# Paso 1: Copiar certificado CA (formato PEM o DER)
sudo cp company-ca.crt /etc/pki/ca-trust/source/anchors/

# Paso 2: Actualizar almacén de confianza
sudo update-ca-trust

# Paso 3: Verificar adición
trust list | grep -i "company"

# Paso 4: Probar
curl https://internal-server.example.com

Funciona idénticamente en RHEL 7, 8, 9, 10.

Agregar con Restricciones de Propósito

Si una CA solo debe ser confiable para autenticación de servidor TLS (no para firma de correo ni firma de código), usa el comando trust en lugar del enfoque simple de copia de archivos:

# Confiar solo para autenticación de servidor TLS
sudo trust anchor --store /path/to/company-ca.crt

# O con restricción de propósito explícita vía formato p11-kit
# Crear un archivo .p11-kit con confianza restringida:
cat > /tmp/company-ca.p11-kit <<'EOF'
[p11-kit-object-v1]
class: x-certificate-extension
label: "My Company CA"
x-public-key-info: <extracted-from-cert>

[p11-kit-object-v1]
class: certificate
label: "My Company CA"
certificate-type: x-509
java-midp-security-domain: 0
trusted: true
x-distrusted: false

[p11-kit-object-v1]
class: x-certificate-extension
label: "My Company CA"
object-id: 2.5.29.37
value: "%06%08%2b%06%01%05%05%07%03%01"
EOF

El comando trust anchor --store maneja esto automáticamente y es el enfoque recomendado en RHEL 8+.

6.5 Características del Almacén de Confianza por Versión de RHEL

Evolución de la Gestión de Confianza

Mejora RHEL 8+:

# Gestión avanzada de confianza (RHEL 8+)
trust anchor /path/to/ca.crt --purpose server-auth
trust anchor --remove "pkcs11:id=%CERT_ID%"
trust list --filter=ca-anchors

# Desconfiar de una CA comprometida
# RHEL 7/8:
sudo cp compromised.crt /etc/pki/ca-trust/source/blacklist/
# RHEL 9+:
sudo cp compromised.crt /etc/pki/ca-trust/source/blocklist/

sudo update-ca-trust

6.6 Certificados Duplicados: Qué Sucede y Cómo Manejarlos

Variantes de Formato PEM e Implicaciones de Confianza

Antes de discutir duplicados, es esencial entender los tres formatos de encabezado PEM que RHEL utiliza, porque el formato en sí lleva semántica de confianza:

Puedes inspeccionar los atributos de confianza embebidos en un archivo BEGIN TRUSTED CERTIFICATE:

# Mostrar los datos auxiliares de confianza
openssl x509 -in cert.crt -noout -text -trustout 2>/dev/null | grep -A 5 "Trusted Uses\|Rejected Uses"

Un archivo BEGIN TRUSTED CERTIFICATE con “Rejected Uses: TLS Web Server Authentication” y un archivo BEGIN CERTIFICATE para el mismo cert (que no lleva información de rechazo) son contradictorios desde la perspectiva de p11-kit.

Entender los Certificados “Duplicados”

Dos certificados pueden ser duplicados en diferentes niveles:

La distinción crítica: p11-kit identifica duplicados por contenido de certificado codificado en DER, no por campos de metadatos. Sin embargo, “coincidir” el contenido DER es solo la mitad de la historia — lo que sucede después depende enteramente de si los formatos de envoltura de confianza coinciden:

• Si los bytes DER crudos del certificado son idénticos y todas las fuentes coinciden en la disposición de confianza → deduplicado, confiable
• Si los bytes DER crudos del certificado son idénticos pero una fuente tiene OIDs de uso rechazado embebidos y la otra no → aserciones de confianza contradictorias → DESCONFIADO
• Si los bytes DER crudos del certificado son idénticos pero una fuente tiene BEGIN TRUSTED CERTIFICATE con atributos de confianza vacíos (ningún uso confiable, ningún uso rechazado) → p11-kit interpreta como “confiable para nada” → contradice confianza implícita total → DESCONFIADO
• Si los bytes DER crudos del certificado son idénticos y una fuente tiene BEGIN TRUSTED CERTIFICATE con solo usos confiables explícitos (sin usos rechazados) → certificado es aceptado con los propósitos de confianza especificados
• Si los bytes DER crudos del certificado difieren (incluso por un solo byte) → p11-kit los trata como certificados separados y ambos se incluyen

Escenario: Formatos de Confianza en Conflicto (Más Peligroso)

Este es el problema de “duplicados” más común y más dañino. Ocurre silenciosamente cuando un administrador copia un certificado en source/anchors/ sin darse cuenta de que el mismo certificado ya existe en el paquete del sistema con OIDs de uso rechazado o atributos de confianza vacíos en sus datos de confianza.

Ejemplo:

/usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit
  → Contiene "My Corp CA" como objeto de confianza p11-kit con atributos de confianza específicos
    INCLUYENDO usos rechazados (ej.: "Rejected Uses: TLS Web Server Authentication")
    O con atributos de confianza vacíos (ningún uso confiable, ningún uso rechazado listado)

/etc/pki/ca-trust/source/anchors/my-corp-ca.crt
  → Mismo "My Corp CA" como PEM simple (-----BEGIN CERTIFICATE-----)
    (sin atributos de confianza — depende de la ubicación del directorio para confianza implícita)

Resultado: El mismo contenido DER del certificado ahora tiene descripciones de confianza contradictorias. El objeto de confianza p11-kit o rechaza explícitamente ciertos usos, o no lista ningún uso (lo que p11-kit interpreta como “confiable para nada”). El PEM simple no lleva metadatos de confianza, implicando confianza para todos los propósitos. p11-kit no puede reconciliar estas contradicciones, y marca el certificado como desconfiado. Después de ejecutar update-ca-trust:

• El certificado desaparece de tls-ca-bundle.pem
• trust list lo muestra con trust: distrusted
• Todos los servicios que dependen de esta CA comienzan a fallar con certificate verify failed

Este mismo problema ocurre con el formato BEGIN TRUSTED CERTIFICATE de OpenSSL cuando contiene usos rechazados O confianza vacía:

/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
  → Contiene el certificado como -----BEGIN TRUSTED CERTIFICATE-----
    (con OIDs de "Rejected Uses" embebidos, O sin ningún uso confiable/rechazado listado)

/etc/pki/ca-trust/source/anchors/certificate.crt
  → Mismo certificado como -----BEGIN CERTIFICATE-----
    (sin datos embebidos de confianza — sin información de rechazo)

Resultado: Mismo desenlace — el rechazo o la confianza vacía en una fuente contradice la confianza implícita en la otra, certificado marcado como desconfiado.

Información clave: En un BEGIN TRUSTED CERTIFICATE, “ningún uso confiable/rechazado listado” NO significa “confiable para todos los propósitos.” Significa “confiable para nada.” Esta es la distinción crítica respecto a un BEGIN CERTIFICATE simple en anchors/, donde la ubicación en el directorio otorga confianza implícita total. Para depurar, busque certificados duplicados en /etc/pki/ca-trust/source/ y /usr/share/pki/ca-trust-source/ y verifique si existe algún BEGIN TRUSTED CERTIFICATE sin Reject o con confianza vacía que pueda conflictuar con una copia PEM simple.

Cómo solucionarlo:

# Opción 1: Eliminar el duplicado PEM simple de anchors/
sudo rm /etc/pki/ca-trust/source/anchors/my-corp-ca.crt
sudo update-ca-trust

# Opción 2: Si NECESITAS el cert en anchors/, conviértelo al
# formato confiable que coincida con los atributos de confianza existentes:
openssl x509 -in my-corp-ca.crt -addtrust serverAuth \
    -addtrust emailProtection -out my-corp-ca-trusted.crt
sudo cp my-corp-ca-trusted.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# Verificar la corrección
trust list --filter=ca-anchors | grep -A 3 "My Corp CA"

Escenario: Desconfianza Explícita

/usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit
  → Contiene "Legacy Corp CA" con confianza completa

/etc/pki/ca-trust/source/blacklist/legacy-corp-ca.crt    ← RHEL 7/8
/etc/pki/ca-trust/source/blocklist/legacy-corp-ca.crt    ← RHEL 9+
  → Mismo "Legacy Corp CA" como PEM simple, colocado en directorio de desconfianza

Resultado: La desconfianza prevalece por diseño. El certificado se excluye de tls-ca-bundle.pem y se marca como desconfiado en el paquete OpenSSL. Este es el comportamiento esperado cuando un administrador desconfía intencionalmente de una CA.

Escenario: Certificados Casi Idénticos (Diferente DER)

Un problema más sutil ocurre cuando dos certificados parecen iguales pero no son idénticos byte por byte:

• Un certificado CA fue descargado de dos fuentes diferentes con un ajuste de línea PEM ligeramente diferente
• Un certificado CA fue recodificado (PEM → DER → PEM) y obtuvo metadatos de encabezado diferentes
• Una CA fue reemitida con el mismo Subject DN pero un nuevo par de claves y número de serie

En estos casos, p11-kit los trata como certificados distintos, y ambos terminan en los paquetes extraídos. Esto puede causar:

• Salida confusa de trust list con aparentes duplicados
• Tamaño de paquete incrementado (problema cosmético)
• Confusión en la construcción de cadenas si una copia es desconfiada y la otra es confiable pero tienen diferente contenido DER

Cómo Detectar Certificados Duplicados

Método 1: Comparación de huella digital + formato

Extraer huellas digitales de todos los certificados fuente y buscar duplicados, incluyendo qué formato usa cada archivo:

# Escanear todos los directorios fuente por huellas SHA-256 duplicadas
# Y reportar el formato PEM de cada archivo
for dir in /usr/share/pki/ca-trust-source/anchors \
           /etc/pki/ca-trust/source/anchors; do
    for cert in "$dir"/*.crt "$dir"/*.pem 2>/dev/null; do
        [ -f "$cert" ] || continue
        fp=$(openssl x509 -in "$cert" -noout -fingerprint -sha256 2>/dev/null)
        fmt=$(head -1 "$cert" 2>/dev/null)
        [ -n "$fp" ] && echo "$fp  [$fmt]  $cert"
    done
done | sort

# Buscar la misma huella digital apareciendo con formatos diferentes:
# Si ves la misma huella digital tanto con "BEGIN CERTIFICATE" como con
# "BEGIN TRUSTED CERTIFICATE", esa es la fuente de un conflicto de confianza.

Si la misma huella digital aparece con encabezados PEM diferentes, has encontrado un conflicto de formato de confianza que causará desconfianza.

Método 2: Usar trust list para detectar duplicados

# Extraer todas las etiquetas y buscar duplicados
trust list --filter=ca-anchors | grep "^    label:" | sort | uniq -c | sort -rn | head -20

Si alguna etiqueta aparece más de una vez, investiga más:

# Mostrar detalles completos para un duplicado sospechoso
trust list | grep -B 2 -A 10 "label: DigiCert Global Root G2"

Método 3: Comparar el paquete extraído contra archivos fuente

# Contar certificados en el paquete PEM
grep -c 'BEGIN CERTIFICATE' /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

# Contar certificados únicos por huella digital
awk '/BEGIN CERT/,/END CERT/' /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem | \
    csplit -z -f /tmp/cert- - '/BEGIN CERTIFICATE/' '{*}' 2>/dev/null
for f in /tmp/cert-*; do
    openssl x509 -in "$f" -noout -fingerprint -sha256 2>/dev/null
done | sort -u | wc -l
rm -f /tmp/cert-*

Si el conteo de certificados excede el conteo de huellas únicas, existen duplicados en el paquete extraído.

Cómo Identificar Diferencias Entre Duplicados Sospechosos

Cuando tienes dos archivos de certificado que parecen ser la misma CA, compáralos en cuatro niveles:

Nivel 1: Verificar el formato PEM (causa más común de conflictos)

# Verificar qué encabezado PEM usa cada archivo
head -1 cert1.crt
head -1 cert2.crt

# "-----BEGIN CERTIFICATE-----"         → PEM simple, sin datos de confianza
# "-----BEGIN TRUSTED CERTIFICATE-----" → formato confiable de OpenSSL, TIENE datos de confianza

Si uno dice BEGIN CERTIFICATE y el otro dice BEGIN TRUSTED CERTIFICATE, has encontrado el problema. Causarán un conflicto de confianza incluso si el certificado subyacente es idéntico.

Nivel 2: Comparar contenido de certificado codificado en DER

# Comparar contenido codificado en DER (elimina encabezados PEM, diferencias de espaciado)
openssl x509 -in cert1.crt -outform DER -out /tmp/cert1.der
openssl x509 -in cert2.crt -outform DER -out /tmp/cert2.der
diff /tmp/cert1.der /tmp/cert2.der && echo "DER IDÉNTICO" || echo "DER DIFERENTE"

Nivel 3: Comparar campos del certificado

# Comparar subject, issuer, serial, validez y clave
for field in subject issuer serial dates fingerprint pubkey; do
    echo "=== $field ==="
    echo "cert1: $(openssl x509 -in cert1.crt -noout -$field 2>/dev/null)"
    echo "cert2: $(openssl x509 -in cert2.crt -noout -$field 2>/dev/null)"
done

Nivel 4: Comparar atributos de confianza embebidos (si es formato TRUSTED CERTIFICATE)

# Mostrar atributos de confianza para cada archivo
echo "=== atributos de confianza cert1 ==="
openssl x509 -in cert1.crt -noout -text -trustout 2>/dev/null | grep -A 5 "Trusted Uses\|Rejected Uses"
echo "=== atributos de confianza cert2 ==="
openssl x509 -in cert2.crt -noout -text -trustout 2>/dev/null | grep -A 5 "Trusted Uses\|Rejected Uses"

Hallazgos comunes:

Limpiar Duplicados

Si el certificado ya está en el paquete del sistema (caso más común):

Un certificado en anchors/ que ya existe en ca-bundle.trust.p11-kit no siempre es inofensivo — si la copia en el paquete del sistema tiene OIDs de uso rechazado o atributos de confianza vacíos, el duplicado PEM simple causa desconfianza. Siempre verifica los atributos de confianza antes de asumir que un duplicado es benigno.

# 1. Verificar el formato del archivo en anchors/
head -1 /etc/pki/ca-trust/source/anchors/suspect.crt

# 2. Encontrar la huella digital
openssl x509 -in /etc/pki/ca-trust/source/anchors/suspect.crt -noout -fingerprint -sha256

# 3. Verificar si ese certificado existe en el paquete del sistema
trust list | grep -B5 -A5 "<subject del cert>"

# 4. Si el certificado ya existe en el paquete del sistema con atributos
#    de confianza apropiados, eliminar el duplicado de anchors/:
sudo rm /etc/pki/ca-trust/source/anchors/suspect.crt
sudo update-ca-trust

# 5. Verificar que el certificado ahora es confiable (no desconfiado)
trust list --filter=ca-anchors | grep -A 3 "<subject del cert>"

Si necesitas mantener el certificado en anchors/ (CA personalizada no en el paquete del sistema):

# Asegurar que el formato del archivo coincide con lo que p11-kit espera.
# Para CAs personalizadas no en el paquete del sistema, PEM simple está bien:
openssl x509 -in suspect.crt -out /etc/pki/ca-trust/source/anchors/suspect.crt
sudo update-ca-trust

6.7 Usar trust list para Identificar Certificados Desconfiados

El comando trust list es la herramienta principal para inspeccionar el estado del almacén de confianza después de ejecutar update-ca-trust.

Uso Básico

# Listar todos los objetos de confianza (confiables + desconfiados)
trust list

# Listar solo anclas de CA confiables
trust list --filter=ca-anchors

# Listar solo certificados desconfiados
trust list --filter=blacklist     # RHEL 7/8
trust list --filter=blocklist     # RHEL 9+

# Listar todos los certificados (sin filtrar por disposición de confianza)
trust list --filter=certificates

Anatomía de la Salida de trust list

Cada entrada en la salida de trust list se ve así:

pkcs11:id=%DE%28%F4%A4%FF%E5%B9%2F%A3%C5%03%D1%A3%49%A7%F9%96%2A%82%12;type=cert
    type: certificate
    label: DigiCert Global Root G2
    trust: anchor
    category: authority

pkcs11:id=%01%02%03...;type=cert
    type: certificate
    label: Legacy Compromised CA
    trust: distrusted
    category: authority

Encontrar Certificados Desconfiados

# Listar todos los certificados desconfiados con sus etiquetas
trust list --filter=blacklist     # RHEL 7/8
trust list --filter=blocklist     # RHEL 9+

# Contar certificados desconfiados
trust list --filter=blocklist | grep "^pkcs11:" | wc -l    # RHEL 9+

# Buscar un certificado desconfiado específico
trust list --filter=blocklist | grep -B 1 -A 4 "Symantec"  # RHEL 9+

Rastrear un Certificado Desconfiado Hasta su Origen

Cuando trust list --filter=blacklist (RHEL 7/8) o trust list --filter=blocklist (RHEL 9+) muestra un certificado que no esperabas que estuviera desconfiado, necesitas encontrar dónde se origina la desconfianza:

# Paso 1: Obtener la etiqueta del certificado desconfiado
trust list --filter=blacklist     # RHEL 7/8
trust list --filter=blocklist     # RHEL 9+
# Ejemplo de salida:
# pkcs11:id=%AB%CD...;type=cert
#     type: certificate
#     label: Suspicious CA
#     trust: distrusted
#     category: authority

# Paso 2: Verificar directorio de desconfianza del administrador
# RHEL 7/8: blacklist/  |  RHEL 9+: blocklist/
for distrust_dir in /etc/pki/ca-trust/source/blacklist \
                    /etc/pki/ca-trust/source/blocklist; do
    [ -d "$distrust_dir" ] || continue
    echo "=== $distrust_dir ==="
    ls -la "$distrust_dir"/
    for f in "$distrust_dir"/*; do
        [ -f "$f" ] || continue
        subj=$(openssl x509 -in "$f" -noout -subject 2>/dev/null)
        echo "$f: $subj"
    done
done

# Paso 3: Verificar directorio de desconfianza provisto por paquetes
for distrust_dir in /usr/share/pki/ca-trust-source/blacklist \
                    /usr/share/pki/ca-trust-source/blocklist; do
    [ -d "$distrust_dir" ] || continue
    echo "=== $distrust_dir ==="
    ls -la "$distrust_dir"/
    for f in "$distrust_dir"/*; do
        [ -f "$f" ] || continue
        subj=$(openssl x509 -in "$f" -noout -subject 2>/dev/null)
        echo "$f: $subj"
    done
done

# Paso 4: Verificar atributos de desconfianza en el paquete principal p11-kit
grep -A 5 "Suspicious CA" /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit
# Buscar "x-distrusted: true" o "nss-mozilla-ca-policy: false"

Interpretación de resultados:

Ejemplo Práctico: Depurar una CA Desconfiada

Un servicio falla con certificate verify failed y sospechas que la CA fue desconfiada:

# 1. Identificar la CA desde el certificado fallido
openssl x509 -in /etc/pki/tls/certs/server.crt -noout -issuer
# issuer=CN = Internal Corp CA, O = CorpCo

# 2. Verificar si el emisor es confiable
trust list --filter=ca-anchors | grep -A 3 "Internal Corp CA"
# Sin salida significa que NO está en las anclas confiables

# 3. Verificar si está activamente desconfiado
trust list --filter=blacklist | grep -A 3 "Internal Corp CA"   # RHEL 7/8
trust list --filter=blocklist | grep -A 3 "Internal Corp CA"   # RHEL 9+
# Si se encuentra aquí, la CA está explícitamente desconfiada

# 4. Verificar si está presente de alguna forma
trust list | grep -A 3 "Internal Corp CA"
# Si no se encuentra en ningún lado, nunca fue agregada al almacén de confianza

# 5. Si está desconfiada, encontrar el archivo fuente (verifica rutas de RHEL 7/8 y 9+)
find /etc/pki/ca-trust/source/blacklist/ \
     /etc/pki/ca-trust/source/blocklist/ \
     /usr/share/pki/ca-trust-source/blacklist/ \
     /usr/share/pki/ca-trust-source/blocklist/ \
     -type f 2>/dev/null | while read f; do
    if openssl x509 -in "$f" -noout -subject 2>/dev/null | grep -qi "Internal Corp CA"; then
        echo "ENCONTRADO: $f"
    fi
done

# 6. Si NO se encuentra en ningún directorio de desconfianza, verificar conflictos de formato de confianza:
#    buscar un PEM simple en anchors/ que duplique un cert en el paquete del sistema
for f in /etc/pki/ca-trust/source/anchors/*; do
    [ -f "$f" ] || continue
    if openssl x509 -in "$f" -noout -subject 2>/dev/null | grep -qi "Internal Corp CA"; then
        echo "DUPLICADO EN ANCHORS: $f"
        echo "  Formato: $(head -1 "$f")"
        echo "  Verificar si el mismo cert existe en ca-bundle.trust.p11-kit con formato de confianza diferente"
    fi
done

# 7. También verificar el paquete principal p11-kit
grep -B 2 -A 10 "Internal Corp CA" \
    /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit

Restaurar Confianza de un Certificado Desconfiado

Si determinas que un certificado fue incorrectamente desconfiado:

# Si la entrada de desconfianza está en /etc/pki/ (gestionada por el administrador)
# RHEL 7/8:
sudo rm /etc/pki/ca-trust/source/blacklist/the-cert.crt
# RHEL 9+:
sudo rm /etc/pki/ca-trust/source/blocklist/the-cert.crt

sudo update-ca-trust

# Si la desconfianza proviene del paquete ca-certificates, necesitas
# anularla agregando el certificado como ancla confiable:
sudo cp the-cert.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust
# Nota: esto funciona porque las anclas del administrador anulan la desconfianza
# a nivel de paquete para certificados que coinciden por contenido DER.

# Verificar que el certificado ahora es confiable
trust list --filter=ca-anchors | grep -A 3 "The Cert Label"

Advertencia: Anular una decisión de desconfianza de Mozilla/Red Hat solo debe hacerse si tienes una razón de negocio específica y comprendes las implicaciones de seguridad. Las CAs son desconfiadas por causa (compromiso, emisión incorrecta, violaciones de políticas).

6.8 Depuración Avanzada con trust y p11-kit

Inspeccionar Objetos de Confianza Individuales

# Volcar los atributos PKCS#11 completos para un certificado específico
trust dump --filter="pkcs11:id=%DE%28%F4%A4..." 

# Listar todos los atributos de todos los objetos de confianza (verboso, salida extensa)
trust dump

Verificar la Cadena de Extracción

Si sospechas que update-ca-trust no está produciendo la salida esperada:

# Ejecutar la extracción manualmente con salida detallada
p11-kit extract --format=pem-bundle \
    --filter=ca-anchors \
    --purpose=server-auth \
    /tmp/test-tls-bundle.pem

# Comparar con el paquete del sistema
diff <(sort /tmp/test-tls-bundle.pem) \
     <(sort /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem)

# Ejecutar con registro de depuración de p11-kit
P11_KIT_DEBUG=all update-ca-trust 2>&1 | head -100

Verificar Completitud de la Cadena de Certificados

# Verificar un certificado de servidor contra el almacén de confianza del sistema
openssl verify -CAfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem server.crt

# Si la cadena tiene intermedios, inclúyelos:
openssl verify -CAfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem \
    -untrusted intermediate.crt server.crt

# Mostrar la cadena completa que OpenSSL construiría:
openssl verify -show_chain -CAfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem server.crt

Verificación Cruzada del Paquete OpenSSL

El formato “certificado confiable” de OpenSSL (ca-bundle.trust.crt) incluye atributos embebidos de confianza/rechazo que son distintos del paquete PEM simple. Puedes inspeccionarlos:

# Mostrar atributos de confianza para certificados en el paquete OpenSSL
openssl x509 -in /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt \
    -noout -text -trustout 2>/dev/null | grep -A 2 "Trusted Uses\|Rejected Uses"

Verificar el Keystore de Java

# Listar todas las entradas en el almacén de confianza de Java
keytool -list -cacerts -storepass changeit 2>/dev/null | grep "trustedCertEntry" | wc -l

# Buscar una CA específica
keytool -list -cacerts -storepass changeit 2>/dev/null | grep -i "company"

6.9 Resolver Problemas de Confianza

Enfoque Sistemático

Síntoma: Falló la verificación del certificado

Paso 1: Identificar qué certificado está fallando y quién lo emitió

# Obtener la cadena del emisor desde un servidor remoto
openssl s_client -connect server.example.com:443 -showcerts </dev/null 2>/dev/null | \
    openssl x509 -noout -issuer -subject

# O desde un archivo de certificado local
openssl x509 -in server.crt -noout -issuer -subject -serial

Paso 2: Verificar si la CA emisora está en el almacén de confianza

trust list --filter=ca-anchors | grep -i "ISSUER_CN_HERE"

Paso 3: Verificar si la CA emisora está desconfiada

trust list --filter=blacklist | grep -i "ISSUER_CN_HERE"    # RHEL 7/8
trust list --filter=blocklist | grep -i "ISSUER_CN_HERE"    # RHEL 9+

Paso 4: Si falta, agregarla

sudo cp issuer-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Paso 5: Si está desconfiada, encontrar el origen y decidir la acción

# Rastrear el origen de la desconfianza (ver Sección 6.7)
# Verifica rutas de RHEL 7/8 (blacklist) y RHEL 9+ (blocklist)
find /etc/pki/ca-trust/source/blacklist/ \
     /etc/pki/ca-trust/source/blocklist/ \
     /usr/share/pki/ca-trust-source/blacklist/ \
     /usr/share/pki/ca-trust-source/blocklist/ \
     -name '*.crt' -o -name '*.pem' 2>/dev/null | while read f; do
    openssl x509 -in "$f" -noout -subject 2>/dev/null
done

Problemas Comunes del Almacén de Confianza

Referencia Rápida

┌────────────────────────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA DEL ALMACÉN DE CONFIANZA DE RHEL                             │
├────────────────────────────────────────────────────────────────────────────────┤
│                                                                                │
│  Agregar CA:    sudo cp ca.crt /etc/pki/ca-trust/source/anchors/               │
│                 sudo update-ca-trust                                           │
│                                                                                │
│  Desconfiar:    sudo cp bad.crt /etc/pki/ca-trust/source/blacklist/            │
│                 (RHEL 7/8) o .../source/blocklist/ (RHEL 9+)                   │
│                 sudo update-ca-trust                                           │
│                                                                                │
│  Verificar:     trust list --filter=ca-anchors | grep "Nombre CA"              │
│                 openssl verify -CAfile /etc/pki/ca-trust/extracted/            │
│                     pem/tls-ca-bundle.pem cert.crt                             │
│                                                                                │
│  Desconfiados:  trust list --filter=blacklist  (RHEL 7/8)                      │
│                 trust list --filter=blocklist  (RHEL 9+)                       │
│                                                                                │
│  Duplicados:    trust list --filter=ca-anchors | grep "label:" |               │
│                     sort | uniq -c | sort -rn                                  │
│                                                                                │
│  Comparar:      openssl x509 -in a.crt -outform DER | sha256sum                │
│                 openssl x509 -in b.crt -outform DER | sha256sum                │
│                                                                                │
│  Depurar:       P11_KIT_DEBUG=all update-ca-trust 2>&1                         │
│                                                                                │
│  Dirs fuente:   /etc/pki/ca-trust/source/{anchors,blacklist|blocklist}/        │
│                 /usr/share/pki/ca-trust-source/{anchors,blacklist|blocklist}/  │
│                                                                                │
│  Extraídos:     /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem              │
│                 /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt        │
│                 /etc/pki/ca-trust/extracted/java/cacerts                       │
│                                                                                │
│  Pipeline:      update-ca-trust = update-ca-trust extract (idénticos)          │
│                                                                                │
│  Prioridad:     blacklist/blocklist > anchors                                  │
│                 /etc/pki/ > /usr/share/pki/                                    │
│                 atributos .p11-kit > PEM simple predeterminado                 │
│                                                                                │
│  PELIGRO:       Nunca agregar un PEM simple "BEGIN CERTIFICATE" a              │
│                 anchors/ si el mismo cert ya existe en el paquete del          │
│                 sistema como "BEGIN TRUSTED CERTIFICATE" o formato             │
│                 .p11-kit. Confianza vacía (sin usos) = "confiable para         │
│                 nada" = DESCONFIADO. Usos rechazados + PEM simple →            │
│                 también DESCONFIADO.                                           │
└────────────────────────────────────────────────────────────────────────────────┘

🧪 Laboratorio Práctico

Lab 05: Gestión del Almacén de Confianza

Agrega CAs personalizadas al almacén de confianza del sistema, gestiona atributos de confianza, detecta duplicados y depura certificados desconfiados.

• 📁 Ubicación: labs/es_ES/05-trust-store/
• ⏱️ Tiempo: 45 minutos
• 🎯 Nivel: Intermedio

Navegación del Capítulo

Capítulo 7: Firmas Digitales y Verificación en RHEL

Cómo Funciona la Confianza: Aprende cómo las firmas digitales habilitan la validación de certificados en sistemas RHEL.

7.1 Funciones Hash Criptográficas

Propiedades:

1. Deterministas
2. Resistencia a preimagen
3. Resistencia a colisiones
4. Efecto avalancha

Algoritmos populares: SHA-256, SHA-3, BLAKE2.

7.2 Construir Firmas

1. Calcular hash del mensaje.
2. Cifrar hash con clave privada → firma.
3. El receptor descifra la firma con clave pública y compara con su propio hash.

7.3 Huellas de Certificados

Una huella es simplemente el hash del certificado codificado en DER, usado para identificarlo únicamente, ej.:

openssl x509 -in server.crt -noout -fingerprint -sha256

7.4 Laboratorio: Firmar y Verificar un Archivo

# firmar
openssl dgst -sha256 -sign rsa.key.pem -out report.sig report.pdf
# verificar
openssl dgst -sha256 -verify rsa.pub.pem -signature report.sig report.pdf

7.5 Resumen

Las firmas vinculan datos a identidades; los hashes aseguran integridad. Juntos sustentan la validación de certificados y todas las operaciones PKI.

7.6 Algoritmos de Firma en RHEL

Aprobados por Versión de RHEL

Crítico: ¡RHEL 9+ bloquea SHA-1 y MD5 por seguridad!

Verificar Certificados en RHEL

# Verificar cadena de certificado
openssl verify /etc/pki/tls/certs/server.crt

# Verificar contra CA específica
openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt server.crt

# Verificar algoritmo de firma
openssl x509 -in server.crt -noout -text | grep "Signature Algorithm"
# Debe ser SHA-256+ en RHEL 8+

Referencia Rápida

┌─────────────────────────────────────────────────────────────┐
│ FIRMAS DIGITALES EN RHEL                                    │
├─────────────────────────────────────────────────────────────┤
│ Propósito:       Probar autenticidad e integridad           │
│ Cómo:            Hash + Clave privada = Firma               │
│ Verificar:       Firma + Clave pública = Hash original      │
│                                                             │
│ Aprobados:       SHA-256, SHA-384, SHA-512                  │
│ Obsoleto:        SHA-1 (bloqueado en RHEL 9+)               │
│ Bloqueado:       MD5 (bloqueado en RHEL 9+)                 │
│                                                             │
│ Verificar cert:  openssl verify cert.crt                    │
│ Ver algoritmo:   openssl x509 -noout -text | grep Signature │
│ Huella:          openssl x509 -noout -fingerprint -sha256   │
└─────────────────────────────────────────────────────────────┘

🧪 Laboratorio Práctico

Lab 03: Firmas Digitales

Firma archivos, verifica firmas y detecta manipulaciones

• 📁 Ubicación: labs/es_ES/03-digital-signatures/
• ⏱️ Tiempo: 20 minutos
• 🎯 Nivel: Principiante

Navegación del Capítulo

Capítulo 8: Versiones de RHEL y Evolución de Certificados

Objetivo de Aprendizaje: Entender cómo difiere la gestión de certificados entre RHEL 7, 8, 9 y 10 para que puedas identificar rápidamente comportamientos específicos de versión al resolver problemas.

8.1 Por Qué Importa la Versión de RHEL

Al resolver problemas de certificados en RHEL, la primera pregunta siempre debe ser: “¿En qué versión de RHEL estoy?”

La gestión de certificados ha evolucionado significativamente a través de las versiones de RHEL. Lo que funciona en RHEL 7 puede fallar en RHEL 9. Entender estas diferencias es crucial para:

• ✅ Elegir el enfoque de solución de problemas correcto
• ✅ Identificar errores específicos de versión
• ✅ Planificar migraciones
• ✅ Escribir scripts de automatización compatibles

8.2 Verificación Rápida de Versión

# Método 1: Verificar /etc/redhat-release
cat /etc/redhat-release
# Ejemplos de salida:
#   Red Hat Enterprise Linux Server release 7.9 (Maipo)
#   Red Hat Enterprise Linux release 8.10 (Ootpa)
#   Red Hat Enterprise Linux release 9.8 (Plow)
#   Red Hat Enterprise Linux release 10.2 (Coughlan)

# Método 2: Usar rpm
rpm -q --queryformat '%{VERSION}\n' redhat-release

# Método 3: Verificar versión de OpenSSL (indirecto pero útil)
openssl version
# RHEL 7: OpenSSL 1.0.2k
# RHEL 8: OpenSSL 1.1.1k
# RHEL 9: OpenSSL 3.5.5
# RHEL 10: OpenSSL 3.5.5

8.3 Resumen de Versiones RHEL

Fuente: Ciclo de Vida de Productos Red Hat

8.4 Resumen de Diferencias Principales

RHEL 7 (Legado)

Características:

• ✅ Estable, bien entendido
• ✅ Máxima compatibilidad
• ⚠️ TLS 1.0/1.1 habilitado por defecto
• ⚠️ Cifrados débiles permitidos
• ⚠️ Gestión de certificados manual

Paquete: openssl-1.0.2k-26.el7_9.x86_64

Cuándo lo Verás:

• Sistemas legacy no migrados aún
• Aplicaciones que requieren versiones TLS antiguas
• Entornos conservadores

Comando Clave:

# Generar clave (estilo RHEL 7)
openssl genrsa -out server.key 2048

RHEL 8 (Estándar Empresarial Actual)

Características:

• ✅ Crypto-policies en todo el sistema (¡cambio de juego!)
• ✅ TLS 1.2+ por defecto
• ✅ certmonger para renovación automática
• ✅ Suites de cifrado modernas
• ⚠️ Cambios incompatibles con RHEL 7

Paquete: openssl-1.1.1k-14.el8_6.x86_64

Innovación Clave - Crypto-Policies:

# Ver política actual
update-crypto-policies --show
# DEFAULT, LEGACY, FUTURE, o FIPS

# ¡Control de seguridad en todo el sistema!
sudo update-crypto-policies --set FUTURE

Cuándo lo Verás:

• La mayoría de despliegues empresariales
• Aplicaciones modernas
• Entornos FreeIPA

Comando Clave:

# Generar clave (estilo moderno RHEL 8)
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out server.key

RHEL 9 (Estándar Moderno)

Características:

• ✅ OpenSSL 3.5.5 con arquitectura de proveedores
• ✅ TLS 1.2+ obligatorio
• ✅ Crypto-policies mejoradas
• ✅ Validación de certificados más estricta
• ⚠️ Cambios en API de OpenSSL 3.x
• ⚠️ Algoritmos legacy deshabilitados

Paquete: openssl-3.5.5-2.el9_8.x86_64

Cambio Mayor - Arquitectura de Proveedores:

# Listar proveedores crypto
openssl list -providers
# default, fips, legacy, base

# Algoritmos legacy requieren proveedor explícito
openssl md5 -provider legacy file.txt

Cuándo lo Verás:

• Nuevos despliegues
• Entornos conscientes de seguridad
• Últimas versiones de aplicaciones

Comando Clave:

# Generar clave EC (RHEL 9)
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ec.key

RHEL 10 (Lanzamiento Actual)

Características:

• ✅ Mismo OpenSSL 3.5.5 que RHEL 9.8
• ✅ Fortalecimiento de seguridad continuo
• ✅ Preparación para criptografía post-cuántica
• ✅ Soporte mejorado de certificados para contenedores
• ⚠️ Valores predeterminados aún más estrictos
• ⚠️ Eliminaciones legacy adicionales

Paquete: openssl-3.5.5-2.el10_2.x86_64

Nota: RHEL 10.0 GA fue el 20 de mayo de 2025. Las características y capacidades pueden evolucionar a través de versiones menores (10.1, 10.2, etc.). Siempre consulta la documentación oficial para tu lanzamiento específico de RHEL 10.x.

Enfoque Clave:

• Base de criptografía resistente a cuántica
• Prácticas de seguridad modernas
• Cargas de trabajo nativas de contenedor y nube

Cuándo lo Verás:

• Despliegues completamente nuevos
• Requisitos de seguridad de vanguardia
• Iniciativas de preparación para el futuro

8.5 Diferencias Críticas de Versión

Soporte de Versiones TLS

Disponibilidad de Herramientas de Certificados

Cambios Clave en Cifrado/Algoritmos

8.6 Problemas Comunes Específicos de Versión

Problemas RHEL 7

# Problema: Suites de cifrado antiguas aceptadas
# Impacto: Vulnerabilidades de seguridad
# Solución: Configuración manual de cifrados Apache/NGINX

Problemas RHEL 8

# Problema: La aplicación falla después de migración desde RHEL 7
# Razón: TLS 1.0/1.1 deshabilitado por defecto
# Solución Rápida: Usar temporalmente política LEGACY (no recomendado a largo plazo)
sudo update-crypto-policies --set LEGACY

# Mejor Solución: Actualizar aplicación para soportar TLS 1.2+

Problemas RHEL 9

# Problema: Comandos OpenSSL fallan con errores de proveedor
# Razón: Arquitectura de proveedores OpenSSL 3.x
# Solución: Especificar proveedor explícitamente
openssl md5 -provider legacy file.txt

# Problema: Certificados SHA-1 rechazados
# Razón: Validación más estricta
# Solución: Reemitir certificados con SHA-256+

Problemas RHEL 10

# Problema: Valores predeterminados aún más estrictos que RHEL 9
# Impacto: Certificados legacy pueden fallar validación
# Solución: Asegurar que todos los certificados usen algoritmos modernos
#           Verificar documentación específica de RHEL 10.x para tu versión menor

8.7 Impacto de Migración

RHEL 7 → RHEL 8

Impacto en Certificados: MODERADO

• TLS 1.0/1.1 deshabilitado
• Cifrados débiles eliminados
• Integración certmonger requerida para automatización

Acción Requerida:

1. Auditar versiones TLS en uso
2. Actualizar configuraciones de cifrado
3. Probar aplicaciones con TLS 1.2+
4. Considerar crypto-policies

RHEL 8 → RHEL 9

Impacto en Certificados: ALTO

• Cambios en API de OpenSSL 3.x
• Eliminación de algoritmos legacy
• Validación de certificados más estricta
• Cambios en arquitectura de proveedores

Acción Requerida:

1. Probar todas las operaciones de certificados
2. Actualizar scripts personalizados usando OpenSSL
3. Validar integridad de cadena de certificados
4. Verificar uso de SHA-1

RHEL 9 → RHEL 10

Impacto en Certificados: BAJO-MODERADO

• Misma base OpenSSL (3.5.5)
• Fortalecimiento incremental
• Refinamientos de política

Acción Requerida:

1. Revisar documentación de RHEL 10.x
2. Probar compatibilidad de crypto-policy
3. Validar uso de algoritmos modernos

8.8 Elegir el Enfoque Correcto

Para Solución de Problemas

# Siempre comenzar con verificación de versión
cat /etc/redhat-release

# Luego verificar versión de OpenSSL
openssl version

# Para RHEL 8+: Verificar crypto-policy
update-crypto-policies --show 2>/dev/null || echo "Pre-RHEL 8"

Árbol de Decisión de Referencia Rápida

¿Es RHEL 7?
├─ SÍ → Verificar problemas de TLS/cifrado legacy
│       Probablemente se necesita configuración manual
│       Considerar planificación de migración
│
└─ NO → ¿Es RHEL 8?
    ├─ SÍ → ¡Verificar crypto-policies primero!
    │       Usar certmonger para automatización
    │       Considerar actualización a RHEL 9
    │
    └─ NO → ¿Es RHEL 9 o 10?
        └─ SÍ → Verificar problemas de proveedor OpenSSL 3.x
                Verificar algoritmos modernos en uso
                Aprovechar herramientas mejoradas

8.9 Conclusiones Clave

1. Siempre verificar versión RHEL primero al resolver problemas
2. RHEL 8 introdujo crypto-policies - cambio de juego para gestión de certificados
3. RHEL 9 usa OpenSSL 3.x - cambios significativos en API y comportamiento
4. RHEL 10 continúa la base de RHEL 9 - mejoras incrementales
5. Algoritmos legacy eliminados progresivamente a través de versiones
6. Las pruebas de migración son críticas - el comportamiento de certificados cambia significativamente

8.10 ¿Qué Sigue?

Ahora que entiendes las diferencias de versiones RHEL, profundizaremos en:

• Capítulo 9: Gestión de Certificados en RHEL 7 (detallado)
• Capítulo 10: RHEL 8 y Crypto-Policies (detallado)
• Capítulo 11: Seguridad Moderna en RHEL 9 (detallado)
• Capítulo 12: Características Actuales de RHEL 10 (detallado)

Tarjeta de Referencia Rápida

┌────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA DE VERSIONES RHEL                        │
├─────────────┬───────────┬──────────────┬───────────────────┤
│ RHEL 7      │ 1.0.2k    │ Manual       │ Amigable legacy   │
│ RHEL 8      │ 1.1.1k    │ Crypto-pols  │ Estándar empresa  │
│ RHEL 9      │ 3.5.5     │ OpenSSL 3.x  │ Moderno seguro    │
│ RHEL 10     │ 3.5.5     │ Fortalecido  │ Preparado futuro  │
└─────────────┴───────────┴──────────────┴───────────────────┘

Verificar versión:   cat /etc/redhat-release
Verificar OpenSSL:   openssl version
Verificar política:  update-crypto-policies --show  (RHEL 8+)

Navegación del Capítulo

Capítulo 9: Gestión de Certificados en RHEL 7

Legado pero Importante: RHEL 7 alcanzó el fin de mantenimiento en junio de 2024, pero muchas empresas aún lo ejecutan. Aprende cómo funciona la gestión de certificados en RHEL 7.

9.1 Resumen de RHEL 7

Lanzamiento: 10 de junio de 2014 Fin de Soporte de Mantenimiento: 30 de junio de 2024 Soporte de Ciclo de Vida Extendido: Disponible hasta 2028

Características Clave:

• Versión OpenSSL: 1.0.2k-26 (paquete: openssl-1.0.2k-26.el7_9.x86_64)
• TLS Por Defecto: TLS 1.0, 1.1, 1.2 todos habilitados
• Almacén de Confianza: /etc/pki/ca-trust/extracted/
• Enfoque de Gestión: Principalmente manual
• Crypto-Policies: No disponible (característica de RHEL 8+)

Nota: Si aún estás en RHEL 7, planifica la migración a RHEL 8 o 9. Las actualizaciones de seguridad son limitadas.

9.2 Especificaciones de OpenSSL 1.0.2k

Verificación de Versión

# Verificar versión de OpenSSL en RHEL 7
openssl version
# OpenSSL 1.0.2k-fips  12 Jan 2017

# Verificar paquete
rpm -q openssl
# openssl-1.0.2k-26.el7_9.x86_64

Características y Limitaciones Clave

Características:

• ✅ Soporte TLS 1.0, 1.1, 1.2
• ✅ Estable y bien probado
• ✅ Amplia compatibilidad
• ✅ Tipos de clave RSA, ECC, DSA

Limitaciones:

• ❌ Sin soporte TLS 1.3
• ❌ Sintaxis de comando antigua (genrsa vs genpkey)
• ❌ Cifrados predeterminados más débiles
• ❌ Suites de cifrado modernas limitadas

Sintaxis de Comandos (Estilo RHEL 7)

#============================================#
# GENERAR CLAVE RSA (RHEL 7)
#============================================#

# Estilo antiguo (común en RHEL 7)
openssl genrsa -out server.key 2048

# Con protección de frase de contraseña
openssl genrsa -aes256 -out server.key 2048

# Eliminar frase de contraseña de clave
openssl rsa -in server.key -out server-nopass.key


#============================================#
# GENERAR CSR (RHEL 7)
#============================================#

# CSR básico
openssl req -new -key server.key -out server.csr

# Con sujeto especificado
openssl req -new -key server.key -out server.csr \
  -subj "/C=US/ST=State/L=City/O=Company/CN=server.example.com"

# ⚠️ Nota: Los SANs son más difíciles de agregar con OpenSSL de RHEL 7
# Se necesita archivo de configuración para SANs


#============================================#
# VER CERTIFICADO
#============================================#

# Detalles completos
openssl x509 -in server.crt -noout -text

# Solo expiración
openssl x509 -in server.crt -noout -dates

# Solo sujeto
openssl x509 -in server.crt -noout -subject

9.3 Gestión del Almacén de Confianza en RHEL 7

Agregar CAs Personalizadas

#============================================#
# AGREGAR CA PERSONALIZADA (RHEL 7)
#============================================#

# Paso 1: Copiar certificado CA al directorio de anchors
sudo cp corporate-ca.crt /etc/pki/ca-trust/source/anchors/

# Paso 2: Actualizar almacén de confianza
sudo update-ca-trust extract

# Paso 3: Verificar
trust list | grep -i "corporate"

# Verificar que las aplicaciones lo usen
openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt test-cert.crt

Ubicaciones del Almacén de Confianza (RHEL 7)

/etc/pki/ca-trust/
├── source/
│   └── anchors/                   ← Agregar CAs personalizadas aquí
│
└── extracted/
    ├── pem/
    │   └── tls-ca-bundle.pem      ← OpenSSL, Python, Ruby
    ├── openssl/
    │   └── ca-bundle.trust.crt    ← Específico de OpenSSL
    └── java/
        └── cacerts                ← Aplicaciones Java

9.4 Configuración de Servicios (Enfoque RHEL 7)

Apache HTTPS en RHEL 7

#============================================#
# CONFIGURACIÓN SSL/TLS DE APACHE (RHEL 7)
#============================================#

# Instalar Apache con SSL
sudo yum install httpd mod_ssl -y

# Generar certificado y clave
sudo openssl genrsa -out /etc/pki/tls/private/server.key 2048
sudo openssl req -new -key /etc/pki/tls/private/server.key \
  -out /tmp/server.csr \
  -subj "/CN=$(hostname -f)"

# Obtener certificado de CA (o autofirmado para pruebas)
sudo openssl x509 -req -days 365 -in /tmp/server.csr \
  -signkey /etc/pki/tls/private/server.key \
  -out /etc/pki/tls/certs/server.crt

# Configurar Apache (/etc/httpd/conf.d/ssl.conf)
sudo vi /etc/httpd/conf.d/ssl.conf
# Establecer:
#   SSLCertificateFile /etc/pki/tls/certs/server.crt
#   SSLCertificateKeyFile /etc/pki/tls/private/server.key
#
#   # Recomendado: Deshabilitar versiones TLS débiles
#   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
#
#   # Recomendado: Solo cifrados fuertes
#   SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!RC4

# Iniciar Apache
sudo systemctl enable httpd
sudo systemctl start httpd

# Probar
curl -vk https://localhost/

NGINX en RHEL 7

#============================================#
# CONFIGURACIÓN SSL/TLS DE NGINX (RHEL 7)
#============================================#

# Instalar NGINX (desde EPEL)
sudo yum install epel-release -y
sudo yum install nginx -y

# Generar certificado
sudo openssl genrsa -out /etc/pki/tls/private/nginx.key 2048
sudo openssl req -new -x509 -days 365 \
  -key /etc/pki/tls/private/nginx.key \
  -out /etc/pki/tls/certs/nginx.crt \
  -subj "/CN=$(hostname -f)"

# Configurar NGINX (/etc/nginx/nginx.conf)
# Agregar al bloque de servidor:
#   listen 443 ssl;
#   ssl_certificate /etc/pki/tls/certs/nginx.crt;
#   ssl_certificate_key /etc/pki/tls/private/nginx.key;
#
#   # Recomendado
#   ssl_protocols TLSv1.2;
#   ssl_ciphers HIGH:!aNULL:!MD5;

# Iniciar NGINX
sudo systemctl enable nginx
sudo systemctl start nginx

9.5 Renovación Manual de Certificados (RHEL 7)

Sin crypto-policies, sin herramientas automáticas - ¡todo es manual!

Proceso de Renovación

#============================================#
# PROCESO DE RENOVACIÓN MANUAL (RHEL 7)
#============================================#

# Paso 1: Verificar expiración (configurar recordatorio de calendario)
openssl x509 -in /etc/pki/tls/certs/server.crt -noout -dates

# Paso 2: Generar nuevo CSR (reutilizar clave existente)
openssl req -new -key /etc/pki/tls/private/server.key \
  -out /tmp/server-renewal.csr \
  -subj "/CN=server.example.com"

# Paso 3: Enviar CSR a CA

# Paso 4: Recibir nuevo certificado de CA

# Paso 5: Hacer respaldo del certificado antiguo
sudo cp /etc/pki/tls/certs/server.crt \
     /etc/pki/tls/certs/server.crt.$(date +%Y%m%d).old

# Paso 6: Instalar nuevo certificado
sudo cp new-server.crt /etc/pki/tls/certs/server.crt
sudo chmod 644 /etc/pki/tls/certs/server.crt

# Paso 7: Recargar servicio
sudo systemctl reload httpd

# Paso 8: Probar
curl -v https://localhost/
openssl s_client -connect localhost:443

Rastrear Renovaciones de Certificados

#============================================#
# CREAR RASTREO DE RENOVACIÓN (RHEL 7)
#============================================#

# Tarea cron para verificar expiración
cat > /etc/cron.weekly/check-cert-expiration << 'EOF'
#!/bin/bash
# Verificar certificados que expiran en 60 días

for cert in /etc/pki/tls/certs/*.crt; do
  [ -f "$cert" ] || continue

  if ! openssl x509 -in "$cert" -noout -checkend $((86400*60)); then
    echo "⚠️ $cert expira dentro de 60 días!"
    echo "$cert" | mail -s "Certificado Expirando Pronto" admin@example.com
  fi
done
EOF

chmod +x /etc/cron.weekly/check-cert-expiration

9.6 Problemas Comunes de Certificados en RHEL 7

Problema 1: TLS 1.0/1.1 Obsoleto

Problema: Los clientes modernos rechazan TLS 1.0/1.1

Síntomas:

curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

Solución:

# Actualizar Apache para deshabilitar versiones TLS antiguas
# /etc/httpd/conf.d/ssl.conf
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

# Reiniciar Apache
sudo systemctl restart httpd

Problema 2: Cifrados Débiles

Problema: Los escaneos PCI/Seguridad marcan cifrados débiles

Solución:

# Apache: Usar solo cifrados fuertes
# /etc/httpd/conf.d/ssl.conf
SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!RC4:!EXPORT
SSLHonorCipherOrder on

# Probar
openssl s_client -connect localhost:443 -cipher '3DES'
# Debería fallar si 3DES está deshabilitado

Problema 3: SANs Faltantes

Problema: Los navegadores modernos requieren Subject Alternative Names

Desafío RHEL 7: Los SANs son más difíciles de agregar con OpenSSL 1.0.2

Solución: Usar archivo de configuración

# Crear configuración OpenSSL
cat > /tmp/san.cnf << EOF
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]
CN = server.example.com

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = server.example.com
DNS.2 = www.example.com
IP.1 = 10.0.0.100
EOF

# Generar CSR con SANs
openssl req -new -key server.key -out server.csr -config /tmp/san.cnf

# Verificar SANs en CSR
openssl req -in server.csr -noout -text | grep -A3 "Subject Alternative Name"

9.7 certmonger en RHEL 7

Disponible: Sí (versión básica)

#============================================#
# CERTMONGER EN RHEL 7
#============================================#

# Instalar
sudo yum install certmonger -y
sudo systemctl enable certmonger
sudo systemctl start certmonger

# Solicitar certificado de FreeIPA
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/web.crt \
  -k /etc/pki/tls/private/web.key \
  -K host/$(hostname -f)@REALM

# Listar certificados rastreados
sudo getcert list

# Verificar estado de certificado específico
sudo getcert list -f /etc/pki/tls/certs/web.crt

# Monitorear logs de certmonger
sudo tail -f /var/log/messages | grep certmonger

Limitaciones de RHEL 7:

• Sin soporte ACME (Let’s Encrypt requiere certbot manual)
• Salida de estado menos detallada
• Menos opciones de comandos post-guardado

9.8 Consideraciones de Migración

Cuándo Migrar desde RHEL 7

Deberías migrar si:

• ✅ El soporte terminó (junio 2024) y necesitas actualizaciones
• ✅ Necesitas soporte TLS 1.3
• ✅ Quieres crypto-policies para gestión más fácil
• ✅ Requieres características de seguridad modernas
• ✅ El cumplimiento requiere SO soportado

Tareas de Certificados Pre-Migración

#============================================#
# AUDITORÍA DE CERTIFICADOS PRE-MIGRACIÓN RHEL 7
#============================================#

# 1. Listar todos los certificados
find /etc/pki/tls/ -name "*.crt" -o -name "*.key"

# 2. Verificar expiraciones
for cert in /etc/pki/tls/certs/*.crt; do
  echo "=== $cert ==="
  openssl x509 -in "$cert" -noout -subject -dates
  echo ""
done

# 3. Verificar algoritmos de firma (SHA-1 no funcionará en RHEL 8+)
for cert in /etc/pki/tls/certs/*.crt; do
  SIG=$(openssl x509 -in "$cert" -noout -text | grep "Signature Algorithm" | head -2)
  echo "$cert: $SIG"
done | grep -i sha1
# ¡Si se encuentra alguno, reemitir antes de migración!

# 4. Documentar CAs personalizadas
ls -l /etc/pki/ca-trust/source/anchors/

# 5. Exportar certificados y claves
tar czf rhel7-certificates-backup-$(date +%Y%m%d).tar.gz \
  /etc/pki/tls/certs/*.crt \
  /etc/pki/tls/private/*.key \
  /etc/pki/ca-trust/source/anchors/*

9.9 Flujos de Trabajo Comunes en RHEL 7

Flujo de Trabajo 1: Configuración Manual de Apache HTTPS

# Flujo de trabajo completo desde cero

# 1. Instalar Apache con SSL
sudo yum install httpd mod_ssl -y

# 2. Generar clave privada
sudo openssl genrsa -out /etc/pki/tls/private/$(hostname -s).key 2048

# 3. Establecer permisos de clave
sudo chmod 600 /etc/pki/tls/private/$(hostname -s).key

# 4. Crear CSR
sudo openssl req -new \
  -key /etc/pki/tls/private/$(hostname -s).key \
  -out /tmp/$(hostname -s).csr \
  -subj "/C=US/O=Company/CN=$(hostname -f)"

# 5. Enviar CSR a CA, esperar certificado

# 6. Instalar certificado
sudo cp $(hostname -s).crt /etc/pki/tls/certs/

# 7. Configurar Apache
sudo vi /etc/httpd/conf.d/ssl.conf
# Editar:
#   SSLCertificateFile /etc/pki/tls/certs/$(hostname -s).crt
#   SSLCertificateKeyFile /etc/pki/tls/private/$(hostname -s).key
#   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
#   SSLCipherSuite HIGH:!aNULL:!MD5:!3DES

# 8. Probar configuración
sudo apachectl configtest

# 9. Abrir firewall
sudo firewall-cmd --add-service=https --permanent
sudo firewall-cmd --reload

# 10. Iniciar Apache
sudo systemctl enable httpd
sudo systemctl start httpd

# 11. Probar
curl -vk https://$(hostname -f)/

Flujo de Trabajo 2: Integración con FreeIPA

#============================================#
# FLUJO DE TRABAJO DE CERTIFICADO FREEIPA (RHEL 7)
#============================================#

# Prerrequisitos: El sistema debe estar inscrito en IPA
ipa-client-install

# Instalar certmonger
sudo yum install certmonger -y
sudo systemctl enable certmonger
sudo systemctl start certmonger

# Solicitar certificado para Apache
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/$(hostname -s).crt \
  -k /etc/pki/tls/private/$(hostname -s).key \
  -K host/$(hostname -f)@REALM.EXAMPLE.COM \
  -D $(hostname -f)

# Verificar estado
sudo getcert list

# Esperar estado MONITORING (certificado emitido)

# Configurar Apache para usar cert
# /etc/httpd/conf.d/ssl.conf

# Recargar Apache cuando el cert se renueve
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/$(hostname -s).crt \
  -k /etc/pki/tls/private/$(hostname -s).key \
  -K host/$(hostname -f)@REALM \
  -C "systemctl reload httpd"

9.10 Solución de Problemas de Certificados en RHEL 7

Comandos de Diagnóstico

#============================================#
# DIAGNÓSTICO DE CERTIFICADOS RHEL 7
#============================================#

# Verificar versión de OpenSSL
openssl version

# Probar HTTPS localmente
openssl s_client -connect localhost:443

# Verificar configuración SSL de Apache
sudo apachectl -t -D DUMP_VHOSTS | grep 443

# Ver errores SSL de Apache
sudo tail -f /var/log/httpd/ssl_error_log

# Verificar denegaciones SELinux
sudo grep AVC /var/log/audit/audit.log | grep cert

# Verificar permisos de archivos
ls -lZ /etc/pki/tls/certs/*.crt
ls -lZ /etc/pki/tls/private/*.key

# Verificar par certificado/clave
openssl x509 -noout -modulus -in /etc/pki/tls/certs/server.crt | openssl md5
openssl rsa -noout -modulus -in /etc/pki/tls/private/server.key | openssl md5
# Los hashes MD5 deberían coincidir

Errores Comunes de RHEL 7

9.11 Fortalecimiento de Seguridad en RHEL 7

Configuración Recomendada

#============================================#
# ENDURECIMIENTO SSL/TLS DE APACHE (RHEL 7)
#============================================#

# /etc/httpd/conf.d/ssl.conf

# Deshabilitar protocolos antiguos
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

# Solo cifrados fuertes
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!3DES:!DES

# Honrar preferencia de cifrado del servidor
SSLHonorCipherOrder on

# Habilitar HSTS (HTTP Strict Transport Security)
Header always set Strict-Transport-Security "max-age=31536000"

# OCSP Stapling (no disponible en OpenSSL 1.0.2 de RHEL 7 por defecto)
# Disponible en algunos backports

# Perfect Forward Secrecy
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256

9.12 Ruta de Migración a RHEL 8+

Pasos de Migración Específicos de Certificados

#============================================#
# PREPARAR CERTIFICADOS PARA MIGRACIÓN
#============================================#

# 1. Verificar que todos los certificados usen SHA-256+ (sin SHA-1 ni MD5)
for cert in /etc/pki/tls/certs/*.crt; do
  openssl x509 -in "$cert" -noout -text | grep "Signature Algorithm"
done | grep -i sha1 && echo "⚠️ ¡Certificados SHA-1 encontrados! ¡Reemitir antes de migración!"

# 2. Verificar tamaños de clave (2048+ bits)
for cert in /etc/pki/tls/certs/*.crt; do
  SIZE=$(openssl x509 -in "$cert" -noout -text | grep "Public-Key" | grep -oP '\d+')
  if [ "$SIZE" -lt 2048 ]; then
    echo "⚠️ $cert: Clave muy pequeña ($SIZE bits)"
  fi
done

# 3. Respaldar todo
tar czf rhel7-certs-$(hostname)-$(date +%Y%m%d).tar.gz \
  /etc/pki/tls/ \
  /etc/pki/ca-trust/source/anchors/ \
  /etc/httpd/conf.d/ssl.conf \
  /etc/nginx/nginx.conf

# 4. Documentar inventario de certificados
./generate-cert-inventory.sh > cert-inventory-pre-migration.csv

# 5. Probar compatibilidad TLS 1.2
# Asegurar que todos los servicios funcionen solo con TLS 1.2

9.13 Cuándo RHEL 7 Tiene Sentido

¿Aún Usando RHEL 7? Considera:

Razones para Quedarse (Temporalmente):

• Contrato de Soporte de Ciclo de Vida Extendido activo
• Aplicaciones legacy críticas que requieren TLS 1.0/1.1
• Migración planificada para futuro cercano
• Probando RHEL 8/9 en paralelo

Razones para Migrar:

• ✅ Mantenimiento extendido terminó en junio 2024
• ✅ Sin crypto-policies (más difícil de gestionar)
• ✅ Sin TLS 1.3
• ✅ Actualizaciones de seguridad limitadas
• ✅ Aplicaciones modernas dejando de soportar TLS 1.0/1.1

9.14 Conclusiones Clave

1. RHEL 7 es manual - Sin crypto-policies, se necesita configuración cuidadosa
2. OpenSSL 1.0.2k - Sintaxis antigua, sin TLS 1.3
3. TLS 1.0/1.1 habilitado por defecto - Deshabilitarlos manualmente
4. SHA-1 aún funciona - Pero no después de migración a RHEL 8+
5. certmonger disponible - Pero básico comparado con RHEL 8+
6. Planificar migración - El soporte de RHEL 7 está terminando
7. Documentar todo - Facilita la migración

Referencia Rápida

┌─────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA DE CERTIFICADOS RHEL 7                │
├─────────────────────────────────────────────────────────┤
│ OpenSSL:     1.0.2k-26                                  │
│ TLS:         1.0, 1.1, 1.2 (no 1.3)                     │
│ Política:    Configuración manual (sin crypto-policies) │
│                                                         │
│ Generar:     openssl genrsa -out key.pem 2048           │
│ CSR:         openssl req -new -key key.pem -out req.csr │
│ Ver:         openssl x509 -in cert.crt -noout -text     │
│ Probar:      openssl s_client -connect host:443         │
│                                                         │
│ Fortalecer:  SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1     │
│              SSLCipherSuite HIGH:!aNULL:!MD5:!3DES      │
└─────────────────────────────────────────────────────────┘

Navegación del Capítulo

Capítulo 10: RHEL 8 y Crypto-Policies

Cambio de Juego: RHEL 8 introdujo crypto-policies, revolucionando cómo se gestionan certificados y criptografía en todo el sistema. Esta es la característica más importante que debes entender para RHEL 8.

10.1 ¿Qué Cambió en RHEL 8?

Lanzamiento: 7 de mayo de 2019 Soporte Hasta: 31 de mayo de 2029 Versión Actual: RHEL 8.10 (a partir de 2024)

Cambios Principales Relacionados con Certificados:

Paquete: openssl-1.1.1k-14.el8_6.x86_64

10.2 Entender Crypto-Policies

La Idea Revolucionaria

Problema RHEL 7:

❌ Configurar Apache:     SSLProtocol, SSLCipherSuite
❌ Configurar NGINX:      ssl_protocols, ssl_ciphers
❌ Configurar Postfix:    smtpd_tls_protocols
❌ Configurar OpenLDAP:   olcTLSProtocolMin
❌ ¡Configurar cada aplicación de manera diferente!

Solución RHEL 8:

✅ Establecer UNA política en todo el sistema
✅ ¡Todas las aplicaciones cumplen automáticamente!

Cómo Funciona

┌────────────────────────────────────────┐
│  update-crypto-policies --set DEFAULT  │  ← Comando único
└──────────────────┬─────────────────────┘
                   │
      ┌────────────┴────────────┐
      │ Sistema Crypto-Policies │
      └────────────┬────────────┘
                   │
    ┌──────────────┼──────────────┐
    ▼              ▼              ▼
 OpenSSL        GnuTLS         NSS
 Postfix        Apache         NGINX
 OpenSSH        Kerberos       BIND
 (¡todas apps!) (¡automático!) (¡consistente!)

10.3 Crypto-Policies Disponibles

Las Cuatro Políticas Principales

# Verificar política actual
update-crypto-policies --show

# Políticas disponibles en RHEL 8:

Detalles de Políticas

Política DEFAULT:

Versiones TLS: 1.2, 1.3
RSA/DH Mínimo: 2048 bits
ECC Mínimo: secp256r1 (P-256)
Cifrados: AES-GCM, ChaCha20-Poly1305, AES-CBC
Firmas: SHA-256, SHA-384, SHA-512
Bloqueados: MD5, firmas SHA-1, 3DES, RC4, DSS

Política LEGACY:

Versiones TLS: 1.0, 1.1, 1.2, 1.3
RSA/DH Mínimo: 1024 bits
Cifrados: Incluye 3DES, cifrados débiles
Firmas: Permite SHA-1
Uso: Solo para compatibilidad con sistemas antiguos (¡temporal!)

Política FUTURE:

Versiones TLS: 1.2, 1.3 (cifrados más estrictos)
RSA/DH Mínimo: 3072 bits
ECC Mínimo: secp384r1 (P-384)
Firmas: SHA-384, SHA-512 preferidos
Bloqueados: Todo en DEFAULT, más otros

Política FIPS:

Versiones TLS: 1.2, 1.3
Algoritmos: Solo aprobados FIPS 140-2
Requiere: Modo FIPS habilitado
Más estricto: Requisitos de cumplimiento federal

10.4 Cambiar Crypto-Policies

Cambios Básicos de Política

#============================================#
# VER POLÍTICA ACTUAL
#============================================#

update-crypto-policies --show
# DEFAULT


#============================================#
# ESTABLECER POLÍTICA
#============================================#

# Establecer a FUTURE (más estricto)
sudo update-crypto-policies --set FUTURE

# Establecer a LEGACY (menos seguro, para compatibilidad)
sudo update-crypto-policies --set LEGACY

# Establecer a FIPS (requiere modo FIPS habilitado)
sudo fips-mode-setup --enable
sudo reboot
sudo update-crypto-policies --set FIPS

# Volver a DEFAULT
sudo update-crypto-policies --set DEFAULT


#============================================#
# APLICAR POLÍTICA (reiniciar servicios)
#============================================#

# Crypto-policies actualiza archivos de configuración, pero los servicios deben reiniciarse
sudo systemctl restart httpd nginx postfix

# O reiniciar (asegura que todo use la nueva política)
sudo reboot

Qué Sucede Cuando Cambias la Política

# Ejemplo: Cambiar a política FUTURE

# Antes:
update-crypto-policies --show
# DEFAULT

# Después:
sudo update-crypto-policies --set FUTURE

# Los cambios ocurren en:
ls -l /etc/crypto-policies/back-ends/
# opensslcnf.config      ← Configuración OpenSSL actualizada
# gnutls.config          ← Configuración GnuTLS actualizada
# nss.config             ← Configuración NSS actualizada
# bind.config            ← Configuración BIND actualizada
# ... y más

# Ver política OpenSSL aplicada:
cat /etc/crypto-policies/back-ends/opensslcnf.config

10.5 Impacto de la Política en Certificados

Impacto de la Política DEFAULT

#============================================#
# QUÉ PERMITE/BLOQUEA LA POLÍTICA DEFAULT
#============================================#

# ✅ PERMITIDO:
- TLS 1.2, 1.3
- RSA 2048+ bits
- AES-128-GCM, AES-256-GCM
- ChaCha20-Poly1305
- Firmas SHA-256, SHA-384, SHA-512

# ❌ BLOQUEADO:
- TLS 1.0, 1.1
- RSA < 2048 bits
- 3DES, RC4, DES
- Firmas MD5, SHA-1
- Claves DSA
- Cifrados de exportación

Probar Contra la Política Actual

#============================================#
# PROBAR SI TU CERTIFICADO FUNCIONA
#============================================#

# Probar TLS 1.2
openssl s_client -connect server.example.com:443 -tls1_2

# Probar TLS 1.3
openssl s_client -connect server.example.com:443 -tls1_3

# Probar cifrado específico
openssl s_client -connect server.example.com:443 \
  -cipher 'ECDHE-RSA-AES256-GCM-SHA384'

# Ver qué cifrados están disponibles bajo la política actual
openssl ciphers -v | head -20

10.6 Características de OpenSSL 1.1.1 (RHEL 8)

Nuevas Características

#============================================#
# SOPORTE TLS 1.3 (¡Nuevo en RHEL 8!)
#============================================#

# Probar TLS 1.3
openssl s_client -connect server.example.com:443 -tls1_3

# Beneficios de TLS 1.3:
# - Handshake más rápido
# - Forward secrecy obligatorio
# - Características obsoletas eliminadas


#============================================#
# GENERACIÓN DE CLAVES MODERNA
#============================================#

# Estilo antiguo (aún funciona)
openssl genrsa -out server.key 2048

# Estilo nuevo (preferido en RHEL 8)
openssl genpkey -algorithm RSA -out server.key \
  -pkeyopt rsa_keygen_bits:2048

# Claves EC (curva elíptica)
openssl genpkey -algorithm EC -out ec.key \
  -pkeyopt ec_paramgen_curve:P-256


#============================================#
# GENERACIÓN DE CSR MEJORADA
#============================================#

# CSR con SANs (¡mucho más fácil que RHEL 7!)
openssl req -new -key server.key -out server.csr \
  -subj "/CN=server.example.com" \
  -addext "subjectAltName=DNS:server.example.com,DNS:www.example.com,IP:10.0.0.100"

# Verificar SANs
openssl req -in server.csr -noout -text | grep -A2 "Subject Alternative Name"

10.7 Mejoras de certmonger en RHEL 8

Características Mejoradas

#============================================#
# CERTMONGER EN RHEL 8
#============================================#

# Mejor integración con IPA
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/web.crt \
  -k /etc/pki/tls/private/web.key \
  -D web.example.com \
  -K host/web.example.com@REALM \
  -C "systemctl reload httpd"  # ¡Comando post-guardado (mejorado!)

# Salida de estado mejorada
sudo getcert list -v

# Mejor reporte de errores
sudo getcert list -f /etc/pki/tls/certs/web.crt
# Muestra mensajes de error detallados si la renovación falla

Mejoras de certmonger en RHEL 8:

• ✅ Mejores mensajes de error
• ✅ Soporte de comando post-guardado
• ✅ Integración mejorada con IPA
• ✅ Renovación más confiable

10.8 Escenarios Comunes en RHEL 8

Escenario 1: Migrado desde RHEL 7, App TLS 1.0 Falla

Problema:

# La aplicación funcionaba en RHEL 7
# Después de migración a RHEL 8: fallos de conexión

Diagnóstico:

# Verificar crypto-policy
update-crypto-policies --show
# DEFAULT  ← ¡TLS 1.0/1.1 deshabilitado!

# Verificar logs de aplicación
journalctl -xe | grep -i tls
# "wrong version number" o "no shared cipher"

Solución Rápida (Temporal):

# Usar política LEGACY para permitir TLS 1.0/1.1
sudo update-crypto-policies --set LEGACY
sudo systemctl restart <service>

Solución Apropiada:

# Actualizar aplicación para soportar TLS 1.2+
# O configurar aplicación específicamente (optar por no usar política)

Escenario 2: Necesidad de Soportar Clientes Antiguos

Problema: Clientes Windows Server 2008, Java 7 no pueden conectarse

Solución:

# Opción 1: Política LEGACY (no recomendado a largo plazo)
sudo update-crypto-policies --set LEGACY

# Opción 2: Módulo de política personalizada
# Crear /etc/crypto-policies/policies/modules/COMPAT-OLD-CLIENTS.pmod
sudo update-crypto-policies --set DEFAULT:COMPAT-OLD-CLIENTS

# Opción 3: Optar por no usar política en servicio específico
# Configurar ese servicio para permitir TLS 1.0/1.1

Escenario 3: Probar Antes de Producción

#============================================#
# PROBAR IMPACTO DE CRYPTO-POLICY
#============================================#

# Política actual
CURRENT=$(update-crypto-policies --show)

# Probar con política FUTURE
sudo update-crypto-policies --set FUTURE
sudo systemctl restart httpd

# Ejecutar pruebas
curl https://localhost/
# Suite de pruebas de aplicación

# Si hay problemas:
sudo update-crypto-policies --set $CURRENT  # Revertir
sudo systemctl restart httpd

10.9 Sobrescrituras por Aplicación

Cuándo Sobrescribir

A veces necesitas que UNA aplicación opte por no usar la política del sistema:

Ejemplo: La app legacy necesita TLS 1.0, pero quieres DEFAULT para todo lo demás

#============================================#
# SOBRESCRITURA DE APACHE (Optar por No Usar)
#============================================#

# /etc/httpd/conf.d/ssl.conf
# Agregar esto para re-habilitar TLS 1.0 solo para Apache:
SSLProtocol all

# O usar Include para cargar crypto-policy
Include /etc/crypto-policies/back-ends/httpd.config
# Luego sobrescribir ajustes específicos después

# ⚠️ Nota: Esto opta por NO usar crypto-policies para Apache
# Ahora gestionas TLS de Apache manualmente otra vez

Mejor: Usar módulos de política (ver Capítulo 23 para detalles)

10.10 Resolver Problemas de Crypto-Policy

Problemas Comunes

Problema 1: “no shared cipher”

# Diagnóstico
update-crypto-policies --show
# DEFAULT

# Probar qué cifrados están disponibles
openssl ciphers -v

# Verificar solicitud del cliente
openssl s_client -connect localhost:443 -cipher 'ALL'

# Solución: Usar temporalmente LEGACY para identificar problema
sudo update-crypto-policies --set LEGACY
# Si funciona → problema de compatibilidad de cifrado
# Solución apropiada: Actualizar cliente o crear política personalizada

Problema 2: El servicio falla después de cambio de política

# Síntoma
sudo systemctl status httpd
# Failed to start

# Verificar logs
sudo journalctl -xe -u httpd | grep -i tls

# Revertir política
sudo update-crypto-policies --set DEFAULT
sudo systemctl restart httpd

10.11 Mejores Prácticas para RHEL 8

Recomendación: Usar Política DEFAULT

# Para la mayoría de entornos:
sudo update-crypto-policies --set DEFAULT

# Razones:
✅ Seguridad/compatibilidad equilibrada
✅ Probado por Red Hat
✅ Cumple estándares modernos
✅ Bloquea algoritmos débiles conocidos
✅ Funciona con la mayoría de clientes

Cuándo Usar Otras Políticas

Usar LEGACY cuando:

• Soportar temporalmente clientes muy antiguos
• Período de migración desde RHEL 7
• Probar compatibilidad
• Pero: ¡Planifica volver a DEFAULT lo antes posible!

Usar FUTURE cuando:

• Requisitos de alta seguridad
• Todos los clientes son modernos
• Quieres los ajustes más estrictos
• Planificación anticipada

Usar FIPS cuando:

• Se requiere cumplimiento federal
• Contratos gubernamentales
• Industrias reguladas
• Se necesitan certificaciones de seguridad

10.12 Conclusiones Clave (RHEL 8)

1. Crypto-policies son LA característica - Apréndelas bien
2. La política DEFAULT es buena - No cambiar sin razón
3. TLS 1.3 ahora disponible - Más rápido y más seguro
4. OpenSSL 1.1.1 - Características modernas, mejor sintaxis
5. certmonger mejorado - Mejor automatización
6. Migración desde RHEL 7 - Probar exhaustivamente
7. Planificar para RHEL 9 - OpenSSL 3.x viene

Referencia Rápida

┌────────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA CRYPTO-POLICIES RHEL 8                       │
├────────────────────────────────────────────────────────────────┤
│ OpenSSL:         1.1.1k-14                                     │
│ TLS:             1.2, 1.3 (política DEFAULT)                   │
│ Característica:  Crypto-policies en todo el sistema            │
│                                                                │
│ Ver política:    update-crypto-policies --show                 │
│ Establecer:      sudo update-crypto-policies --set <POLICY>    │
│ Políticas:       DEFAULT, LEGACY, FUTURE, FIPS                 │
│                                                                │
│ Archivos config: /etc/crypto-policies/back-ends/               │
│ Reiniciar:       systemctl restart <services>                  │
│                                                                │
│ Generar clave:   openssl genpkey -algorithm RSA -out key.pem   │
│ CSR con SANs:    openssl req -new -addext "subjectAltName=..." │
└────────────────────────────────────────────────────────────────┘

Navegación del Capítulo

Capítulo 11: Seguridad Moderna en RHEL 9

Estándar Moderno: RHEL 9 representa el estado del arte actual en gestión de certificados en Linux con OpenSSL 3.x, crypto-policies mejoradas y valores predeterminados de seguridad más estrictos.

11.1 Resumen de RHEL 9

Lanzamiento: 17 de mayo de 2022 Soporte Hasta: 31 de mayo de 2032 Versión Actual: RHEL 9.8

Cambios Principales desde RHEL 8:

Paquete: openssl-3.5.5-2.el9_8.x86_64

11.2 OpenSSL 3.5.5 - Cambios Principales

Arquitectura de Proveedores (¡Nuevo!)

Qué Cambió: OpenSSL 3.x introdujo un sistema de “proveedores” para diferentes implementaciones crypto.

#============================================#
# LISTAR PROVEEDORES (RHEL 9)
#============================================#

openssl list -providers

# Salida:
# Providers:
#   default
#     name: OpenSSL Default Provider
#     version: 3.5.5
#     status: active
#
#   fips
#     name: OpenSSL FIPS Provider
#     version: 3.5.5
#     status: inactive (a menos que modo FIPS habilitado)
#
#   legacy
#     name: OpenSSL Legacy Provider
#     version: 3.5.5
#     status: inactive
#
#   base
#     name: OpenSSL Base Provider
#     version: 3.5.5
#     status: active

Los Algoritmos Legacy Requieren Proveedor Explícito

Cambio Incompatible: MD5, Blowfish, CAST5 necesitan -provider legacy

#============================================#
# USAR ALGORITMOS LEGACY (RHEL 9)
#============================================#

# Esto FALLA en RHEL 9:
openssl md5 file.txt
# Error: unsupported

# Esto FUNCIONA (proveedor explícito):
openssl md5 -provider legacy file.txt

# Por qué: Algoritmos legacy deshabilitados por defecto por seguridad

Generación Moderna de Claves (RHEL 9)

#============================================#
# GENERAR CLAVES (RHEL 9)
#============================================#

# RSA 2048 (estándar)
openssl genpkey -algorithm RSA -out server.key \
  -pkeyopt rsa_keygen_bits:2048

# RSA 4096 (más fuerte)
openssl genpkey -algorithm RSA -out server.key \
  -pkeyopt rsa_keygen_bits:4096

# EC P-256 (curva elíptica, recomendado)
openssl genpkey -algorithm EC -out ec.key \
  -pkeyopt ec_paramgen_curve:P-256

# EC P-384 (más fuerte)
openssl genpkey -algorithm EC -out ec.key \
  -pkeyopt ec_paramgen_curve:P-384


#============================================#
# GENERAR CSR CON SANS (RHEL 9)
#============================================#

openssl req -new -key server.key -out server.csr \
  -subj "/C=US/ST=State/O=Company/CN=server.example.com" \
  -addext "subjectAltName=DNS:server.example.com,DNS:www.example.com,IP:10.0.0.100" \
  -addext "keyUsage=digitalSignature,keyEncipherment" \
  -addext "extendedKeyUsage=serverAuth,clientAuth"

# Verificar
openssl req -in server.csr -noout -text | grep -A5 "Subject Alternative Name"

11.3 Crypto-Policies Mejoradas (RHEL 9)

Subpolíticas (¡Nueva Característica!)

RHEL 9 introduce modificadores de política:

#============================================#
# SUBPOLÍTICAS DE CRYPTO-POLICY (RHEL 9)
#============================================#

# Política base con módulo NO-SHA1
sudo update-crypto-policies --set DEFAULT:NO-SHA1

# Múltiples módulos
sudo update-crypto-policies --set DEFAULT:NO-SHA1:GOST

# Subpolíticas comunes:
# - NO-SHA1: Deshabilitar completamente SHA-1 (incluso en firmas)
# - NO-ENFORCE-EMS: Deshabilitar Extended Master Secret
# - GOST: Habilitar algoritmos GOST
# - NO-CAMELLIA: Deshabilitar cifrado Camellia

# Ver módulos disponibles
ls /usr/share/crypto-policies/policies/modules/

Módulos Personalizados de Crypto-Policy (RHEL 9)

#============================================#
# CREAR MÓDULO DE POLÍTICA PERSONALIZADO
#============================================#

# Crear módulo personalizado
sudo vi /etc/crypto-policies/policies/modules/CUSTOM.pmod

# Contenido de ejemplo:
min_rsa_size = 3072
min_dh_size = 3072
min_dsa_size = 3072

# Aplicar
sudo update-crypto-policies --set DEFAULT:CUSTOM

# Probar
openssl ciphers -v | head

11.4 Validación de Certificados Más Estricta

¿Qué es Más Estricto en RHEL 9?

#============================================#
# EJEMPLOS DE VALIDACIÓN MÁS ESTRICTA
#============================================#

# 1. Firmas SHA-1 completamente rechazadas
openssl verify sha1-signed-cert.crt
# Error: CA md too weak

# 2. Autofirmados sin confianza CA apropiada rechazados
curl https://self-signed.example.com/
# Error: certificate verify failed

# 3. La cadena de certificados debe estar completa
# Intermedio faltante → conexión falla

# 4. El hostname debe coincidir (CN o SAN)
openssl s_client -connect server.example.com:443 -servername different.example.com
# Verification error: hostname mismatch

# 5. Claves < 2048 bits rechazadas
# (incluso en política LEGACY, < 1024 rechazadas)

Impacto en Aplicaciones

Aplicaciones compiladas contra OpenSSL 3.x:

• Pueden necesitar cambios de código si usan APIs obsoletas
• El manejo de errores puede ser diferente
• El código crypto personalizado necesita pruebas

Administradores de sistema:

• ✅ La mayoría de cambios transparentes
• ✅ Los comandos son mayormente iguales
• ⚠️ La validación más estricta captura más problemas (¡esto es bueno!)

11.5 Automatización en RHEL 9: certmonger, certbot e IdM ACME

Usa el cliente correcto para la CA correcta

#============================================#
# OPCIONES DE AUTOMATIZACIÓN EN RHEL 9
#============================================#

# Flujo nativo de certmonger para FreeIPA / IdM
sudo dnf install certmonger -y
sudo systemctl enable --now certmonger
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/internal.crt \
  -k /etc/pki/tls/private/internal.key \
  -K HTTP/$(hostname -f)@REALM \
  -D $(hostname -f) \
  -C "systemctl reload httpd"

# Flujo público con Let's Encrypt
# Usa certbot, no una definición falsa de CA Let's Encrypt en certmonger.
sudo certbot certonly --apache -d web.example.com

# Flujo IdM ACME (opcional)
# Esto apunta al directorio ACME de tu servidor IPA, no a Let's Encrypt.
sudo certbot certonly \
  --server https://ipa.example.com/acme/directory \
  -d host.example.com

Importante: IdM ACME y Let’s Encrypt son CAs distintas. certmonger sigue siendo la herramienta nativa de RHEL para IPA, CA local y flujos de renovación con seguimiento.

11.6 Mejoras del Almacén de Confianza

Gestión de Confianza Avanzada

#============================================#
# GESTIÓN DE CONFIANZA RHEL 9
#============================================#

# Agregar CA (igual que RHEL 7/8)
sudo cp corporate-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# NUEVO: Confianza específica por propósito
trust anchor /path/to/ca.crt --purpose server-auth

# Listar confianza con detalles
trust list --filter=ca-anchors

# Exportar CA específica
trust extract --format=pem-bundle --filter=ca-anchors \
  --purpose server-auth /tmp/server-cas.pem

# Eliminar confianza específica
trust anchor --remove "pkcs11:id=%CERT_ID%"

11.7 Problemas y Soluciones Comunes en RHEL 9

Problema 1: Cambios en API de OpenSSL 3.x

Problema: La aplicación personalizada falla con errores de OpenSSL

Síntomas:

Error: EVP_PKEY_RSA no longer supported
Error: Provider not available

Solución:

# Verificar si la aplicación está usando APIs obsoletas
# La aplicación necesita recompilación contra OpenSSL 3.x

# Temporal: Establecer variable de entorno de compatibilidad (si está disponible)
export OPENSSL_CONF=/etc/pki/tls/openssl-compat.cnf

# Largo plazo: Actualizar aplicación

Problema 2: Certificados SHA-1 Rechazados

Problema: Certificados legacy con firmas SHA-1 fallan

Síntomas:

openssl verify cert.crt
# error 3: CA md too weak

Solución:

# Reemitir certificado con SHA-256+
# No hay solución alternativa - SHA-1 está bloqueado por seguridad

# Verificar firma del certificado
openssl x509 -in cert.crt -noout -text | grep "Signature Algorithm"
# Debe mostrar: sha256WithRSAEncryption o mejor

Problema 3: Algoritmo Legacy No Disponible

Problema: La aplicación necesita MD5/RC4/etc.

Síntomas:

openssl md5 file.txt
# Error: unsupported

Solución:

# Usar proveedor legacy explícitamente
openssl md5 -provider legacy file.txt

# Para aplicaciones: Actualizar para usar SHA-256+
# O configurar para cargar proveedor legacy

11.8 Modo FIPS en RHEL 9

Soporte FIPS Mejorado

#============================================#
# MODO FIPS (RHEL 9)
#============================================#

# Habilitar modo FIPS
sudo fips-mode-setup --enable
sudo reboot

# Verificar estado FIPS
fips-mode-setup --check
# FIPS mode is enabled.

# Verificar proveedor FIPS cargado
openssl list -providers | grep -A3 fips
#   fips
#     name: OpenSSL FIPS Provider
#     version: 3.5.5
#     status: active

# Generar certificado compatible con FIPS
openssl req -new -x509 -days 365 -newkey rsa:2048 \
  -keyout fips.key -out fips.crt \
  -subj "/CN=$(hostname)" -provider fips

FIPS en RHEL 9:

• Usa proveedor FIPS de OpenSSL 3.x
• Módulos validados FIPS 140-2
• Transición a FIPS 140-3 en progreso

11.9 Migración desde RHEL 8

Impacto en Certificados

Impacto Moderado:

• Cambios en API de OpenSSL (afecta apps personalizadas)
• Validación más estricta (captura más problemas)
• Algoritmos legacy eliminados
• SHA-1 completamente bloqueado

Verificaciones Pre-Migración

#============================================#
# PRE-MIGRACIÓN DE CERTIFICADOS RHEL 8 → 9
#============================================#

# 1. Verificar certificados SHA-1 (fallarán en RHEL 9)
for cert in /etc/pki/tls/certs/*.crt; do
  SIG=$(openssl x509 -in "$cert" -noout -text | grep "Signature Algorithm" | head -2)
  echo "$cert: $SIG"
done | grep -i sha1
# ⚠️ ¡Reemitir cualquier cert SHA-1 antes de migración!

# 2. Verificar aplicaciones personalizadas usando OpenSSL
rpm -qa | grep -E "custom|local"
# Probar estas aplicaciones en entorno RHEL 9

# 3. Verificar compatibilidad de crypto-policy
update-crypto-policies --show

# 4. Probar operaciones de certificados
openssl s_client -connect localhost:443

# 5. Respaldar todo
tar czf rhel8-certs-backup-$(date +%Y%m%d).tar.gz \
  /etc/pki/tls/ \
  /etc/pki/ca-trust/source/anchors/

11.10 Mejores Prácticas para RHEL 9

Configuración Recomendada

#============================================#
# CONFIGURACIÓN RECOMENDADA (RHEL 9)
#============================================#

# 1. Usar crypto-policy DEFAULT (a menos que necesidad específica)
sudo update-crypto-policies --set DEFAULT

# 2. Usar certmonger para automatización nativa
sudo dnf install certmonger
sudo systemctl enable --now certmonger

# 3. Para sitios públicos: usar certbot con Let's Encrypt
sudo certbot certonly --apache -d web.example.com

# 4. Para interno: usar FreeIPA con certmonger
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/internal.crt \
  -k /etc/pki/tls/private/internal.key \
  -K host/$(hostname -f)@REALM

# 5. Generar claves EC (más pequeñas, más rápidas)
openssl genpkey -algorithm EC -out ec.key \
  -pkeyopt ec_paramgen_curve:P-256

# 6. Siempre usar SANs
openssl req -new -addext "subjectAltName=DNS:..."

11.11 Nuevas Características Que Deberías Usar

Característica 1: Flujos más sólidos de certmonger + IPA

# Automatización nativa de RHEL para certificados internos
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/internal.crt \
  -k /etc/pki/tls/private/internal.key \
  -K HTTP/$(hostname -f)@REALM \
  -D $(hostname -f) \
  -C "systemctl reload httpd"

# Mejor salida de estado en RHEL 9
sudo getcert list -v

Característica 2: Reporte de Estado Mejorado

# Estado más detallado
sudo getcert list -v

# Mejores mensajes de error
sudo getcert list -f /etc/pki/tls/certs/web.crt
# Muestra razón exacta del error si la renovación falla

Característica 3: Subpolíticas de Crypto-Policy

# Afinar política DEFAULT
sudo update-crypto-policies --set DEFAULT:NO-SHA1

# Múltiples modificadores
sudo update-crypto-policies --set FUTURE:AD-SUPPORT

11.12 Cambios Incompatibles desde RHEL 8

Cambios en API

Si tienes aplicaciones personalizadas:

// RHEL 8 (OpenSSL 1.1.1) - OBSOLETO en RHEL 9:
RSA *rsa = RSA_new();

// RHEL 9 (OpenSSL 3.x) - API NUEVA:
EVP_PKEY *pkey = EVP_PKEY_new();

Impacto: Las aplicaciones compiladas personalizadas pueden necesitar actualizaciones

Cambios en Comandos

# La mayoría de comandos funcionan igual, pero algunos casos especiales:

# RHEL 8: Esto funciona
openssl md5 file.txt

# RHEL 9: Requiere proveedor
openssl md5 -provider legacy file.txt

# Solución: Usar SHA-256 en su lugar
openssl sha256 file.txt

11.13 Escenarios Comunes en RHEL 9

Escenario 1: Configuración HTTPS Apache Nueva en RHEL 9 (CA interna)

#============================================#
# CONFIGURACIÓN COMPLETA APACHE HTTPS (RHEL 9)
#============================================#

# 1. Instalar Apache con mod_ssl
sudo dnf install httpd mod_ssl -y

# 2. Usar certmonger + FreeIPA / IdM
sudo dnf install certmonger -y
sudo systemctl enable --now certmonger

# 3. Solicitar certificado
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/web.crt \
  -k /etc/pki/tls/private/web.key \
  -K HTTP/$(hostname -f)@REALM \
  -D $(hostname -f) \
  -C "systemctl reload httpd"

# 4. Esperar certificado (verificar estado)
sudo getcert list

# 5. Configurar Apache para usar certificado
# /etc/httpd/conf.d/ssl.conf ya apunta a:
#   SSLCertificateFile /etc/pki/tls/certs/localhost.crt
# Actualizar a:
#   SSLCertificateFile /etc/pki/tls/certs/web.crt
#   SSLCertificateKeyFile /etc/pki/tls/private/web.key

# 6. ¡Crypto-policy maneja ajustes TLS automáticamente!
# No necesitas establecer SSLProtocol o SSLCipherSuite

# 7. Abrir firewall
sudo firewall-cmd --add-service=https --permanent
sudo firewall-cmd --reload

# 8. Iniciar Apache
sudo systemctl enable httpd
sudo systemctl start httpd

# 9. Probar
curl -v https://$(hostname -f)/

# 10. ¡La renovación automática ocurre mucho antes de la expiración!

Resultado: ¡HTTPS interno totalmente automatizado con FreeIPA y certmonger!

11.14 Solución de Problemas de Certificados en RHEL 9

Comandos de Diagnóstico

#============================================#
# DIAGNÓSTICO DE CERTIFICADOS RHEL 9
#============================================#

# Verificar versión de OpenSSL
openssl version
# OpenSSL 3.5.5

# Verificar proveedores
openssl list -providers

# Verificar crypto-policy
update-crypto-policies --show

# Probar conexión con TLS 1.3
openssl s_client -connect server:443 -tls1_3

# Verificar algoritmo de firma del certificado
openssl x509 -in cert.crt -noout -text | grep "Signature Algorithm"
# Debe ser SHA-256+ en RHEL 9

# Probar con proveedor legacy (si es necesario)
openssl md5 -provider legacy file.txt

# Verificar rastreo de certmonger
sudo getcert list

# Ver logs de certmonger
sudo journalctl -u certmonger -f

Errores Comunes en RHEL 9

11.15 Cuándo Usar RHEL 9

Ideal Para:

✅ Nuevos despliegues - Comenzar con seguridad moderna ✅ Entornos enfocados en seguridad - Valores predeterminados más estrictos ✅ Aplicaciones modernas - Beneficiarse de TLS 1.3 ✅ Soporte a largo plazo - 10 años de mantenimiento ✅ Requisitos de cumplimiento - Estándares de seguridad modernos

Momento de Migración:

Desde RHEL 7:

• ✅ ¡Sí! El mantenimiento de RHEL 7 terminó en junio 2024
• Planificar cuidadosamente - gran salto (probar exhaustivamente)

Desde RHEL 8:

• Moderado - OpenSSL 3.x es el cambio principal
• Probar aplicaciones personalizadas primero
• Los certificados SHA-1 deben ser reemitidos

11.16 Conclusiones Clave

1. Arquitectura de proveedores OpenSSL 3.5.5 - Entender proveedores
2. Validación más estricta - Captura problemas de seguridad (¡bien!)
3. SHA-1 completamente bloqueado - Reemitir certificados antiguos
4. Subpolíticas de crypto-policy - Afinar seguridad
5. certmonger sigue siendo valioso para IPA y flujos de renovación con seguimiento
6. Soporte obligatorio TLS 1.3 - Más rápido, más seguro
7. Planificar pruebas - Apps personalizadas pueden necesitar actualizaciones

Referencia Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA DE CERTIFICADOS RHEL 9                     │
├──────────────────────────────────────────────────────────────┤
│ OpenSSL:        3.5.5 (arquitectura de proveedores)          │
│ TLS:            1.2, 1.3 (1.0/1.1 eliminados completamente)  │
│ Característica: Subpolíticas, validación más estricta         │
│                                                              │
│ Proveedores:    openssl list -providers                      │
│ Política:       update-crypto-policies --show                │
│ Subpolítica:    update-crypto-policies --set DEFAULT:NO-SHA1 │
│                                                              │
│ Generar clave:  openssl genpkey -algorithm RSA -out key.pem  │
│ Clave EC:       openssl genpkey -algorithm EC -out ec.pem    │
│                 -pkeyopt ec_paramgen_curve:P-256             │
│                                                              │
│ ACME público:   certbot certonly --apache -d example.com     │
│ certmonger:     ipa-getcert request ...                      │
│ Algo legacy:    openssl md5 -provider legacy file.txt        │
└──────────────────────────────────────────────────────────────┘

⚠️ SHA-1 está BLOQUEADO - ¡reemitir certificados antiguos!
✅ Usar certmonger para IPA y automatización con seguimiento
✅ La política DEFAULT funciona para la mayoría de casos

Navegación del Capítulo

Capítulo 12: Características Actuales de RHEL 10

Vanguardia: RHEL 10 GA se lanzó el 20 de mayo de 2025; RHEL 10.2 es la versión menor actual. Aprende sobre las últimas características y prepárate para el futuro de la gestión de certificados en Red Hat Enterprise Linux.

12.1 Resumen de RHEL 10

Lanzamiento GA: 20 de mayo de 2025 Versión Actual: RHEL 10.2 Soporte Hasta: 31 de mayo de 2035 Estado: ✅ Lanzamiento de Producción

Características Clave:

• Versión OpenSSL: 3.5.5-2 (paquete: openssl-3.5.5-2.el10_2.x86_64)
• Misma base que: RHEL 9.8 (OpenSSL 3.5.5)
• Enfoque: Fortalecimiento continuo, preparación post-cuántica, nativo de nube
• Filosofía: Mejora incremental sobre RHEL 9

Importante: Las características de RHEL 10 pueden evolucionar a través de versiones menores (10.1, 10.2, etc.). Siempre consulta la documentación oficial de Red Hat para tu lanzamiento específico de RHEL 10.x.

12.2 ¿Qué Hay de Nuevo vs. RHEL 9?

Diferencias Clave

Paquete: openssl-3.5.5-2.el10_2.x86_64

No es un Cambio Revolucionario

A diferencia de RHEL 7→8 (crypto-policies) o RHEL 8→9 (OpenSSL 3.x), RHEL 10 es una mejora incremental.

Piénsalo como:

• RHEL 7 → 8: 🚀 Revolucionario (crypto-policies)
• RHEL 8 → 9: 🔄 Mayor (OpenSSL 3.x)
• RHEL 9 → 10: ⬆️ Incremental (refinamientos)

12.3 Gestión de Certificados en RHEL 10

Mismo Fundamento que RHEL 9

#============================================#
# CONCEPTOS BÁSICOS DE CERTIFICADOS RHEL 10
#============================================#

# Misma versión de OpenSSL que RHEL 9.8
openssl version
# OpenSSL 3.5.5 27 Jan 2026

# Mismo sistema crypto-policies
update-crypto-policies --show

# Mismo certmonger
getcert list

# Misma estructura de directorios
ls -la /etc/pki/tls/

Conclusión: ¡Si conoces RHEL 9, conoces certificados de RHEL 10!

12.4 Características de Seguridad Mejoradas

Valores Predeterminados Más Estrictos

#============================================#
# MEJORAS DE SEGURIDAD RHEL 10
#============================================#

# 1. La política DEFAULT es más estricta
# - Preferencias de cifrado más fuertes
# - Algoritmos débiles adicionales eliminados
# - Validación mejorada

# 2. Política LEGACY más restringida
# - Menos algoritmos legacy permitidos
# - Mínimos más fuertes incluso en LEGACY

# 3. Gestión de certificados de contenedor mejorada
# - Mejor integración con Podman
# - Montaje de certificados simplificado
# - Gestión de secretos mejorada

Preparación para Criptografía Post-Cuántica

Fundamento para el Futuro:

# RHEL 10 se prepara para algoritmos post-cuánticos
# (Aún no predeterminado, pero infraestructura lista)

# Capacidad futura (a medida que los estándares se finalicen):
# - ML-KEM (Module-Lattice Key Encapsulation)
# - ML-DSA (Module-Lattice Digital Signatures)
# - Criptografía híbrida clásica/cuántica

# Estado actual: Monitoreando estándares NIST
# Esperado: Lanzamientos menores RHEL 10.x agregarán soporte PQC

Nota: La criptografía post-cuántica aún está evolucionando. RHEL 10 proporciona el fundamento, la implementación real vendrá a medida que los estándares se finalicen.

12.5 Características Específicas de RHEL 10

Característica 1: Módulos de Crypto-Policy Mejorados

#============================================#
# MEJORAS EN CRYPTO-POLICY DE RHEL 10
#============================================#

# Control más granular
sudo update-crypto-policies --set DEFAULT:NO-SHA1

# Mejor validación
update-crypto-policies --check

# Mensajes de error mejorados cuando las políticas entran en conflicto

Característica 2: Soporte Mejorado de Certificados de Contenedor

#============================================#
# CONTENEDORES CON CERTIFICADOS (RHEL 10)
#============================================#

# Montaje de certificados más fácil en Podman
podman run -d \
  -v /etc/pki/tls/certs/web.crt:/certs/web.crt:ro \
  -v /etc/pki/tls/private/web.key:/certs/web.key:ro \
  -p 443:443 \
  nginx

# Gestión de secretos mejorada
podman secret create web-cert /etc/pki/tls/certs/web.crt
podman secret create web-key /etc/pki/tls/private/web.key

# Usar secretos en contenedor
podman run -d --secret web-cert --secret web-key nginx

Característica 3: Modo FIPS Mejorado

#============================================#
# FIPS EN RHEL 10
#============================================#

# Modo FIPS con proveedor FIPS de OpenSSL 3.x
sudo fips-mode-setup --enable
sudo reboot

# Verificar estado FIPS
fips-mode-setup --check

# RHEL 10: Transición hacia FIPS 140-3
# Actual: Aún módulos validados FIPS 140-2
# Futuro: Cumplimiento FIPS 140-3 a medida que se complete la certificación

12.6 Migración desde RHEL 9

¿Deberías Actualizar?

Consideraciones de Actualización:

Razones para Actualizar:

• ✅ Quieres 10+ años de soporte (hasta 2035)
• ✅ Necesitas las últimas mejoras de seguridad
• ✅ Preparación para el futuro (preparación post-cuántica)
• ✅ Soporte mejorado de contenedores
• ✅ Últimas características y mejoras

Razones para Esperar:

• ⏸️ RHEL 9 soportado hasta 2032
• ⏸️ No hay características urgentes relacionadas con certificados
• ⏸️ Deja que otros prueben RHEL 10 en producción primero
• ⏸️ Quieres esperar por RHEL 10.3 o 10.4

Impacto en Certificados: BAJO

• Misma base OpenSSL (3.5.5)
• Mismas herramientas y comandos
• Cambios incompatibles mínimos
• Mayormente transparente

Proceso de Migración

#============================================#
# MIGRACIÓN DE CERTIFICADOS RHEL 9 → RHEL 10
#============================================#

# 1. Pre-migración: Verificar certificados
for cert in /etc/pki/tls/certs/*.crt; do
  openssl x509 -in "$cert" -noout -text | grep "Signature Algorithm"
done
# Todos deberían mostrar SHA-256+ (sin SHA-1 ni MD5)

# 2. Respaldo
tar czf rhel9-certs-backup-$(date +%Y%m%d).tar.gz \
  /etc/pki/tls/ \
  /etc/pki/ca-trust/source/anchors/

# 3. Realizar actualización de RHEL
sudo leapp upgrade

# 4. Verificar crypto-policy
update-crypto-policies --show

# 5. Reiniciar servicios
sudo systemctl restart httpd nginx postfix

# 6. Probar certificados
curl -v https://localhost/
openssl s_client -connect localhost:443

# 7. Verificar certmonger
sudo getcert list

12.7 Mejores Prácticas para RHEL 10

Configuración Recomendada

#============================================#
# CONFIGURACIÓN RECOMENDADA DE RHEL 10
#============================================#

# 1. Usar crypto-policy DEFAULT (ya óptima)
sudo update-crypto-policies --set DEFAULT

# 2. Preferir TLS 1.3
# (Ya preferido automáticamente por política DEFAULT)

# 3. Usar claves EC para nuevos certificados
openssl genpkey -algorithm EC -out ec.key \
  -pkeyopt ec_paramgen_curve:P-256

# 4. Automatizar con la herramienta correcta
# Certificado público de Let's Encrypt: usar certbot
sudo certbot certonly --apache -d web.example.com

# Certificado interno de FreeIPA / IdM: usar certmonger
# sudo ipa-getcert request \
#   -f /etc/pki/tls/certs/web.crt \
#   -k /etc/pki/tls/private/web.key \
#   -K HTTP/web.example.com@REALM \
#   -D web.example.com \
#   -C "systemctl reload httpd"

# 5. Monitorear certificados
# Usar monitoreo integrado o herramientas externas

# 6. Planificar para PQC futuro
# Mantente al día con lanzamientos menores RHEL 10.x

12.8 Mirando Hacia Adelante: Preparación Post-Cuántica

¿Qué es la Criptografía Post-Cuántica?

Problema: Las computadoras cuánticas futuras podrían romper el cifrado actual (RSA, ECC) Solución: Nuevos algoritmos resistentes a cuántica

Estándares NIST (Finalizados 2024):

• ML-KEM-768 (Encapsulación de Clave)
• ML-DSA-65 (Firmas Digitales)
• SLH-DSA (Firmas sin estado)

Rol de RHEL 10:

• Proporciona fundamento para PQC
• La arquitectura OpenSSL 3.x soporta nuevos algoritmos
• Futuros lanzamientos RHEL 10.x agregarán soporte PQC

Criptografía Híbrida (Futuro)

# Capacidad futura en RHEL 10.x:
# Usar criptografía clásica Y resistente a cuántica

# Ejemplo (conceptual - aún no en RHEL 10.2):
openssl genpkey -algorithm hybrid-rsa-mlkem768 -out hybrid.key

# Proporciona:
# - Seguridad contra ataques clásicos (RSA)
# - Seguridad contra ataques cuánticos (ML-KEM)

Nota: El soporte PQC vendrá en versiones menores futuras de RHEL 10.x a medida que los estándares se finalicen y prueben.

12.9 Qué Permanece Igual

Sin Cambios Incompatibles Mayores

#============================================#
# LOS COMANDOS FAMILIARES AÚN FUNCIONAN
#============================================#

# Generar clave (igual que RHEL 9)
openssl genpkey -algorithm RSA -out server.key \
  -pkeyopt rsa_keygen_bits:2048

# Generar CSR (igual que RHEL 9)
openssl req -new -key server.key -out server.csr \
  -subj "/CN=server.example.com" \
  -addext "subjectAltName=DNS:server.example.com"

# Ver certificado (igual)
openssl x509 -in cert.crt -noout -text

# Probar conexión (igual)
openssl s_client -connect server:443

# Gestión de confianza (igual)
sudo cp ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# certmonger (igual)
sudo getcert list

# crypto-policies (igual)
update-crypto-policies --show

¡Si conoces RHEL 9, estás listo para RHEL 10!

12.10 Cuándo Adoptar RHEL 10

Recomendaciones de Cronograma de Adopción

Adoptadores Tempranos (2025-2026):

• Entornos de prueba
• Cargas de trabajo no críticas
• Quieren las últimas características
• Investigación de seguridad

Mainstream (2026-2027):

• Nuevos despliegues
• Infraestructura renovada
• Después del lanzamiento de RHEL 10.3/10.4
• Cuando las apps principales estén certificadas

Conservador (2027-2028):

• Sistemas de producción críticos
• Cargas de trabajo estables
• Después de pruebas extensivas de la comunidad
• Cuando la migración desde RHEL 9 sea necesaria

Recomendación Actual (Finales de 2025):

• ✅ Proyectos nuevos: Considerar RHEL 10
• ⏸️ RHEL 9 existente: No hay urgencia para actualizar
• ✅ RHEL 8 o anterior: Evaluar RHEL 9 o 10
• ❌ RHEL 7: Actualización requerida (soporte terminado)

12.11 Monitorear la Evolución de RHEL 10

Mantenerse Actualizado

# Verificar versión menor de RHEL 10
cat /etc/redhat-release
# Red Hat Enterprise Linux release 10.2 (Coughlan)

# Verificar actualizaciones
sudo dnf check-update

# Monitorear anuncios de Red Hat
# - https://access.redhat.com/articles/3078
# - Notas de lanzamiento de RHEL 10
# - Avisos de seguridad de Red Hat

# Suscribirse a boletines de Red Hat
# Seguir notas de lanzamiento para 10.3, 10.4, etc.

Características a Vigilar

Esperado en lanzamientos menores RHEL 10.x:

• Soporte de criptografía post-cuántica
• Mejoras adicionales en crypto-policy
• Mayor integración de contenedores
• Herramientas de automatización mejoradas
• Módulos FIPS 140-3 adicionales

12.12 Configuración Práctica de Certificados en RHEL 10

Ejemplo Completo: Configuración HTTPS Moderna

#!/bin/bash
# Configuración HTTPS moderna completa en RHEL 10

echo "=== Configuración HTTPS Moderna RHEL 10 ==="

# 1. Instalar paquetes
sudo dnf install -y httpd mod_ssl epel-release certbot python3-certbot-apache

# 2. Habilitar servicios
sudo systemctl enable --now httpd

# 3. Solicitar certificado de Let's Encrypt con certbot
sudo certbot --apache -d $(hostname -f)

# 4. Verificar el certificado
sudo certbot certificates

# 5. Actualizar configuración de Apache
# certbot normalmente actualiza Apache automáticamente; ajusta manualmente solo si hace falta
sudo sed -i "s|SSLCertificateFile.*|SSLCertificateFile /etc/letsencrypt/live/$(hostname -f)/fullchain.pem|" \
  /etc/httpd/conf.d/ssl.conf
sudo sed -i "s|SSLCertificateKeyFile.*|SSLCertificateKeyFile /etc/letsencrypt/live/$(hostname -f)/privkey.pem|" \
  /etc/httpd/conf.d/ssl.conf

# 6. Crypto-policy ya óptima (DEFAULT)
update-crypto-policies --show

# 7. Abrir firewall
sudo firewall-cmd --add-service=https --permanent
sudo firewall-cmd --reload

# 8. Recargar Apache
sudo systemctl reload httpd

# 9. Probar
curl -v https://$(hostname -f)/

echo "✅ ¡Configuración HTTPS moderna de RHEL 10 completa!"
echo "   - TLS 1.3 soportado"
echo "   - Certificado Let's Encrypt"
echo "   - Renovación automática habilitada"
echo "   - Seguridad óptima (política DEFAULT)"

12.13 Estrategias de Preparación para el Futuro

Preparándose para la Evolución de RHEL 10.x

#============================================#
# GESTIÓN DE CERTIFICADOS PREPARADA PARA EL FUTURO
#============================================#

# 1. Usar algoritmos modernos (listo para transición PQC)
# Preferir EC sobre RSA
openssl genpkey -algorithm EC -out ec.key -pkeyopt ec_paramgen_curve:P-256

# 2. Mantener certificados de corta vida (90 días o menos)
# Más fácil rotar cuando cambien los algoritmos

# 3. Automatizar todo
# Usar certbot para ACME público y certmonger para flujos IPA/internos

# 4. Monitorear anuncios de Red Hat
# Suscribirse a notificaciones de seguridad y lanzamiento

# 5. Probar PQC cuando esté disponible
# Ser probador temprano de nuevas características en RHEL 10.x

# 6. Documentar tu configuración
# Facilita transiciones futuras

12.14 Problemas Conocidos y Soluciones

Problema 1: Igual que RHEL 9 (OpenSSL 3.x)

La mayoría de problemas de RHEL 9 aplican a RHEL 10:

• Los algoritmos legacy necesitan -provider legacy
• SHA-1 bloqueado
• Apps personalizadas pueden necesitar actualizaciones OpenSSL 3.x

Referencia: Ver Capítulo 11 para problemas OpenSSL 3.x

Problema 2: Validación Aún Más Estricta

RHEL 10 puede capturar problemas que RHEL 9 permitía:

# Ejemplo: Certificado marginal que funcionaba en RHEL 9
# podría fallar en RHEL 10

# Solución: Siempre usar mejores prácticas
# - Firmas SHA-256+
# - Claves de 2048+ bits (4096 recomendado)
# - SANs apropiados
# - Cadenas de confianza válidas

12.15 Cuándo Elegir RHEL 10

Matriz de Decisión

12.16 Conclusiones Clave

1. RHEL 10 = RHEL 9 + mejoras incrementales
2. Misma base OpenSSL 3.5.5 - Sin cambios API mayores
3. Valores predeterminados de seguridad más estrictos - Bueno para seguridad
4. Preparación post-cuántica - Infraestructura lista para el futuro
5. Sin cambios urgentes de certificados - La transición es suave
6. Conocimiento de RHEL 9 se transfiere - Mismas herramientas y comandos
7. Vigilar lanzamientos menores - 10.3, 10.4 pueden agregar características

12.17 Solución de Problemas en RHEL 10

Enfoque de Diagnóstico

#============================================#
# RESOLUCIÓN DE PROBLEMAS DE CERTIFICADOS RHEL 10
#============================================#

# Usar la metodología de solución de problemas (Capítulo 27) y los patrones de RHEL 9 (Capítulo 11)

# 1. Verificar versión de RHEL 10
cat /etc/redhat-release
# Red Hat Enterprise Linux release 10.2 (Coughlan)

# 2. Verificar OpenSSL
openssl version
# OpenSSL 3.5.5

# 3. Verificar crypto-policy
update-crypto-policies --show

# 4. Probar certificado
openssl x509 -in cert.crt -noout -text

# 5. Probar conexión
openssl s_client -connect server:443 -tls1_3

# 6. Verificar proveedores (si hay problemas)
openssl list -providers

# 7. Verificar logs
sudo journalctl -xe | grep -i cert

¡No se necesitan nuevas técnicas de solución de problemas - igual que RHEL 9!

12.18 Ruta de Migración Recomendada

De RHEL 9 a RHEL 10

#============================================#
# MIGRACIÓN SEGURA PARA CERTIFICADOS RHEL 9→10
#============================================#

# Fase 1: Preparación
# - Respaldar todos los certificados
# - Documentar configuración actual
# - Probar en entorno de laboratorio

# Fase 2: Migración
# - Usar proceso estándar de actualización de RHEL
# - Los certificados deberían transferirse sin problemas

# Fase 3: Verificación
# - Verificar crypto-policy sin cambios
# - Probar todas las operaciones de certificados
# - Confirmar rastreo de certmonger mantenido
# - Probar servicios usando certificados

# Fase 4: Optimización
# - Considerar claves EC para nuevos certificados
# - Revisar y actualizar crypto-policy si es necesario
# - Monitorear mejoras de RHEL 10.x

12.19 Documentación y Recursos

Recursos Oficiales

## Recursos de Certificados RHEL 10

### Documentación Oficial
- Notas de Lanzamiento RHEL 10 (verificar tu versión 10.x específica)
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/10

### Actualizaciones de Seguridad
- https://access.redhat.com/security/
- Suscribirse a anuncios de seguridad de RHEL

### Crypto-Policies
- https://access.redhat.com/articles/3642912
- Verificar actualizaciones específicas de RHEL 10

### Soporte
- Portal de Clientes Red Hat
- Casos de Soporte Red Hat
- Foros de la comunidad RHEL

12.20 Referencia Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA DE CERTIFICADOS RHEL 10                    │
├──────────────────────────────────────────────────────────────┤
│ OpenSSL:      3.5.5-2 (igual que RHEL 9.8)                   │
│ TLS:          1.3 preferido, 1.2 soportado                   │
│ Lanzado:      20 de mayo de 2025 (RHEL 10.0 GA)              │
│ Estado:       Listo para producción                          │
│                                                              │
│ Cambio clave: Mejoras de seguridad incrementales             │
│ Migración:    Bajo impacto desde RHEL 9                      │
│ Comandos:     Iguales que RHEL 9                             │
│ Herramientas: Iguales que RHEL 9                             │
│                                                              │
│ Futuro:       Preparación criptografía post-cuántica         │
│               Vigilar características en 10.3, 10.4+         │
│                                                              │
│ Verificar:    cat /etc/redhat-release                        │
│               openssl version                                │
│               update-crypto-policies --show                  │
└──────────────────────────────────────────────────────────────┘

✅ ¡Si conoces certificados RHEL 9, conoces RHEL 10!
⚠️ Siempre verificar docs oficiales para tu versión menor 10.x específica

Navegación del Capítulo

Capítulo 13: Compatibilidad entre Versiones

Desafío del Mundo Real: Tu entorno probablemente tiene sistemas RHEL 7, 8 y 9 todos comunicándose entre sí. ¿Cómo haces que los certificados funcionen en todas las versiones?

13.1 La Realidad del Entorno Mixto

La mayoría de las empresas no actualizan todo a la vez. Encontrarás:

Entorno de Producción (Típico):
├── Servidor de App Legacy (RHEL 7)
├── Servidor de Base de Datos (RHEL 8)
├── Capa Web (RHEL 9)
├── Nodo de Gestión (RHEL 10)
└── Clientes: Windows, Mac, Linux, Mobile

Desafío: Estos sistemas tienen diferentes:

• Soporte de versión TLS
• Suites de cifrado
• Reglas de validación de certificados
• Versiones de OpenSSL
• Crypto-policies (o falta de ellas)

13.2 Problemas Comunes de Compatibilidad

Problema 1: Desajustes de Versión TLS

Escenario: Servidor RHEL 9 (solo TLS 1.2+) ← Cliente RHEL 7 (TLS 1.0/1.1 predeterminado)

# Cliente RHEL 7 intentando conectarse a servidor RHEL 9
curl https://rhel9-server.example.com/
# Error: SSL routines:ssl3_get_record:wrong version number

# Por qué: RHEL 7 intenta TLS 1.0 primero, RHEL 9 lo rechaza

Solución:

# Opción 1: Actualizar cliente RHEL 7 para usar TLS 1.2
# Editar /etc/httpd/conf.d/ssl.conf (si cliente Apache)
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

# Opción 2: Política LEGACY temporal en RHEL 9 (NO recomendado)
# sudo update-crypto-policies --set LEGACY  # En servidor RHEL 9

# Opción 3: Mejor - ¡Actualizar sistemas RHEL 7!

Problema 2: Desajustes de Suite de Cifrado

Escenario: Servidor moderno no soporta cifrados de cliente antiguo

# Cliente RHEL 7 → Servidor RHEL 9
openssl s_client -connect rhel9-server:443 -cipher '3DES'
# Error: no shared cipher

Por qué: 3DES está bloqueado en política DEFAULT de RHEL 8+

Solución:

# Verificar qué cifrados están disponibles
openssl ciphers -v 'HIGH:!aNULL:!MD5' | head

# Probar cifrado específico en cliente
openssl s_client -connect server:443 -cipher 'AES256-GCM-SHA384'

# En servidor RHEL 9, si DEBES soportar clientes antiguos:
sudo update-crypto-policies --set LEGACY  # ¡Temporal!

Problema 3: Diferencias de Validación de Certificados

Escenario: Certificado firmado con SHA-1

Certificado con firma SHA-1:
├── ✅ Funciona en RHEL 7
├── ❌ Rechazado por RHEL 8 DEFAULT
├── ❌ Rechazado por RHEL 9
└── ❌ Rechazado por RHEL 10

Solución:

# Reemitir certificado con SHA-256 o mejor
openssl req -new -key server.key -out server.csr -sha256

# Verificar algoritmo de firma
openssl x509 -in cert.crt -noout -text | grep "Signature Algorithm"
# Debería mostrar: sha256WithRSAEncryption (o mejor)

13.3 Matriz de Compatibilidad

Compatibilidad Cliente → Servidor

Leyenda:

• ✅ Funciona sin cambios
• ⚠️ Funciona con cambios de configuración
• ❌ Incompatible sin actualizaciones mayores

13.4 Requisitos de Certificado para Máxima Compatibilidad

El Perfil de Certificado “Universal”

Para funcionar en todas las versiones de RHEL (7-10) y clientes externos:

# Requisitos del Certificado:
✅ Clave RSA: 2048 bits mínimo (4096 para preparación futura)
✅ Firma: SHA-256 o mejor (¡no SHA-1!)
✅ Subject Alternative Names (SANs) requeridos
✅ Validez: ≤ 365 días (requisito de navegador)
✅ Key Usage: Extensiones apropiadas establecidas

❌ Evitar: Firmas SHA-1
❌ Evitar: RSA < 2048 bits
❌ Evitar: SANs faltantes
❌ Evitar: Certificados solo CN

Generar un Certificado Compatible

#============================================#
# PASO 1: Generar Clave (funciona en todas las versiones de RHEL)
#============================================#

# RSA 2048 (mínimo, compatible)
openssl genpkey -algorithm RSA -out universal.key -pkeyopt rsa_keygen_bits:2048

# O RSA 4096 (mejor, aún compatible)
openssl genpkey -algorithm RSA -out universal.key -pkeyopt rsa_keygen_bits:4096


#============================================#
# PASO 2: Crear CSR con SANs
#============================================#

openssl req -new -key universal.key -out universal.csr \
  -subj "/C=US/ST=State/L=City/O=Company/CN=server.example.com" \
  -addext "subjectAltName=DNS:server.example.com,DNS:www.example.com,IP:10.0.0.100" \
  -addext "keyUsage=digitalSignature,keyEncipherment" \
  -addext "extendedKeyUsage=serverAuth,clientAuth"


#============================================#
# PASO 3: Verificar CSR
#============================================#

openssl req -in universal.csr -noout -text | grep -A2 "Subject Alternative Name"
# Debería mostrar tus SANs

openssl req -in universal.csr -noout -text | grep "Public-Key"
# Debería mostrar: Public-Key: (2048 bit) o superior

13.5 Probar Compatibilidad entre Versiones

Script de Suite de Pruebas

#!/bin/bash
# test-cert-compatibility.sh
# Prueba si el certificado funciona desde varias versiones de RHEL

SERVER_HOST="server.example.com"
SERVER_PORT="443"
CERT_FILE="/etc/pki/tls/certs/server.crt"

echo "=== Suite de Pruebas de Compatibilidad de Certificados ==="
echo ""

#============================================#
# PRUEBA 1: Propiedades del Certificado
#============================================#

echo "1. Propiedades del Certificado:"
echo "   Algoritmo de Firma:"
openssl x509 -in "$CERT_FILE" -noout -text | grep "Signature Algorithm" | head -1

echo "   Tamaño de Clave:"
openssl x509 -in "$CERT_FILE" -noout -text | grep "Public-Key"

echo "   SANs:"
openssl x509 -in "$CERT_FILE" -noout -ext subjectAltName 2>/dev/null || echo "   ¡No se encontraron SANs!"

echo ""


#============================================#
# PRUEBA 2: Soporte de Versión TLS
#============================================#

echo "2. Soporte de Versión TLS:"

for version in tls1 tls1_1 tls1_2 tls1_3; do
  if openssl s_client -connect "$SERVER_HOST:$SERVER_PORT" -"$version" </dev/null 2>&1 | grep -q "Cipher"; then
    echo "   ${version//_/.}: ✅ Soportado"
  else
    echo "   ${version//_/.}: ❌ No soportado"
  fi
done

echo ""


#============================================#
# PRUEBA 3: Compatibilidad de Suite de Cifrado
#============================================#

echo "3. Pruebas de Cifrado Comunes:"

# Cifrado moderno (RHEL 8+)
if openssl s_client -connect "$SERVER_HOST:$SERVER_PORT" -cipher 'ECDHE-RSA-AES256-GCM-SHA384' </dev/null 2>&1 | grep -q "Cipher"; then
  echo "   Cifrado moderno (ECDHE-RSA-AES256-GCM-SHA384): ✅"
else
  echo "   Cifrado moderno: ❌"
fi

# Cifrado legacy (RHEL 7)
if openssl s_client -connect "$SERVER_HOST:$SERVER_PORT" -cipher 'AES256-SHA' </dev/null 2>&1 | grep -q "Cipher"; then
  echo "   Cifrado legacy (AES256-SHA): ✅ (puede indicar política LEGACY)"
else
  echo "   Cifrado legacy: ❌ (bueno para seguridad)"
fi


#============================================#
# PRUEBA 4: Validación de Certificado
#============================================#

echo ""
echo "4. Validación de Certificado:"

if openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt "$CERT_FILE" | grep -q "OK"; then
  echo "   Cadena de confianza: ✅ Válida"
else
  echo "   Cadena de confianza: ❌ Inválida"
fi

echo ""
echo "=== Prueba Completa ==="

Uso:

chmod +x test-cert-compatibility.sh
sudo ./test-cert-compatibility.sh

13.6 Manejar Escenarios Específicos de Compatibilidad

Escenario 1: Cliente RHEL 7 → Servidor RHEL 9

Problema: La conexión falla con error de versión TLS

Solución Lado Cliente (RHEL 7):

# Para curl
curl --tlsv1.2 https://rhel9-server/

# Para wget
wget --secure-protocol=TLSv1_2 https://rhel9-server/

# Para aplicaciones usando OpenSSL, establecer variable de entorno
export OPENSSL_CONF=/etc/pki/tls/openssl-tls12.cnf

# Crear configuración personalizada
cat > /etc/pki/tls/openssl-tls12.cnf << 'EOF'
openssl_conf = default_conf

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=1
EOF

Solución Lado Servidor (RHEL 9) - NO RECOMENDADO:

# ¡Solo si es absolutamente necesario y temporalmente!
sudo update-crypto-policies --set LEGACY
sudo systemctl restart httpd  # O tu servicio

Escenario 2: Confianza CA Mixta

Problema: CA corporativa confiable en algunos sistemas pero no en otros

Solución: Almacén de confianza consistente en todas las versiones

#============================================#
# SCRIPT DE DESPLIEGUE (ejecutar en todas las versiones de RHEL)
#============================================#

#!/bin/bash
# deploy-corporate-ca.sh

CA_CERT_URL="http://pki.example.com/ca-chain.crt"
CA_CERT_FILE="/etc/pki/ca-trust/source/anchors/corporate-ca-chain.crt"

# Descargar certificado CA
curl -o "$CA_CERT_FILE" "$CA_CERT_URL"

# Actualizar almacén de confianza (funciona en todas las versiones de RHEL)
update-ca-trust extract

# Verificar
if trust list | grep -q "Corporate Root CA"; then
  echo "✅ CA corporativa instalada exitosamente"
else
  echo "❌ Falló la instalación de CA corporativa"
  exit 1
fi

Escenario 3: Aplicación Usando Biblioteca TLS Antigua

Problema: La aplicación Java 7 no puede conectarse a servidores modernos

Verificar Soporte TLS de Java:

# Verificar versión de Java
java -version

# Probar soporte TLS
java -Djavax.net.debug=ssl:handshake -jar app.jar 2>&1 | grep "TLS"

Opciones:

# Opción 1: Actualizar Java (mejor)
sudo dnf install java-11-openjdk

# Opción 2: Habilitar TLS 1.2 en Java 7 (si actualización imposible)
# Agregar al inicio de Java:
-Dhttps.protocols=TLSv1.2

# Opción 3: Usar script wrapper
#!/bin/bash
export JAVA_OPTS="-Dhttps.protocols=TLSv1.2 -Djavax.net.ssl.trustStore=/etc/pki/java/cacerts"
java $JAVA_OPTS -jar /path/to/app.jar

13.7 Compatibilidad de Crypto-Policy

Entender el Impacto de la Política entre Versiones

#============================================#
# RHEL 7 (Sin crypto-policies)
#============================================#

# Configuración manual en cada app
# Apache: /etc/httpd/conf.d/ssl.conf
# NGINX: /etc/nginx/nginx.conf
# Postfix: /etc/postfix/main.cf


#============================================#
# RHEL 8/9/10 (crypto-policies)
#============================================#

# Control en todo el sistema
update-crypto-policies --set DEFAULT

# Para soportar clientes RHEL 7, podría necesitarse:
update-crypto-policies --set LEGACY  # ¡Temporalmente!

Equivalentes de Política para Entornos Mixtos

Si necesitas mantener compatibilidad:

Opción A: Usar LEGACY en sistemas modernos (no recomendado a largo plazo)

# En servidores RHEL 8/9/10
sudo update-crypto-policies --set LEGACY

Opción B: Configurar RHEL 7 para coincidir con DEFAULT (recomendado)

# En RHEL 7, configurar manualmente para coincidir con DEFAULT de RHEL 8+
# Ejemplo Apache:
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!CAMELLIA
SSLHonorCipherOrder on

13.8 Ruta de Migración: Actualización Gradual

Fase 1: Preparar RHEL 7 (Pre-Migración)

# 1. Reemitir todos los certificados con SHA-256+
# 2. Probar compatibilidad TLS 1.2
# 3. Actualizar configuraciones de cifrado
# 4. Documentar inventario actual de certificados

Fase 2: Desplegar RHEL 8 (Transición)

# 1. Comenzar con política LEGACY
sudo update-crypto-policies --set LEGACY

# 2. Desplegar servicios
# 3. Probar exhaustivamente
# 4. Cambiar gradualmente a DEFAULT
sudo update-crypto-policies --set DEFAULT

Fase 3: Actualizar a RHEL 9 (Modernización)

# 1. Todos los clientes deberían ser RHEL 8+ o capaces de TLS 1.2
# 2. Usar política DEFAULT
# 3. Monitorear problemas de compatibilidad
# 4. Considerar política FUTURE después de estabilización

13.9 Resolver Problemas entre Versiones

Comandos de Diagnóstico

#============================================#
# EN EL CLIENTE
#============================================#

# Probar versión TLS específica
openssl s_client -connect server:443 -tls1_2

# Probar con salida verbosa
curl -v --tlsv1.2 https://server/

# Verificar OpenSSL del cliente
openssl version
openssl ciphers -v


#============================================#
# EN EL SERVIDOR
#============================================#

# Verificar crypto-policy (RHEL 8+)
update-crypto-policies --show

# Verificar configuración de OpenSSL
openssl version
cat /etc/crypto-policies/back-ends/opensslcnf.config

# Probar certificado del servidor
openssl s_client -connect localhost:443 -servername $(hostname)

# Verificar logs de servicio
sudo journalctl -xe | grep -i tls
sudo tail -f /var/log/httpd/ssl_error_log

Mensajes de Error Comunes

13.10 Mejores Prácticas para Entornos Mixtos

1. Estandarizar Emisión de Certificados

# Estándar de Certificado (ejemplo)
Algorithm: RSA
Key Size: 2048 bits mínimo (4096 preferido)
Signature: SHA-256 o mejor
Validity: 365 días máximo
SANs: Siempre incluir
Extensions: Uso de clave apropiado establecido

2. Mantener Almacenes de Confianza Consistentes

# Script de despliegue para todos los sistemas
for host in rhel7-hosts rhel8-hosts rhel9-hosts; do
  ssh "$host" 'sudo cp /path/to/ca.crt /etc/pki/ca-trust/source/anchors/ && sudo update-ca-trust'
done

3. Probar Antes de Desplegar

# Matriz de pruebas
Cliente RHEL 7 → Servidor RHEL 7 ✓
Cliente RHEL 7 → Servidor RHEL 8 ✓
Cliente RHEL 7 → Servidor RHEL 9 ✓
Cliente RHEL 8 → Servidor RHEL 7 ✓
Cliente RHEL 8 → Servidor RHEL 9 ✓
Cliente RHEL 9 → Servidor RHEL 8 ✓

4. Documentar Tu Entorno

## Matriz de Compatibilidad de Certificados

### Servidores:
- Servidor App 1: RHEL 7.9, TLS 1.0-1.2, RSA 2048
- Base de Datos: RHEL 8.10, política DEFAULT, RSA 2048
- Capa Web: RHEL 9.8, política DEFAULT, RSA 4096

### Limitaciones Conocidas:
- Los sistemas RHEL 7 requieren TLS 1.0/1.1 para app legacy X
- La base de datos requiere cifrado específico: AES256-GCM-SHA384

### Plan de Actualización:
- T1 2025: Migrar Servidor App 1 a RHEL 8
- T2 2025: Actualizar todos los certificados a RSA 4096

13.11 Conclusiones Clave

1. Los entornos mixtos son normales - Planificar para compatibilidad
2. TLS 1.2+ es el mínimo para sistemas modernos
3. Firmas SHA-256+ requeridas para RHEL 8+
4. Crypto-policies cambiaron todo (RHEL 8+)
5. Probar en todas las versiones antes de desplegar
6. Documentar todo - especialmente excepciones
7. La ruta de actualización es gradual - no apresurar, probar exhaustivamente

Referencia Rápida

┌──────────────────────────────────────────────────────────────┐
│ LISTA DE VERIFICACIÓN DE COMPATIBILIDAD ENTRE VERSIONES      │
├──────────────────────────────────────────────────────────────┤
│ ✅ RSA 2048+ bits                                            │
│ ✅ Firma SHA-256+                                            │
│ ✅ SANs incluidos                                            │
│ ✅ Soporte TLS 1.2+                                          │
│ ✅ Cifrados modernos                                         │
│ ✅ Confianza CA consistente                                  │
│ ✅ Probado en todas las versiones                            │
└──────────────────────────────────────────────────────────────┘

Comando de prueba:
openssl s_client -connect server:443 -tls1_2 -servername server

Verificar política (RHEL 8+):
update-crypto-policies --show

Navegación del Capítulo

Capítulo 14: Apache httpd en RHEL

Más Común: Apache (httpd) es el servidor web más ampliamente desplegado en RHEL. Domina la configuración HTTPS de Apache en todas las versiones de RHEL.

14.1 Resumen de Apache en RHEL

Nombre del Paquete: httpd Módulo SSL/TLS: mod_ssl Ubicación de Config: /etc/httpd/conf.d/ssl.conf Ruta de Certificados: /etc/pki/tls/certs/ Ruta de Claves: /etc/pki/tls/private/

Comparación de Versiones

14.2 Instalación

RHEL 7

#============================================#
# INSTALAR APACHE CON SSL (RHEL 7)
#============================================#

sudo yum install httpd mod_ssl -y
sudo systemctl enable httpd
sudo systemctl start httpd

# Abrir firewall
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

# Verificar
systemctl status httpd

RHEL 8/9/10

#============================================#
# INSTALAR APACHE CON SSL (RHEL 8/9/10)
#============================================#

sudo dnf install httpd mod_ssl -y
sudo systemctl enable httpd
sudo systemctl start httpd

# Abrir firewall
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

# Verificar
systemctl status httpd
ss -tlnp | grep :443  # Verificar si escucha en 443

14.3 Configuración Básica SSL

Configuración SSL Predeterminada

# Archivo principal de configuración SSL
/etc/httpd/conf.d/ssl.conf

# Directivas clave:
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

Ejemplo Completo de Virtual Host

#============================================#
# /etc/httpd/conf.d/ssl.conf
# O /etc/httpd/conf.d/mysite-ssl.conf
#============================================#

<VirtualHost *:443>
    ServerName www.example.com
    ServerAlias example.com
    DocumentRoot /var/www/html

    # Habilitar SSL/TLS
    SSLEngine on

    # Archivos de certificado
    SSLCertificateFile      /etc/pki/tls/certs/www.example.com.crt
    SSLCertificateKeyFile   /etc/pki/tls/private/www.example.com.key
    SSLCertificateChainFile /etc/pki/tls/certs/chain.crt

    # Protocolos TLS (RHEL 7 - config manual)
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1

    # Suite de cifrado (RHEL 7 - manual)
    SSLCipherSuite          HIGH:!aNULL:!MD5:!3DES:!RC4
    SSLHonorCipherOrder     on

    # HSTS (recomendado)
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

    # Logging
    ErrorLog  /var/log/httpd/ssl_error_log
    CustomLog /var/log/httpd/ssl_access_log combined
</VirtualHost>

14.4 Configuración Específica por Versión

RHEL 7: Configuración SSL Manual

#============================================#
# APACHE SSL - MEJORES PRÁCTICAS RHEL 7
#============================================#

<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on

    # Certificados
    SSLCertificateFile      /etc/pki/tls/certs/www.crt
    SSLCertificateKeyFile   /etc/pki/tls/private/www.key
    SSLCertificateChainFile /etc/pki/tls/certs/chain.crt

    # REQUERIDO: Deshabilitar versiones TLS antiguas manualmente
    SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

    # REQUERIDO: Solo cifrados fuertes
    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
    SSLHonorCipherOrder on

    # Encabezados de seguridad
    Header always set Strict-Transport-Security "max-age=31536000"
    Header always set X-Frame-Options DENY
    Header always set X-Content-Type-Options nosniff
</VirtualHost>

RHEL 8/9/10: Integrado con Crypto-Policies

#============================================#
# APACHE SSL - RHEL 8/9/10 CON CRYPTO-POLICIES
#============================================#

<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on

    # Certificados
    SSLCertificateFile      /etc/pki/tls/certs/www.crt
    SSLCertificateKeyFile   /etc/pki/tls/private/www.key
    SSLCertificateChainFile /etc/pki/tls/certs/chain.crt

    # ¡NO NECESITAS establecer SSLProtocol o SSLCipherSuite!
    # Crypto-policies lo maneja automáticamente
    # (a menos que tengas requisitos específicos)

    # Encabezados de seguridad (aún manuales)
    Header always set Strict-Transport-Security "max-age=31536000"
    Header always set X-Frame-Options DENY
    Header always set X-Content-Type-Options nosniff
</VirtualHost>

Diferencia Clave: ¡En RHEL 8+, crypto-policies configura automáticamente versiones TLS y cifrados!

Verificar Integración con Crypto-Policy

#============================================#
# VERIFICAR CRYPTO-POLICY (RHEL 8/9/10)
#============================================#

# Verificar política actual
update-crypto-policies --show

# Ver política específica de Apache
cat /etc/crypto-policies/back-ends/httpd.config

# Apache incluye esto automáticamente
grep -r "crypto-policies" /etc/httpd/

14.5 Generación de Certificados para Apache

Flujo de Trabajo Completo

#============================================#
# GENERAR CERTIFICADO PARA APACHE (TODAS LAS VERSIONES)
#============================================#

# Paso 1: Generar clave privada
sudo openssl genpkey -algorithm RSA \
  -out /etc/pki/tls/private/www.example.com.key \
  -pkeyopt rsa_keygen_bits:2048

# Paso 2: Establecer permisos
sudo chmod 600 /etc/pki/tls/private/www.example.com.key
sudo chown root:root /etc/pki/tls/private/www.example.com.key

# Paso 3: Generar CSR con SANs
sudo openssl req -new \
  -key /etc/pki/tls/private/www.example.com.key \
  -out /tmp/www.example.com.csr \
  -subj "/C=US/ST=State/L=City/O=Company/CN=www.example.com" \
  -addext "subjectAltName=DNS:www.example.com,DNS:example.com"

# Paso 4: Enviar CSR a CA, recibir certificado

# Paso 5: Instalar certificado
sudo cp www.example.com.crt /etc/pki/tls/certs/
sudo chmod 644 /etc/pki/tls/certs/www.example.com.crt

# Paso 6: Si usas certificados intermedios, instalar cadena
sudo cp chain.crt /etc/pki/tls/certs/www.example.com-chain.crt

# Paso 7: Actualizar configuración de Apache (ver sección 14.3)

# Paso 8: Probar configuración
sudo apachectl configtest

# Paso 9: Recargar Apache
sudo systemctl reload httpd

# Paso 10: Probar HTTPS
curl -v https://www.example.com/
openssl s_client -connect www.example.com:443 -servername www.example.com

14.6 Integración con certmonger (¡Automatización!)

Usar certmonger con Apache

#============================================#
# AUTOMATIZAR CERTIFICADOS APACHE CON CERTMONGER
#============================================#

# Instalar certmonger
sudo dnf install certmonger
sudo systemctl enable --now certmonger

# Opción 1: FreeIPA (CA Interna)
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/www.example.com.crt \
  -k /etc/pki/tls/private/www.example.com.key \
  -D www.example.com \
  -K host/www.example.com@REALM \
  -C "systemctl reload httpd"  # ¡Auto-recargar Apache después de renovación!

# Opción 2: Let's Encrypt (RHEL 9+)
sudo getcert request \
  -c lets-encrypt \
  -f /etc/pki/tls/certs/www.example.com.crt \
  -k /etc/pki/tls/private/www.example.com.key \
  -D www.example.com \
  -C "systemctl reload httpd"

# Verificar estado
sudo getcert list

# Esperar estado MONITORING
# ¡El certificado se renueva automáticamente ~30 días antes de expirar!

Beneficios:

• ✅ Renovación automática
• ✅ Sin tiempo de inactividad (recarga, no reinicio)
• ✅ Rastrea expiración
• ✅ Alertas por email si falla

14.7 Let’s Encrypt con certbot

⚠️ IMPORTANTE: EPEL Requerido

certbot NO está disponible en repositorios oficiales de RHEL. Requiere EPEL (Extra Packages for Enterprise Linux), un repositorio mantenido por la comunidad.

Para entornos RHEL de producción, considera:

• FreeIPA con certmonger (recomendado para RHEL)
• Gestión manual de certificados
• CA comercial con certmonger

#============================================#
# CONFIGURACIÓN DE CERTBOT (¡REQUIERE EPEL!)
#============================================#

# Paso 1: Habilitar EPEL (TODAS las versiones RHEL)
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-$(rpm -E %rhel).noarch.rpm

# O en RHEL 8/9/10:
sudo dnf install epel-release

# Paso 2: Instalar certbot
sudo dnf install certbot python3-certbot-apache

# Paso 3: Obtener certificado (¡automatizado!)
sudo certbot --apache -d www.example.com -d example.com

# Paso 4: Certbot automáticamente:
#  - Genera certificado
#  - Configura Apache
#  - Configura temporizador de renovación
#  - Habilita redirección HTTPS

# Paso 5: Probar renovación automática
sudo certbot renew --dry-run

# Verificar temporizador de renovación
systemctl list-timers | grep certbot

Pros:

• ✅ Completamente automatizado
• ✅ Certificados gratuitos
• ✅ Configuración de Apache manejada automáticamente

Contras:

• ❌ Requiere EPEL (no soportado oficialmente por Red Hat)
• ❌ Dependencia externa (Let’s Encrypt)
• ⚠️ El dominio debe ser públicamente accesible

14.8 Solución de Problemas de Apache HTTPS

Lista de Verificación de Problemas Comunes

#============================================#
# LISTA DE VERIFICACIÓN SOLUCIÓN DE PROBLEMAS APACHE SSL
#============================================#

# 1. Verificar si mod_ssl está cargado
sudo httpd -M | grep ssl_module
# Debería mostrar: ssl_module (shared)

# 2. Verificar sintaxis de configuración
sudo apachectl configtest
# Debería mostrar: Syntax OK

# 3. Verificar que existan archivos de certificado
ls -l /etc/pki/tls/certs/www.crt
ls -l /etc/pki/tls/private/www.key

# 4. Verificar permisos
ls -l /etc/pki/tls/private/www.key
# Debería ser: -rw------- (600)

# 5. Verificar contexto SELinux
ls -Z /etc/pki/tls/certs/www.crt
ls -Z /etc/pki/tls/private/www.key
# Debería mostrar: cert_t

# 6. Probar coincidencia par certificado/clave
CERT_MOD=$(openssl x509 -noout -modulus -in /etc/pki/tls/certs/www.crt | openssl md5)
KEY_MOD=$(openssl rsa -noout -modulus -in /etc/pki/tls/private/www.key | openssl md5)
[ "$CERT_MOD" = "$KEY_MOD" ] && echo "✅ Coincide" || echo "❌ ¡No coincide!"

# 7. Verificar si el puerto 443 está escuchando
ss -tlnp | grep :443

# 8. Verificar firewall
sudo firewall-cmd --list-services | grep https

# 9. Probar localmente
curl -vk https://localhost/

# 10. Verificar logs
sudo tail -f /var/log/httpd/ssl_error_log

Errores Comunes y Soluciones

14.9 Solución de Problemas Específica por Versión

Específico RHEL 7

#============================================#
# PROBLEMAS APACHE RHEL 7
#============================================#

# Problema: Navegadores modernos rechazan TLS 1.0/1.1
# Solución: Deshabilitar TLS antiguo en ssl.conf
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

# Problema: Cifrados débiles marcados por escaneo
# Solución: Usar cifrados fuertes
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5
SSLHonorCipherOrder on

# Problema: Sin SANs en certificado
# Solución: Reemitir con SANs (ver 13.5)

# Probar
openssl s_client -connect localhost:443 -tls1_2

Específico RHEL 8/9/10

#============================================#
# PROBLEMAS APACHE RHEL 8/9/10
#============================================#

# Problema: El servicio falla después de cambio de crypto-policy
# Diagnóstico:
update-crypto-policies --show
sudo journalctl -xe -u httpd | grep -i tls

# Solución 1: Verificar que la política sea correcta
sudo update-crypto-policies --set DEFAULT

# Solución 2: Verificar si sobrescribes manualmente la política
grep -E "SSLProtocol|SSLCipherSuite" /etc/httpd/conf.d/*.conf
# Si se encuentra, eliminar (dejar que crypto-policy lo maneje)

# Problema: Error "no shared cipher"
# Diagnóstico: Cliente muy antiguo o política muy estricta
# Solución temporal:
sudo update-crypto-policies --set LEGACY
sudo systemctl restart httpd

# Solución apropiada: Actualizar cliente o crear módulo de política personalizado

14.10 Mejores Prácticas de Seguridad

Configuración SSL Apache Fortalecida

#============================================#
# CONFIGURACIÓN SSL FORTALECIDA (TODAS LAS VERSIONES)
#============================================#

<VirtualHost *:443>
    ServerName secure.example.com

    SSLEngine on
    SSLCertificateFile      /etc/pki/tls/certs/secure.crt
    SSLCertificateKeyFile   /etc/pki/tls/private/secure.key

    # RHEL 7: Configuración TLS manual
    # SSLProtocol TLSv1.2 TLSv1.3
    # SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256
    # SSLHonorCipherOrder on

    # RHEL 8/9/10: Crypto-policies manejan lo anterior automáticamente

    # HSTS (forzar HTTPS por 1 año)
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    # Prevenir clickjacking
    Header always set X-Frame-Options "DENY"

    # Prevenir MIME-type sniffing
    Header always set X-Content-Type-Options "nosniff"

    # Deshabilitar firma del servidor
    ServerSignature Off
    ServerTokens Prod

    # OCSP Stapling (RHEL 8/9/10)
    SSLUseStapling on
    SSLStaplingCache "shmcb:/var/run/ocsp(128000)"

    # Autenticación de certificado de cliente (opcional)
    # SSLVerifyClient require
    # SSLVerifyDepth 3
    # SSLCACertificateFile /etc/pki/tls/certs/client-ca.crt
</VirtualHost>

# Fuera de VirtualHost (configuraciones SSL globales)
SSLStaplingCache "shmcb:/var/run/ocsp(128000)"

14.11 Redirección HTTP a HTTPS

Forzar HTTPS

#============================================#
# REDIRIGIR HTTP → HTTPS
#============================================#

# Método 1: VirtualHost Separado
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName www.example.com
    # ... configuración SSL ...
</VirtualHost>

# Método 2: mod_rewrite
<VirtualHost *:80>
    ServerName www.example.com

    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

14.12 Probar Apache HTTPS

Pruebas Comprehensivas

#============================================#
# SUITE DE PRUEBAS APACHE HTTPS
#============================================#

# Prueba 1: Sintaxis de configuración
sudo apachectl configtest

# Prueba 2: Módulo SSL cargado
sudo httpd -M | grep ssl

# Prueba 3: Puerto escuchando
ss -tlnp | grep :443

# Prueba 4: Conexión local
curl -vk https://localhost/

# Prueba 5: Hostname real
curl -v https://www.example.com/

# Prueba 6: Validación de certificado
openssl s_client -connect www.example.com:443 -servername www.example.com

# Prueba 7: TLS 1.2
openssl s_client -connect www.example.com:443 -tls1_2

# Prueba 8: TLS 1.3 (RHEL 8+)
openssl s_client -connect www.example.com:443 -tls1_3

# Prueba 9: Verificar detalles del certificado desde servidor
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>&1 | \
  openssl x509 -noout -text | head -30

# Prueba 10: Prueba online (externa)
# Usar: https://www.ssllabs.com/ssltest/

14.13 Optimización de Rendimiento

Ajuste de Rendimiento SSL/TLS

#============================================#
# AJUSTE DE RENDIMIENTO
#============================================#

<VirtualHost *:443>
    # ... configuración básica ...

    # Caché de sesión (mejora el rendimiento)
    SSLSessionCache         "shmcb:/var/cache/httpd/ssl_scache(512000)"
    SSLSessionCacheTimeout  300

    # OCSP Stapling (reduce búsqueda del lado del cliente)
    SSLUseStapling on
    SSLStaplingCache "shmcb:/var/run/ocsp(128000)"

    # Keep-Alive (reutilizar conexiones)
    KeepAlive On
    MaxKeepAliveRequests 100
    KeepAliveTimeout 5

    # HTTP/2 (RHEL 8/9/10)
    Protocols h2 h2c http/1.1
</VirtualHost>

14.14 Monitorear Apache HTTPS

Qué Monitorear

#============================================#
# MONITOREO APACHE HTTPS
#============================================#

# Expiración de certificado
openssl s_client -connect localhost:443 -servername $(hostname -f) 2>/dev/null | \
  openssl x509 -noout -dates

# Estado del servicio
systemctl status httpd

# Conteo de conexiones
ss -tn | grep :443 | wc -l

# Monitoreo de log de errores
sudo tail -f /var/log/httpd/ssl_error_log

# Estado de certmonger (si se usa)
sudo getcert list -f /etc/pki/tls/certs/www.crt

# Análisis de log de acceso
sudo tail -f /var/log/httpd/ssl_access_log | grep -E "HTTP/[12]"

14.15 Guía Rápida de Solución de Problemas

¿Apache HTTPS No Funciona?

├─ ¿Apache no inicia?
│  ├─ Verificar: apachectl configtest
│  ├─ Verificar: journalctl -xe -u httpd
│  └─ Solución: Errores de configuración
│
├─ ¿No puedes conectar al puerto 443?
│  ├─ Verificar: ss -tlnp | grep :443
│  ├─ Verificar: firewall-cmd --list-services
│  └─ Solución: Abrir firewall, iniciar httpd
│
├─ ¿Advertencias de certificado en el navegador?
│  ├─ Verificar: Expiración de certificado
│  ├─ Verificar: Coincidencia de hostname (CN/SANs)
│  ├─ Verificar: Cadena de confianza
│  └─ Solución: Renovar cert, corregir SANs, instalar CA
│
├─ ¿Error "No shared cipher"?
│  ├─ Verificar: update-crypto-policies --show
│  ├─ Verificar: Versión TLS del cliente
│  └─ Solución: Actualizar política o cliente
│
└─ ¿Errores de permisos?
   ├─ Verificar: ls -lZ /etc/pki/tls/private/*.key
   ├─ Verificar: Denegaciones SELinux
   └─ Solución: chmod 600, restorecon

14.16 Conclusiones Clave

1. Apache + mod_ssl es el servidor web estándar de RHEL
2. RHEL 7: Configuración TLS manual requerida
3. RHEL 8/9/10: Crypto-policies simplifican la configuración
4. Integración con certmonger habilita automatización
5. certbot requiere EPEL (no soportado oficialmente)
6. Siempre usar SANs en certificados
7. Probar exhaustivamente antes de despliegue en producción

Tarjeta de Referencia Rápida

┌─────────────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA APACHE HTTPD HTTPS                                │
├─────────────────────────────────────────────────────────────────────┤
│ Instalar:       dnf install httpd mod_ssl                           │
│ Config:         /etc/httpd/conf.d/ssl.conf                          │
│ Certs:          /etc/pki/tls/certs/                                 │
│ Claves:         /etc/pki/tls/private/ (¡modo 600!)                  │
│                                                                     │
│ Probar config:  apachectl configtest                                │
│ Recargar:       systemctl reload httpd                              │
│ Logs:           /var/log/httpd/ssl_error_log                        │
│                                                                     │
│ certmonger:     ipa-getcert request ... -C "systemctl reload httpd" │
│ certbot:        certbot --apache (¡requiere EPEL!)                  │
│                                                                     │
│ Probar:         curl -v https://localhost/                          │
│                 openssl s_client -connect host:443                  │
└─────────────────────────────────────────────────────────────────────┘

⚠️ RHEL 8/9/10: Dejar que crypto-policies maneje config TLS/cifrado
⚠️ certbot requiere EPEL (no soportado oficialmente)

🧪 Laboratorio Práctico

Lab 06: Configuración HTTPS de Apache

Configura Apache con SSL/TLS en diferentes versiones de RHEL

• 📁 Ubicación: labs/es_ES/06-apache-https/
• ⏱️ Tiempo: 30-40 minutos
• 🎯 Nivel: Intermedio

Navegación del Capítulo

Capítulo 15: NGINX en RHEL

Alto Rendimiento: NGINX es un servidor web y proxy inverso de alto rendimiento popular. Aprende cómo configurar NGINX con certificados TLS en RHEL.

15.1 Resumen de NGINX en RHEL

Nombre del Paquete: nginx Ubicación de Config: /etc/nginx/nginx.conf Ruta de Certificados: /etc/pki/tls/certs/ o /etc/nginx/certs/ Ruta de Claves: /etc/pki/tls/private/ o /etc/nginx/certs/

Fuentes de Instalación por Versión de RHEL

Nota: RHEL 7 requiere EPEL para NGINX. RHEL 8+ incluye NGINX en repos oficiales.

15.2 Instalación

RHEL 7

#============================================#
# INSTALAR NGINX (RHEL 7 - REQUIERE EPEL)
#============================================#

# Paso 1: Habilitar EPEL
sudo yum install epel-release -y

# Paso 2: Instalar NGINX
sudo yum install nginx -y

# Paso 3: Habilitar e iniciar
sudo systemctl enable nginx
sudo systemctl start nginx

# Paso 4: Abrir firewall
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

# Verificar
systemctl status nginx
curl http://localhost/

RHEL 8

#============================================#
# INSTALAR NGINX (RHEL 8 - DE APPSTREAM)
#============================================#

# Listar módulos NGINX disponibles
dnf module list nginx

# Instalar versión específica
sudo dnf module install nginx:1.20 -y

# O instalar predeterminado
sudo dnf install nginx -y

# Habilitar e iniciar
sudo systemctl enable nginx
sudo systemctl start nginx

# Abrir firewall
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

RHEL 9/10

#============================================#
# INSTALAR NGINX (RHEL 9/10)
#============================================#

sudo dnf install nginx -y

sudo systemctl enable nginx
sudo systemctl start nginx

# Abrir firewall
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

# Verificar
systemctl status nginx
ss -tlnp | grep :443

15.3 Configuración Básica HTTPS

Configuración TLS Mínima

#============================================#
# /etc/nginx/nginx.conf o /etc/nginx/conf.d/default.conf
#============================================#

server {
    listen 80;
    server_name www.example.com;

    # Redirigir HTTP a HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name www.example.com;

    # Archivos de certificado
    ssl_certificate     /etc/pki/tls/certs/www.example.com.crt;
    ssl_certificate_key /etc/pki/tls/private/www.example.com.key;

    # Protocolos TLS
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cifrados
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    # Directorio raíz
    root /usr/share/nginx/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Configuración de Producción Fortalecida

#============================================#
# CONFIGURACIÓN HTTPS NGINX GRADO PRODUCCIÓN
#============================================#

server {
    listen 443 ssl http2;
    server_name api.example.com;

    # Certificados
    ssl_certificate     /etc/pki/tls/certs/api.example.com.crt;
    ssl_certificate_key /etc/pki/tls/private/api.example.com.key;

    # Versiones TLS
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cifrados fuertes
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;

    # Parámetros DH (opcional, para perfect forward secrecy)
    ssl_dhparam /etc/nginx/dhparam.pem;

    # Optimización de sesión SSL
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_session_tickets off;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/pki/tls/certs/chain.crt;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # HSTS
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # Encabezados de seguridad
    add_header X-Frame-Options DENY always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-XSS-Protection "1; mode=block" always;

    # Logging
    access_log /var/log/nginx/api_access.log;
    error_log /var/log/nginx/api_error.log;

    location / {
        proxy_pass http://backend_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

15.4 Configuración de Certificados

Generar Certificados para NGINX

#============================================#
# GENERACIÓN DE CERTIFICADOS PARA NGINX
#============================================#

# Paso 1: Crear directorio de certs (opcional)
sudo mkdir -p /etc/nginx/certs
sudo chmod 755 /etc/nginx/certs

# Paso 2: Generar clave privada
sudo openssl genpkey -algorithm RSA \
  -out /etc/pki/tls/private/api.example.com.key \
  -pkeyopt rsa_keygen_bits:2048

# Paso 3: Establecer permisos
sudo chmod 600 /etc/pki/tls/private/api.example.com.key
sudo chown root:nginx /etc/pki/tls/private/api.example.com.key

# Paso 4: Generar CSR
sudo openssl req -new \
  -key /etc/pki/tls/private/api.example.com.key \
  -out /tmp/api.example.com.csr \
  -subj "/CN=api.example.com" \
  -addext "subjectAltName=DNS:api.example.com,DNS:www.api.example.com"

# Paso 5: Enviar a CA, recibir certificado

# Paso 6: Instalar certificado
sudo cp api.example.com.crt /etc/pki/tls/certs/
sudo chmod 644 /etc/pki/tls/certs/api.example.com.crt

15.5 Integración con certmonger

Renovación Automatizada con certmonger

#============================================#
# CERTMONGER + NGINX
#============================================#

# Instalar certmonger
sudo dnf install certmonger
sudo systemctl enable --now certmonger

# Solicitar certificado de FreeIPA
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/nginx.example.com.crt \
  -k /etc/pki/tls/private/nginx.example.com.key \
  -D nginx.example.com \
  -K host/nginx.example.com@REALM \
  -C "systemctl reload nginx"  # ¡Auto-recargar al renovar!

# O de Let's Encrypt (RHEL 9+)
sudo getcert request \
  -c lets-encrypt \
  -f /etc/pki/tls/certs/nginx.example.com.crt \
  -k /etc/pki/tls/private/nginx.example.com.key \
  -D nginx.example.com \
  -C "systemctl reload nginx"

# Monitorear estado
sudo getcert list

15.6 Let’s Encrypt con certbot

⚠️ IMPORTANTE: EPEL Requerido

certbot NO está disponible en repositorios oficiales de RHEL. Requiere EPEL, un repositorio mantenido por la comunidad.

Instalación: Todas las versiones RHEL requieren EPEL, pero el comando de habilitación varía según la versión. Consulte el Capítulo 24 para el flujo completo de certbot.

RHEL 7

# Paso 1: Habilitar EPEL
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y

# Paso 2: Instalar certbot con plugin NGINX
sudo yum install certbot python2-certbot-nginx -y

RHEL 8

# Paso 1: Habilitar EPEL
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y
# O, con suscripción activa:
# sudo dnf install epel-release -y

# Paso 2: Instalar certbot con plugin NGINX
sudo dnf install certbot python3-certbot-nginx -y

RHEL 9/10

# Paso 1: Habilitar EPEL
sudo dnf install epel-release -y

# Paso 2: Instalar certbot con plugin NGINX
sudo dnf install certbot python3-certbot-nginx -y

Obtener y configurar el certificado (todas las versiones)

# Paso 3: Obtener e instalar certificado (¡automatizado!)
sudo certbot --nginx -d www.example.com -d example.com

# Certbot hará:
#  ✅ Generar certificado de Let's Encrypt
#  ✅ Actualizar configuración NGINX automáticamente
#  ✅ Configurar redirección HTTP a HTTPS
#  ✅ Configurar renovación automática

# Paso 4: Verificar temporizador de renovación automática
systemctl list-timers | grep certbot

# Paso 5: Probar renovación (simulación)
sudo certbot renew --dry-run

# ¡El certificado se renueva automáticamente cada 60 días!

Recuerda: EPEL tiene soporte comunitario, no de Red Hat. Para producción empresarial, considera FreeIPA + certmonger.

15.7 Proxy Inverso con TLS

NGINX como Proxy de Terminación TLS

#============================================#
# PROXY INVERSO NGINX CON TLS
#============================================#

upstream backend_servers {
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

server {
    listen 443 ssl http2;
    server_name proxy.example.com;

    # Terminación TLS aquí
    ssl_certificate     /etc/pki/tls/certs/proxy.crt;
    ssl_certificate_key /etc/pki/tls/private/proxy.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    # Proxy a backends (HTTP)
    location / {
        proxy_pass http://backend_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

15.8 Solución de Problemas NGINX HTTPS

Comandos de Diagnóstico

#============================================#
# SOLUCIÓN DE PROBLEMAS NGINX HTTPS
#============================================#

# Probar sintaxis de configuración
sudo nginx -t

# Mostrar configuración completa (con includes)
sudo nginx -T

# Verificar rutas de certificado SSL
sudo nginx -T | grep ssl_certificate

# Verificar archivo de certificado
sudo openssl x509 -in /etc/pki/tls/certs/nginx.crt -noout -text

# Verificar archivo de clave
sudo openssl rsa -in /etc/pki/tls/private/nginx.key -check

# Verificar coincidencia par cert/clave
CERT=$(openssl x509 -noout -modulus -in /etc/pki/tls/certs/nginx.crt | openssl md5)
KEY=$(openssl rsa -noout -modulus -in /etc/pki/tls/private/nginx.key | openssl md5)
[ "$CERT" = "$KEY" ] && echo "✅ Coincide" || echo "❌ ¡Desajuste!"

# Verificar si NGINX está escuchando en 443
ss -tlnp | grep :443

# Verificar contexto SELinux
ls -Z /etc/pki/tls/certs/nginx.crt
ls -Z /etc/pki/tls/private/nginx.key

# Probar HTTPS localmente
curl -vk https://localhost/

# Verificar logs
sudo tail -f /var/log/nginx/error.log

Errores HTTPS Comunes de NGINX

15.9 Configuración Específica por Versión

RHEL 7: Configuración TLS Manual

#============================================#
# NGINX RHEL 7 - CONFIGURACIÓN SSL MANUAL
#============================================#

server {
    listen 443 ssl;
    server_name www.example.com;

    ssl_certificate     /etc/pki/tls/certs/www.crt;
    ssl_certificate_key /etc/pki/tls/private/www.key;

    # REQUERIDO: Deshabilitar manualmente TLS débil
    ssl_protocols TLSv1.2;  # ¡No TLS 1.0/1.1!

    # REQUERIDO: Establecer manualmente cifrados fuertes
    ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5';
    ssl_prefer_server_ciphers on;

    # Encabezados de seguridad
    add_header Strict-Transport-Security "max-age=31536000" always;

    root /usr/share/nginx/html;
}

RHEL 8/9/10: Con Crypto-Policies

#============================================#
# NGINX RHEL 8/9/10 - CON CRYPTO-POLICIES
#============================================#

server {
    listen 443 ssl http2;
    server_name www.example.com;

    ssl_certificate     /etc/pki/tls/certs/www.crt;
    ssl_certificate_key /etc/pki/tls/private/www.key;

    # Configuración TLS mínima - ¡crypto-policies manejan el resto!
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    # O confiar completamente en crypto-policies:
    # (eliminar ssl_protocols y ssl_ciphers)
    # NGINX usará crypto-policy del sistema

    # Optimización de sesión
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/pki/tls/certs/chain.crt;

    # HSTS
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    root /usr/share/nginx/html;
}

15.10 Optimización de Rendimiento

Ajuste de Rendimiento SSL/TLS

#============================================#
# OPTIMIZACIÓN DE RENDIMIENTO SSL NGINX
#============================================#

http {
    # Caché de sesión SSL (reduce overhead de handshake)
    ssl_session_cache shared:SSL:50m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # Tamaños de buffer
    ssl_buffer_size 4k;  # Más pequeño = menor latencia, más grande = mejor throughput

    server {
        listen 443 ssl http2;
        server_name fast.example.com;

        ssl_certificate     /etc/pki/tls/certs/fast.crt;
        ssl_certificate_key /etc/pki/tls/private/fast.key;

        # Usar HTTP/2 para multiplexación
        # (ya habilitado en directiva listen)

        # Habilitar OCSP Stapling (reduce tiempo de búsqueda del cliente)
        ssl_stapling on;
        ssl_stapling_verify on;

        # Keep-alive
        keepalive_timeout 70;
        keepalive_requests 100;

        location / {
            proxy_pass http://backend;
            proxy_http_version 1.1;
            proxy_set_header Connection "";
        }
    }
}

15.11 Múltiples Certificados (SNI)

Indicación de Nombre de Servidor (SNI)

#============================================#
# MÚLTIPLES DOMINIOS CON CERTIFICADOS DIFERENTES
#============================================#

# Sitio 1
server {
    listen 443 ssl http2;
    server_name site1.example.com;

    ssl_certificate     /etc/pki/tls/certs/site1.crt;
    ssl_certificate_key /etc/pki/tls/private/site1.key;

    root /var/www/site1;
}

# Sitio 2
server {
    listen 443 ssl http2;
    server_name site2.example.com;

    ssl_certificate     /etc/pki/tls/certs/site2.crt;
    ssl_certificate_key /etc/pki/tls/private/site2.key;

    root /var/www/site2;
}

# Sitio 3 (comodín)
server {
    listen 443 ssl http2;
    server_name *.apps.example.com;

    ssl_certificate     /etc/pki/tls/certs/wildcard.apps.crt;
    ssl_certificate_key /etc/pki/tls/private/wildcard.apps.key;

    root /var/www/apps;
}

15.12 Autenticación de Certificado de Cliente

TLS Mutuo (mTLS) con NGINX

#============================================#
# NGINX CON AUTENTICACIÓN DE CERTIFICADO DE CLIENTE
#============================================#

server {
    listen 443 ssl http2;
    server_name secure.example.com;

    # Certificados del servidor
    ssl_certificate     /etc/pki/tls/certs/secure.crt;
    ssl_certificate_key /etc/pki/tls/private/secure.key;

    # Verificación de certificado de cliente
    ssl_client_certificate /etc/pki/tls/certs/client-ca.crt;
    ssl_verify_client on;  # o 'optional'
    ssl_verify_depth 3;

    # Pasar info de cert de cliente a backend
    location / {
        proxy_pass http://backend;
        proxy_set_header X-SSL-Client-Cert $ssl_client_cert;
        proxy_set_header X-SSL-Client-DN $ssl_client_s_dn;
        proxy_set_header X-SSL-Client-Verify $ssl_client_verify;
    }
}

15.13 Probar NGINX HTTPS

Suite de Pruebas Comprehensiva

#============================================#
# PRUEBAS NGINX HTTPS
#============================================#

# Prueba 1: Sintaxis de configuración
sudo nginx -t
# nginx: configuration file /etc/nginx/nginx.conf test is successful

# Prueba 2: Mostrar configuración efectiva
sudo nginx -T | grep -A10 "server_name www.example.com"

# Prueba 3: Puerto escuchando
ss -tlnp | grep nginx

# Prueba 4: HTTPS local
curl -vk https://localhost/

# Prueba 5: Basado en hostname
curl -v https://www.example.com/

# Prueba 6: Verificar certificado desde servidor
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>&1 | \
  openssl x509 -noout -subject -dates

# Prueba 7: TLS 1.2
openssl s_client -connect www.example.com:443 -tls1_2

# Prueba 8: TLS 1.3 (RHEL 8+)
openssl s_client -connect www.example.com:443 -tls1_3

# Prueba 9: Soporte HTTP/2
curl -I --http2 https://www.example.com/

# Prueba 10: Encabezados de seguridad
curl -I https://www.example.com/ | grep -i "strict-transport"

15.14 Problemas Comunes y Soluciones

Problema 1: “Permission denied” en Clave Privada

# Síntoma
sudo nginx -t
# nginx: [emerg] SSL_CTX_use_PrivateKey_file() failed (SSL: error:0200100D:system library:fopen:Permission denied)

# Verificar permisos
ls -l /etc/pki/tls/private/nginx.key

# Solución
sudo chmod 600 /etc/pki/tls/private/nginx.key
sudo chown root:nginx /etc/pki/tls/private/nginx.key

# Si problema SELinux:
sudo restorecon -v /etc/pki/tls/private/nginx.key

Problema 2: Cadena de Certificado No Enviada

# Probar desde cliente
openssl s_client -connect www.example.com:443 -showcerts

# Si muestra solo cert del servidor (no intermedios):
# Crear paquete de certificado
cat server.crt intermediate.crt > /etc/pki/tls/certs/bundle.crt

# Actualizar configuración NGINX
ssl_certificate /etc/pki/tls/certs/bundle.crt;

# Recargar
sudo systemctl reload nginx

Problema 3: OCSP Stapling No Funciona

# Probar OCSP stapling
openssl s_client -connect www.example.com:443 -status -tlsextdebug 2>&1 | grep -A17 "OCSP"

# Causas comunes:
# 1. No hay resolver configurado
# Solución: Agregar a nginx.conf:
resolver 8.8.8.8 8.8.4.4 valid=300s;

# 2. Falta cadena de certificados confiables
# Solución:
ssl_trusted_certificate /etc/pki/tls/certs/chain.crt;

# 3. Firewall bloquea solicitudes OCSP
# Solución: Permitir HTTPS saliente

15.15 Mejores Prácticas de Seguridad

Lista de Verificación

✅ Usar solo TLS 1.2+ (deshabilitar 1.0/1.1)
✅ Cifrados fuertes con forward secrecy (ECDHE)
✅ Habilitar HSTS con max-age largo
✅ Habilitar OCSP Stapling
✅ Usar HTTP/2
✅ Permisos de archivo apropiados (600 para claves)
✅ Contextos SELinux correctos
✅ Validez de certificado ≤ 90 días con renovación automática
✅ Incluir SANs comprehensivos
✅ Encabezados de seguridad habilitados

15.16 Conclusiones Clave

1. NGINX disponible en AppStream (RHEL 8+) o EPEL (RHEL 7)
2. Crypto-policies simplifican config en RHEL 8/9/10
3. certmonger se integra bien con recarga automática
4. certbot requiere EPEL en todas las versiones RHEL
5. SNI habilita múltiples certs en la misma IP
6. mTLS posible para autenticación de cliente
7. Probar exhaustivamente - sintaxis, conectividad, seguridad

Tarjeta de Referencia Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA NGINX HTTPS                                │
├──────────────────────────────────────────────────────────────┤
│ Instalar:     dnf install nginx (RHEL 8/9/10)                │
│               yum install epel-release nginx (RHEL 7)        │
│                                                              │
│ Config:       /etc/nginx/nginx.conf                          │
│               /etc/nginx/conf.d/*.conf                       │
│                                                              │
│ SSL básico:   listen 443 ssl http2;                          │
│               ssl_certificate /path/to/cert.crt;             │
│               ssl_certificate_key /path/to/key.key;          │
│                                                              │
│ Probar:       nginx -t                                       │
│ Recargar:     systemctl reload nginx                         │
│ Logs:         /var/log/nginx/error.log                       │
│                                                              │
│ certbot:      certbot --nginx (¡requiere EPEL!)              │
│ certmonger:   ipa-getcert ... -C "systemctl reload nginx"    │
└──────────────────────────────────────────────────────────────┘

⚠️ certbot requiere EPEL en todas las versiones RHEL
✅ Usar certmonger para entornos empresariales

🧪 Laboratorio Práctico

Lab 07: Configuración HTTPS de NGINX

Configura NGINX con SSL/TLS y mejores prácticas de seguridad

• 📁 Ubicación: labs/es_ES/07-nginx-https/
• ⏱️ Tiempo: 30-35 minutos
• 🎯 Nivel: Intermedio

Navegación del Capítulo

Capítulo 16: TLS en Servidor de Correo Postfix

Seguridad del Email: Aprende cómo configurar cifrado TLS para servidores de correo Postfix en RHEL, protegiendo las comunicaciones de email con certificados.

16.1 Resumen de Postfix en RHEL

Nombre del Paquete: postfix Ubicación de Config: /etc/postfix/main.cf Ruta de Certificados: /etc/pki/tls/certs/ Ruta de Claves: /etc/pki/tls/private/ Puertos: 25 (SMTP), 465 (SMTPS), 587 (Submission con STARTTLS)

¿Por Qué TLS para Email?

• ✅ Cifrar email en tránsito (prevenir escucha clandestina)
• ✅ Autenticar servidores de correo (prevenir suplantación)
• ✅ Cumplir requisitos de cumplimiento (HIPAA, PCI-DSS)
• ✅ Prevenir spam/phishing (SPF, DKIM, DMARC funcionan mejor con TLS)

16.2 Instalación

Todas las Versiones RHEL

#============================================#
# INSTALAR POSTFIX
#============================================#

# Instalar Postfix
sudo dnf install postfix -y

# Detener y deshabilitar Sendmail (si está presente)
sudo systemctl stop sendmail 2>/dev/null
sudo systemctl disable sendmail 2>/dev/null

# Habilitar Postfix
sudo systemctl enable postfix
sudo systemctl start postfix

# Abrir firewall
sudo firewall-cmd --permanent --add-service=smtp
sudo firewall-cmd --permanent --add-service=smtps
sudo firewall-cmd --permanent --add-service=smtp-submission
sudo firewall-cmd --reload

# Verificar
systemctl status postfix
ss -tlnp | grep -E ':(25|465|587)'

16.3 Configuración TLS Lado Servidor

Recibir Correo con TLS (SMTPD)

#============================================#
# /etc/postfix/main.cf - TLS DE SERVIDOR (RECEPCIÓN)
#============================================#

# Archivos de certificado
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.example.com.crt
smtpd_tls_key_file = /etc/pki/tls/private/mail.example.com.key
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt

# Nivel de seguridad TLS
smtpd_tls_security_level = may  # o 'encrypt' para requerir TLS

# Logging
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes

# Caché de sesión (rendimiento)
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

# Autenticación - solo sobre TLS
smtpd_tls_auth_only = yes

# RHEL 7: Especificar protocolos manualmente
# smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
# smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# RHEL 8/9/10: Crypto-policies manejan protocolos automáticamente
# (no necesitas especificar smtpd_tls_protocols)

Niveles de Seguridad Explicados:

16.4 Configuración TLS Lado Cliente

Enviar Correo con TLS (SMTP)

#============================================#
# /etc/postfix/main.cf - TLS DE CLIENTE (ENVÍO)
#============================================#

# Archivos de certificado (opcional para cliente)
smtp_tls_cert_file = /etc/pki/tls/certs/mail.example.com.crt
smtp_tls_key_file = /etc/pki/tls/private/mail.example.com.key
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt

# Nivel de seguridad TLS para salida
smtp_tls_security_level = may  # o 'encrypt' para requerir

# Logging
smtp_tls_loglevel = 1

# Caché de sesión
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# RHEL 7: Especificar protocolos
# smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
# smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# RHEL 8/9/10: Crypto-policies lo manejan

16.5 Configuración Completa TLS de Postfix

Ejemplo de Configuración Completa

#============================================#
# CONFIGURACIÓN TLS COMPLETA DE POSTFIX
#============================================#

# 1. Generar certificado y clave
sudo openssl genpkey -algorithm RSA \
  -out /etc/pki/tls/private/mail.example.com.key \
  -pkeyopt rsa_keygen_bits:2048

sudo chmod 600 /etc/pki/tls/private/mail.example.com.key

# 2. Generar CSR
sudo openssl req -new \
  -key /etc/pki/tls/private/mail.example.com.key \
  -out /tmp/mail.example.com.csr \
  -subj "/CN=mail.example.com" \
  -addext "subjectAltName=DNS:mail.example.com,DNS:smtp.example.com"

# 3. Obtener certificado de CA, instalarlo
sudo cp mail.example.com.crt /etc/pki/tls/certs/
sudo chmod 644 /etc/pki/tls/certs/mail.example.com.crt

# 4. Editar /etc/postfix/main.cf
sudo vi /etc/postfix/main.cf

# Agregar configuración TLS (ver secciones 16.3 y 16.4)

# 5. Probar configuración
sudo postfix check

# 6. Recargar Postfix
sudo systemctl reload postfix

# 7. Probar SMTP TLS
openssl s_client -starttls smtp -connect mail.example.com:25

16.6 Configuración SMTPS (Puerto 465)

Habilitar Servicio SMTPS

#============================================#
# /etc/postfix/master.cf - HABILITAR SMTPS
#============================================#

# Descomentar o agregar servicio SMTPS (puerto 465)
smtps     inet  n       -       n       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

# Recargar
sudo systemctl reload postfix

# Verificar
ss -tlnp | grep :465

Probar SMTPS

# Conectar a SMTPS (TLS inmediato, sin STARTTLS)
openssl s_client -connect mail.example.com:465

# Debería mostrar handshake TLS inmediatamente

16.7 Puerto de Submission (587) con STARTTLS

Habilitar Servicio Submission

#============================================#
# /etc/postfix/master.cf - HABILITAR SUBMISSION
#============================================#

# Descomentar o agregar servicio submission (puerto 587)
submission inet n       -       n       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

# Recargar
sudo systemctl reload postfix

# Verificar
ss -tlnp | grep :587

Probar Puerto Submission

# Probar STARTTLS en puerto 587
openssl s_client -starttls smtp -connect mail.example.com:587

# Debería mostrar:
# STARTTLS
# 220 2.0.0 Ready to start TLS

16.8 Integración con certmonger

Gestión Automatizada de Certificados para Postfix

#============================================#
# CERTMONGER + POSTFIX
#============================================#

# Instalar certmonger
sudo dnf install certmonger
sudo systemctl enable --now certmonger

# Solicitar certificado de FreeIPA
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/mail.example.com.crt \
  -k /etc/pki/tls/private/mail.example.com.key \
  -D mail.example.com \
  -K host/mail.example.com@REALM \
  -C "postfix reload"  # Auto-recargar Postfix después de renovación

# Verificar estado
sudo getcert list

# ¡Postfix usa automáticamente el certificado renovado!

16.9 Autenticación de Certificado de Cliente

Requerir Certificados de Cliente (mTLS para SMTP)

#============================================#
# /etc/postfix/main.cf - AUTENTICACIÓN CERT CLIENTE
#============================================#

# Certificados de servidor (como antes)
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtpd_tls_key_file = /etc/pki/tls/private/mail.key

# Verificación de certificado de cliente
smtpd_tls_CAfile = /etc/pki/tls/certs/client-ca.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_req_ccert = yes  # Requerir cert de cliente

# Mapear certificado a usuario
smtpd_recipient_restrictions =
  permit_tls_clientcerts,
  reject

# Recargar
sudo postfix reload

Probar con certificado de cliente:

openssl s_client -starttls smtp \
  -connect mail.example.com:25 \
  -cert client.crt \
  -key client.key \
  -CAfile ca.crt

16.10 Solución de Problemas Postfix TLS

Comandos de Diagnóstico

#============================================#
# SOLUCIÓN DE PROBLEMAS POSTFIX TLS
#============================================#

# Verificar configuración de Postfix
sudo postconf | grep -i tls

# Probar sintaxis de configuración
sudo postfix check

# Ver ajustes TLS específicos
sudo postconf smtpd_tls_cert_file smtpd_tls_key_file

# Verificar que existan archivos de certificado
ls -l /etc/pki/tls/certs/mail.crt
ls -l /etc/pki/tls/private/mail.key

# Verificar coincidencia par cert/clave
CERT_MOD=$(openssl x509 -noout -modulus -in /etc/pki/tls/certs/mail.crt | openssl md5)
KEY_MOD=$(openssl rsa -noout -modulus -in /etc/pki/tls/private/mail.key | openssl md5)
[ "$CERT_MOD" = "$KEY_MOD" ] && echo "✅ Coincide" || echo "❌ ¡Desajuste!"

# Probar SMTP STARTTLS
openssl s_client -starttls smtp -connect mail.example.com:25

# Probar SMTPS (puerto 465)
openssl s_client -connect mail.example.com:465

# Verificar logs
sudo tail -f /var/log/maillog | grep -i tls

# Verificar cola de Postfix
mailq

# Logging verboso (para solución de problemas)
sudo postconf smtpd_tls_loglevel=2
sudo postfix reload
# Verificar /var/log/maillog para info TLS detallada

Problemas Comunes de Postfix TLS

16.11 Consideraciones Específicas por Versión

RHEL 7

#============================================#
# POSTFIX TLS - ESPECÍFICO RHEL 7
#============================================#

# /etc/postfix/main.cf

# DEBE especificar manualmente protocolos TLS
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# DEBE especificar manualmente cifrados
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high

smtp_tls_mandatory_ciphers = high
smtp_tls_ciphers = high

# Excluir cifrados débiles
smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA

RHEL 8/9/10

#============================================#
# POSTFIX TLS - RHEL 8/9/10 CON CRYPTO-POLICIES
#============================================#

# /etc/postfix/main.cf

# Archivos de certificado
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtpd_tls_key_file = /etc/pki/tls/private/mail.key
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt

# Ajustes TLS (¡crypto-policies manejan protocolos/cifrados!)
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_loglevel = 1

# TLS de cliente
smtp_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtp_tls_key_file = /etc/pki/tls/private/mail.key
smtp_tls_security_level = may
smtp_tls_loglevel = 1

# ¡Eso es todo! Mucho más simple que RHEL 7
# crypto-policies configuran automáticamente versiones TLS y cifrados

Diferencia Clave: ¡RHEL 8+ depende de crypto-policies, haciendo la configuración mucho más simple!

16.12 Probar Postfix TLS

Suite de Pruebas Comprehensiva

#============================================#
# PRUEBAS POSTFIX TLS
#============================================#

# Prueba 1: STARTTLS en puerto 25
openssl s_client -starttls smtp -connect mail.example.com:25

# Buscar:
# - "250-STARTTLS" en capacidades del servidor
# - Handshake TLS exitoso
# - Detalles del certificado

# Prueba 2: SMTPS en puerto 465 (TLS directo)
openssl s_client -connect mail.example.com:465

# Prueba 3: Puerto submission 587 con STARTTLS
openssl s_client -starttls smtp -connect mail.example.com:587

# Prueba 4: Verificar certificado desde servidor
echo "QUIT" | openssl s_client -starttls smtp -connect mail.example.com:25 2>&1 | \
  openssl x509 -noout -subject -dates

# Prueba 5: Enviar email de prueba
echo "Test email" | mail -s "Prueba TLS" test@example.com

# Prueba 6: Verificar TLS en logs
sudo tail -f /var/log/maillog | grep TLS

# Prueba 7: Verificar si TLS se está usando
sudo postconf | grep -i tls | grep -i level

16.13 Mejores Prácticas de Seguridad

Configuración Postfix TLS Fortalecida

#============================================#
# CONFIGURACIÓN POSTFIX TLS FORTALECIDA
#============================================#

# /etc/postfix/main.cf

# TLS de servidor (recibir correo)
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtpd_tls_key_file = /etc/pki/tls/private/mail.key
smtpd_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt

# REQUERIR TLS para autenticación
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes

# TLS de cliente (enviar correo)
smtp_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtp_tls_key_file = /etc/pki/tls/private/mail.key
smtp_tls_security_level = may

# RHEL 7: Deshabilitar manualmente protocolos débiles
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# Obligatorio para conexiones autenticadas
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# Ajustes de cifrado (RHEL 7)
smtpd_tls_mandatory_ciphers = high
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA

# Caché de sesión
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# Logging mejorado (temporal para solución de problemas)
smtpd_tls_loglevel = 1
smtp_tls_loglevel = 1

# Rendimiento
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

16.14 Dovecot IMAP/POP3 con TLS

Configuración de Dovecot

Aunque este capítulo se enfoca en Postfix (SMTP), Dovecot a menudo se ejecuta junto para IMAP/POP3:

#============================================#
# DOVECOT TLS (/etc/dovecot/conf.d/10-ssl.conf)
#============================================#

# Habilitar SSL
ssl = required

# Archivos de certificado
ssl_cert = </etc/pki/tls/certs/mail.example.com.crt
ssl_key = </etc/pki/tls/private/mail.example.com.key

# CA para verificación de cert de cliente (opcional)
#ssl_ca = </etc/pki/tls/certs/ca-bundle.crt

# RHEL 8/9/10: crypto-policies lo manejan

# Protocolos TLS (RHEL 7)
#ssl_min_protocol = TLSv1.2

# Preferencias de suite de cifrado
#ssl_cipher_list = HIGH:!aNULL:!MD5

# Recargar
sudo systemctl reload dovecot

Probar IMAPS:

openssl s_client -connect mail.example.com:993

# Probar POP3S
openssl s_client -connect mail.example.com:995

16.15 Escenarios Comunes

Escenario 1: TLS Oportunista (Estándar)

Objetivo: Aceptar conexiones cifradas y no cifradas

# /etc/postfix/main.cf
smtpd_tls_security_level = may  # TLS opcional
smtp_tls_security_level = may   # TLS opcional

# Por qué: Máxima compatibilidad
# Desventaja: Algunas conexiones pueden no estar cifradas

Escenario 2: TLS Obligatorio (Alta Seguridad)

Objetivo: Rechazar conexiones no cifradas

# /etc/postfix/main.cf
smtpd_tls_security_level = encrypt  # REQUERIR TLS
smtp_tls_security_level = encrypt   # REQUERIR TLS

# Por qué: Máxima seguridad
# Desventaja: Sistemas antiguos pueden fallar al conectar

Escenario 3: Certificado de Cliente para Relay

Objetivo: Permitir relay solo con certificado de cliente válido

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtpd_tls_key_file = /etc/pki/tls/private/mail.key
smtpd_tls_CAfile = /etc/pki/tls/certs/client-ca.crt

smtpd_tls_ask_ccert = yes
smtpd_tls_req_ccert = yes

smtpd_recipient_restrictions =
  permit_tls_clientcerts,
  reject_unauth_destination

# Solo clientes con cert válido de client-ca.crt pueden hacer relay

16.16 Monitorear Postfix TLS

Qué Monitorear

#============================================#
# MONITOREO POSTFIX TLS
#============================================#

# Verificar uso de TLS en logs
sudo grep "TLS connection established" /var/log/maillog | tail -20

# Contar conexiones TLS vs no-TLS
sudo grep "connect from" /var/log/maillog | grep -c "TLS"

# Verificar errores TLS
sudo grep "TLS" /var/log/maillog | grep -i error

# Monitorear expiración de certificado
openssl x509 -in /etc/pki/tls/certs/mail.crt -noout -checkend $((86400*30))

# Estado de certmonger (si se usa)
sudo getcert list -f /etc/pki/tls/certs/mail.crt

# Verificar cola de errores TLS
mailq

Script de Monitoreo

#!/bin/bash
# monitor-postfix-tls.sh

echo "=== Monitoreo TLS de Postfix ==="

# Expiración de certificado
echo "1. Expiración de Certificado:"
openssl x509 -in /etc/pki/tls/certs/mail.crt -noout -enddate

# Conexiones TLS hoy
echo ""
echo "2. Conexiones TLS Hoy:"
sudo grep "$(date '+%b %e')" /var/log/maillog | grep "TLS connection" | wc -l

# Errores TLS hoy
echo ""
echo "3. Errores TLS Hoy:"
sudo grep "$(date '+%b %e')" /var/log/maillog | grep -i "tls.*error" | tail -5

# Estado del servicio
echo ""
echo "4. Estado de Postfix:"
systemctl is-active postfix

# Puertos escuchando
echo ""
echo "5. Escuchando en:"
ss -tlnp | grep master | grep -E ':(25|465|587)'

16.17 Problemas Comunes y Soluciones

Problema 1: Certificado No Confiable por Clientes

Síntoma: Los clientes obtienen advertencias de “certificado no confiable”

Diagnóstico:

# Probar cadena de certificado
openssl s_client -starttls smtp -connect mail.example.com:25 -showcerts

# Verificar si se incluyen certificados intermedios
sudo postconf smtpd_tls_cert_file
# Debería incluir cadena completa o usar smtpd_tls_chain_files

Solución:

# Opción 1: Incluir cadena en archivo de certificado
cat server.crt intermediate.crt > /etc/pki/tls/certs/mail-chain.crt

# Actualizar configuración
sudo postconf -e 'smtpd_tls_cert_file = /etc/pki/tls/certs/mail-chain.crt'
sudo postfix reload

# Opción 2: Usar archivo de cadena separado (Postfix 3.4+)
sudo postconf -e 'smtpd_tls_chain_files = /etc/pki/tls/certs/chain.crt'

Problema 2: “Permission denied” en Clave Privada

Síntoma: Postfix no inicia, logs muestran error de permiso

Solución:

# Establecer permisos correctos
sudo chmod 600 /etc/pki/tls/private/mail.key
sudo chown root:postfix /etc/pki/tls/private/mail.key

# Corregir contexto SELinux
sudo restorecon -v /etc/pki/tls/private/mail.key

# Reiniciar Postfix
sudo systemctl restart postfix

Problema 3: TLS No Ofrecido a Clientes

Síntoma: STARTTLS no mostrado en respuesta EHLO

Diagnóstico:

# Telnet al servidor
telnet mail.example.com 25
# Escribir: EHLO test
# Debería mostrar: 250-STARTTLS

# Si no se muestra, verificar configuración
sudo postconf smtpd_tls_security_level
# Debería ser 'may' o 'encrypt', no 'none'

Solución:

sudo postconf -e 'smtpd_tls_security_level = may'
sudo postfix reload

16.18 Tabla de Comparación de Versiones

16.19 Script de Configuración Rápida

#!/bin/bash
# setup-postfix-tls.sh - Configuración completa Postfix TLS

DOMAIN="example.com"
HOSTNAME="mail.$DOMAIN"

echo "=== Configuración Postfix TLS para $HOSTNAME ==="

# 1. Instalar Postfix
sudo dnf install -y postfix

# 2. Generar certificado (o usar certmonger)
sudo openssl genpkey -algorithm RSA \
  -out /etc/pki/tls/private/$HOSTNAME.key \
  -pkeyopt rsa_keygen_bits:2048

sudo chmod 600 /etc/pki/tls/private/$HOSTNAME.key

# 3. Generar autofirmado para pruebas (¡reemplazar con cert apropiado!)
sudo openssl req -new -x509 -days 365 \
  -key /etc/pki/tls/private/$HOSTNAME.key \
  -out /etc/pki/tls/certs/$HOSTNAME.crt \
  -subj "/CN=$HOSTNAME" \
  -addext "subjectAltName=DNS:$HOSTNAME,DNS:smtp.$DOMAIN"

# 4. Configurar Postfix
sudo postconf -e "smtpd_tls_cert_file = /etc/pki/tls/certs/$HOSTNAME.crt"
sudo postconf -e "smtpd_tls_key_file = /etc/pki/tls/private/$HOSTNAME.key"
sudo postconf -e "smtpd_tls_security_level = may"
sudo postconf -e "smtpd_tls_auth_only = yes"
sudo postconf -e "smtpd_tls_loglevel = 1"

sudo postconf -e "smtp_tls_cert_file = /etc/pki/tls/certs/$HOSTNAME.crt"
sudo postconf -e "smtp_tls_key_file = /etc/pki/tls/private/$HOSTNAME.key"
sudo postconf -e "smtp_tls_security_level = may"

# 5. Abrir firewall
sudo firewall-cmd --permanent --add-service=smtp
sudo firewall-cmd --permanent --add-service=smtps
sudo firewall-cmd --permanent --add-service=smtp-submission
sudo firewall-cmd --reload

# 6. Iniciar Postfix
sudo systemctl enable postfix
sudo systemctl restart postfix

# 7. Probar
echo "Probando SMTP STARTTLS..."
echo "QUIT" | openssl s_client -starttls smtp -connect localhost:25 2>&1 | grep -E "(CONNECTED|subject=)"

echo "✅ ¡Configuración Postfix TLS completa!"
echo "⚠️ Reemplazar cert autofirmado con certificado apropiado de CA"

16.20 Conclusiones Clave

1. Postfix soporta TLS en puertos 25 (STARTTLS), 465 (SMTPS), 587 (Submission)
2. RHEL 7 requiere configuración TLS manual (protocolos, cifrados)
3. RHEL 8+ usa crypto-policies (¡mucho más simple!)
4. Niveles de seguridad: none, may, encrypt, dane
5. certmonger funciona excelente con Postfix
6. Siempre probar con openssl s_client -starttls smtp
7. Monitorear logs para errores TLS

Tarjeta de Referencia Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA POSTFIX TLS                                │
├──────────────────────────────────────────────────────────────┤
│ Config:       /etc/postfix/main.cf                           │
│ Certs:        smtpd_tls_cert_file = /path/to/cert.crt        │
│ Claves:       smtpd_tls_key_file = /path/to/key.key          │
│ Seguridad:    smtpd_tls_security_level = may|encrypt         │
│                                                              │
│ Probar:       openssl s_client -starttls smtp -connect :25   │
│ Recargar:     postfix reload                                 │
│ Verificar:    postfix check                                  │
│ Logs:         tail -f /var/log/maillog | grep TLS            │
│                                                              │
│ Puertos:      25 (SMTP+STARTTLS)                             │
│               465 (SMTPS - TLS directo)                      │
│               587 (Submission con STARTTLS)                  │
│                                                              │
│ certmonger:   ipa-getcert ... -C "postfix reload"            │
└──────────────────────────────────────────────────────────────┘

⚠️ RHEL 7: Configuración manual de protocolo/cifrado necesaria
✅ RHEL 8/9/10: Crypto-policies manejan ajustes TLS

🧪 Laboratorio Práctico

Lab 08: TLS de Postfix

Configura TLS para servidor de correo Postfix

• 📁 Ubicación: labs/es_ES/08-postfix-tls/
• ⏱️ Tiempo: 30 minutos
• 🎯 Nivel: Intermedio

Navegación del Capítulo

Capítulo 17: OpenLDAP y Servicios de Directorio

Directorio Empresarial: Aprende cómo asegurar servicios de directorio OpenLDAP con TLS/SSL en RHEL, protegiendo la autenticación de usuarios y consultas de directorio.

17.1 LDAP vs LDAPS vs STARTTLS

Tres Formas de Asegurar LDAP

Recomendación: Usar LDAPS (puerto 636) para simplicidad y seguridad.

17.2 Instalación de OpenLDAP

Todas las Versiones RHEL

#============================================#
# INSTALAR SERVIDOR OPENLDAP
#============================================#

# Instalar servidor OpenLDAP
sudo dnf install openldap-servers openldap-clients -y

# Iniciar y habilitar
sudo systemctl enable slapd
sudo systemctl start slapd

# Abrir firewall
sudo firewall-cmd --permanent --add-service=ldap
sudo firewall-cmd --permanent --add-service=ldaps
sudo firewall-cmd --reload

# Verificar
systemctl status slapd
ss -tlnp | grep -E ':(389|636)'

17.3 Generar Certificados para LDAP

Requisitos del Certificado

Los certificados LDAP deben incluir:

• ✅ CN coincidiendo con hostname del servidor LDAP
• ✅ SANs con FQDN del servidor LDAP
• ✅ Server Authentication key usage
• ✅ Cadena de confianza válida

#============================================#
# GENERAR CERTIFICADO DE SERVIDOR LDAP
#============================================#

# Paso 1: Generar clave privada
sudo openssl genpkey -algorithm RSA \
  -out /etc/openldap/certs/ldap.key \
  -pkeyopt rsa_keygen_bits:2048

# Paso 2: Establecer permisos (¡importante!)
sudo chmod 600 /etc/openldap/certs/ldap.key
sudo chown ldap:ldap /etc/openldap/certs/ldap.key

# Paso 3: Generar CSR
sudo openssl req -new \
  -key /etc/openldap/certs/ldap.key \
  -out /tmp/ldap.csr \
  -subj "/CN=ldap.example.com" \
  -addext "subjectAltName=DNS:ldap.example.com,DNS:dir.example.com"

# Paso 4: Obtener certificado de CA

# Paso 5: Instalar certificado
sudo cp ldap.crt /etc/openldap/certs/
sudo chmod 644 /etc/openldap/certs/ldap.crt
sudo chown ldap:ldap /etc/openldap/certs/ldap.crt

# Paso 6: Instalar certificado CA
sudo cp ca.crt /etc/openldap/certs/
sudo chmod 644 /etc/openldap/certs/ca.crt

17.4 Configuración TLS de OpenLDAP

Método 1: cn=config (Configuración Dinámica)

#============================================#
# CONFIGURAR TLS CON cn=config (PREFERIDO)
#============================================#

# Crear archivo LDIF
cat > /tmp/tls-config.ldif << EOF
dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/ldap.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.key
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/ca.crt
-
replace: olcTLSProtocolMin
olcTLSProtocolMin: 3.2
EOF

# Aplicar configuración
sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/tls-config.ldif

# Reiniciar slapd
sudo systemctl restart slapd

# Verificar
sudo slapcat -b "cn=config" | grep -i tls

Método 2: slapd.conf (Legacy)

#============================================#
# CONFIGURAR TLS CON slapd.conf (LEGACY)
#============================================#

# Editar /etc/openldap/slapd.conf

TLSCertificateFile      /etc/openldap/certs/ldap.crt
TLSCertificateKeyFile   /etc/openldap/certs/ldap.key
TLSCACertificateFile    /etc/openldap/certs/ca.crt

# RHEL 7: Especificar manualmente versión TLS
TLSProtocolMin          1.2

# Reiniciar
sudo systemctl restart slapd

17.5 Configuración de Cliente

Configurar Cliente LDAP para TLS

#============================================#
# /etc/openldap/ldap.conf - CONFIG CLIENTE
#============================================#

# URI del servidor (usar ldaps:// para puerto 636)
URI ldaps://ldap.example.com

# Certificado CA para validación
TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt

# Verificación de certificado
TLS_REQCERT demand  # requerir certificado válido

# RHEL 7: Especificar versión TLS mínima
# TLS_PROTOCOL_MIN 1.2

Probar Conexión de Cliente LDAP

#============================================#
# PROBAR CONEXIÓN DE CLIENTE LDAPS
#============================================#

# Probar LDAPS (puerto 636)
ldapsearch -H ldaps://ldap.example.com:636 \
  -D "cn=admin,dc=example,dc=com" \
  -W \
  -b "dc=example,dc=com" \
  "(objectClass=*)"

# Probar LDAP con STARTTLS (puerto 389)
ldapsearch -H ldap://ldap.example.com:389 -ZZ \
  -D "cn=admin,dc=example,dc=com" \
  -W \
  -b "dc=example,dc=com"

# -ZZ fuerza STARTTLS (falla si no disponible)
# -Z intenta STARTTLS (continúa sin él si no disponible)

17.6 Integración con FreeIPA

Nota: FreeIPA se cubre en detalle en el Capítulo 19. Esto es un resumen rápido.

FreeIPA Maneja LDAPS Automáticamente

#============================================#
# LDAPS DE FREEIPA (¡AUTOMÁTICO!)
#============================================#

# FreeIPA configura LDAPS automáticamente
# ¡No se necesita configuración manual de certificado!

# Probar LDAPS de FreeIPA
ldapsearch -H ldaps://ipa.example.com:636 \
  -D "uid=admin,cn=users,cn=accounts,dc=example,dc=com" \
  -W \
  -b "dc=example,dc=com"

# Certificados de FreeIPA gestionados por certmonger automáticamente
sudo getcert list | grep -A10 "Directory Server"

17.7 Probar OpenLDAP TLS

Pruebas Comprehensivas

#============================================#
# PRUEBAS OPENLDAP TLS
#============================================#

# Prueba 1: Verificar si slapd está escuchando
ss -tlnp | grep slapd
# Debería mostrar puertos 389 y/o 636

# Prueba 2: Probar conexión LDAPS con OpenSSL
openssl s_client -connect ldap.example.com:636

# Buscar:
# - Handshake TLS exitoso
# - Detalles del certificado
# - Verify return code: 0 (ok)

# Prueba 3: Probar con ldapsearch (anónimo)
ldapsearch -H ldaps://ldap.example.com:636 \
  -x -b "" -s base "(objectClass=*)" namingContexts

# Prueba 4: Probar consulta autenticada
ldapsearch -H ldaps://ldap.example.com:636 \
  -D "cn=admin,dc=example,dc=com" \
  -W \
  -b "dc=example,dc=com" \
  "(uid=*)"

# Prueba 5: Probar STARTTLS
ldapsearch -H ldap://ldap.example.com:389 -ZZ \
  -x -b "" -s base

# Prueba 6: Verificar certificado desde servidor
echo | openssl s_client -connect ldap.example.com:636 2>&1 | \
  openssl x509 -noout -subject -issuer -dates

17.8 Solución de Problemas OpenLDAP TLS

Comandos de Diagnóstico

#============================================#
# DIAGNÓSTICO OPENLDAP TLS
#============================================#

# Verificar configuración de slapd
sudo slapcat -b "cn=config" | grep -i tls

# Verificar archivos de certificado
sudo ls -lZ /etc/openldap/certs/

# Verificar permisos
# La clave debería ser legible por el usuario 'ldap'
sudo -u ldap cat /etc/openldap/certs/ldap.key >/dev/null && \
  echo "✅ Clave legible" || echo "❌ Permission denied"

# Verificar contexto SELinux
ls -Z /etc/openldap/certs/*.{crt,key}

# Verificar logs de slapd
sudo journalctl -u slapd -f

# Probar con OpenSSL verboso
openssl s_client -connect ldap.example.com:636 -showcerts -debug

# Probar STARTTLS
ldapsearch -H ldap://ldap.example.com:389 -ZZ -d 1

Problemas Comunes de OpenLDAP TLS

17.9 Autenticación de Certificado de Cliente

Requerir Certificados de Cliente

#============================================#
# OPENLDAP CON AUTENTICACIÓN CERT CLIENTE
#============================================#

# Configuración de servidor (cn=config)
cat > /tmp/client-cert.ldif << EOF
dn: cn=config
changetype: modify
add: olcTLSVerifyClient
olcTLSVerifyClient: demand
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/client-ca.crt
EOF

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/client-cert.ldif

# Reiniciar
sudo systemctl restart slapd

Conexión de cliente con certificado:

# El cliente debe proporcionar certificado
ldapsearch -H ldaps://ldap.example.com:636 \
  -x -b "dc=example,dc=com" \
  -ZZ

# Configurar cert de cliente en /etc/openldap/ldap.conf:
TLS_CERT /etc/openldap/certs/client.crt
TLS_KEY /etc/openldap/certs/client.key

17.10 Consideraciones Específicas por Versión

RHEL 7

#============================================#
# OPENLDAP TLS - RHEL 7
#============================================#

# Especificación manual de protocolo TLS
# En slapd.conf o cn=config:
TLSProtocolMin 1.2

# O con cn=config:
olcTLSProtocolMin: 3.2  # 3.1=TLS1.0, 3.2=TLS1.1, 3.3=TLS1.2

# Configuración manual de cifrado
TLSCipherSuite HIGH:!aNULL:!MD5:!3DES

# Probar
openssl s_client -connect ldap.example.com:636 -tls1_2

RHEL 8/9/10

#============================================#
# OPENLDAP TLS - RHEL 8/9/10
#============================================#

# Crypto-policies configuran TLS automáticamente
# ¡No necesitas especificar TLSProtocolMin o cifrados!

# Solo configurar certificados:
olcTLSCertificateFile: /etc/openldap/certs/ldap.crt
olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.key
olcTLSCACertificateFile: /etc/openldap/certs/ca.crt

# Crypto-policy maneja el resto
update-crypto-policies --show

17.11 certmonger con OpenLDAP

Gestión Automatizada de Certificados

#============================================#
# CERTMONGER + OPENLDAP
#============================================#

# Instalar certmonger
sudo dnf install certmonger
sudo systemctl enable --now certmonger

# Solicitar certificado de FreeIPA
sudo ipa-getcert request \
  -f /etc/openldap/certs/ldap.crt \
  -k /etc/openldap/certs/ldap.key \
  -D ldap.example.com \
  -K ldap/ldap.example.com@REALM \
  -C "systemctl restart slapd"  # Reiniciar slapd después de renovación

# Establecer ownership apropiado
sudo chown ldap:ldap /etc/openldap/certs/ldap.{crt,key}
sudo chmod 600 /etc/openldap/certs/ldap.key

# Monitorear
sudo getcert list

17.12 Solución de Problemas LDAPS

Pasos de Diagnóstico

#============================================#
# SOLUCIÓN DE PROBLEMAS LDAPS
#============================================#

# Paso 1: Verificar que slapd está escuchando en 636
ss -tlnp | grep 636

# Paso 2: Verificar configuración de certificado
sudo slapcat -b "cn=config" | grep olcTLS

# Paso 3: Probar archivo de certificado
sudo openssl x509 -in /etc/openldap/certs/ldap.crt -noout -text

# Paso 4: Probar archivo de clave
sudo openssl rsa -in /etc/openldap/certs/ldap.key -check

# Paso 5: Verificar coincidencia cert/clave
CERT_MOD=$(openssl x509 -noout -modulus -in /etc/openldap/certs/ldap.crt | openssl md5)
KEY_MOD=$(openssl rsa -noout -modulus -in /etc/openldap/certs/ldap.key | openssl md5)
[ "$CERT_MOD" = "$KEY_MOD" ] && echo "✅ Coincide" || echo "❌ ¡Desajuste!"

# Paso 6: Verificar permisos
ls -l /etc/openldap/certs/
# La clave debería ser propiedad de ldap:ldap con modo 600

# Paso 7: Probar conexión
openssl s_client -connect ldap.example.com:636

# Paso 8: Verificar logs
sudo journalctl -u slapd | grep -i tls

# Paso 9: Probar desde cliente
ldapsearch -H ldaps://ldap.example.com:636 -x -b "" -s base

# Paso 10: Verificar SELinux
sudo ausearch -m avc -ts recent | grep ldap

17.13 Problemas Comunes y Soluciones

Problema 1: Error “TLS: can’t accept”

Síntoma: Conexión LDAPS rechazada

Diagnóstico:

sudo journalctl -u slapd | grep "TLS: can't accept"

Causas y Soluciones:

# Causa 1: Clave no legible por usuario ldap
sudo chown ldap:ldap /etc/openldap/certs/ldap.key
sudo chmod 600 /etc/openldap/certs/ldap.key

# Causa 2: Bloqueo de SELinux
sudo restorecon -Rv /etc/openldap/certs/
# O verificar denegaciones:
sudo ausearch -m avc -ts recent | grep ldap

# Causa 3: Desajuste certificado/clave
# Regenerar CSR con clave correcta

Problema 2: “TLS: hostname does not match”

Síntoma: El cliente obtiene error de desajuste de hostname

Diagnóstico:

# Verificar CN y SANs del certificado
openssl x509 -in /etc/openldap/certs/ldap.crt -noout -subject -ext subjectAltName

Solución:

# Reemitir certificado con hostname correcto en SANs
openssl req -new -key /etc/openldap/certs/ldap.key -out /tmp/ldap.csr \
  -subj "/CN=ldap.example.com" \
  -addext "subjectAltName=DNS:ldap.example.com,DNS:ldap,IP:10.0.0.10"

# O en el lado del cliente: permitir verificación más laxa (NO recomendado para producción)
# En /etc/openldap/ldap.conf:
TLS_REQCERT allow  # en lugar de 'demand'

Problema 3: Certificado No Confiable

Síntoma: “Certificate verification failed”

Solución:

# Agregar CA al almacén de confianza del sistema
sudo cp ldap-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# O especificar CA en configuración de cliente
# /etc/openldap/ldap.conf:
TLS_CACERT /etc/openldap/certs/ca.crt

17.14 Mejores Prácticas de Seguridad

Configuración OpenLDAP TLS Fortalecida

#============================================#
# CONFIGURACIÓN LDAP TLS FORTALECIDA (cn=config)
#============================================#

dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/ldap.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.key
-
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/ca.crt
-
replace: olcTLSProtocolMin
olcTLSProtocolMin: 3.3
-
replace: olcTLSCipherSuite
olcTLSCipherSuite: HIGH:!aNULL:!MD5:!RC4
-
add: olcTLSVerifyClient
olcTLSVerifyClient: never

Aplicar:

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f hardened-tls.ldif
sudo systemctl restart slapd

17.15 Integración con Servicios del Sistema

SSSD con LDAPS (Autenticación del Sistema)

#============================================#
# CONFIGURAR SSSD PARA USAR LDAPS
#============================================#

# /etc/sssd/sssd.conf

[domain/example.com]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap.example.com:636
ldap_search_base = dc=example,dc=com
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_tls_reqcert = demand

# Reiniciar SSSD
sudo systemctl restart sssd

# Probar
id ldapuser@example.com

17.16 Monitorear LDAP TLS

Comandos de Monitoreo

#============================================#
# MONITOREAR LDAP TLS
#============================================#

# Verificar expiración de certificado
openssl s_client -connect ldap.example.com:636 2>/dev/null | \
  openssl x509 -noout -dates

# Verificar conexiones TLS
sudo journalctl -u slapd | grep "TLS established"

# Contar conexiones LDAPS vs LDAP
sudo journalctl -u slapd --since today | grep -c "conn=.*LDAPS"
sudo journalctl -u slapd --since today | grep -c "conn=.*LDAP"

# Verificar errores TLS
sudo journalctl -u slapd | grep -i "tls.*error"

# Estado de certmonger (si se usa)
sudo getcert list -d /etc/openldap/certs

17.17 Conclusiones Clave

1. LDAPS (puerto 636) es más simple que STARTTLS
2. Ownership del certificado crítico - Debe ser legible por usuario ldap
3. cn=config preferido sobre slapd.conf (RHEL moderno)
4. FreeIPA maneja LDAPS automáticamente - ¡Mucho más fácil!
5. Configuración de cliente importa - Establecer TLS_CACERT correctamente
6. Probar exhaustivamente - Usar openssl s_client y ldapsearch -ZZ
7. certmonger automatiza renovación de certificados

Tarjeta de Referencia Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA OPENLDAP TLS                               │
├──────────────────────────────────────────────────────────────┤
│ Config:        cn=config (dinámico) o slapd.conf (legacy)    │
│ Certs:         /etc/openldap/certs/                          │
│ Ownership:     chown ldap:ldap *.{crt,key}                   │
│ Permisos:      chmod 600 ldap.key                            │
│                                                              │
│ LDAPS:         Puerto 636 (TLS desde inicio)                 │
│ STARTTLS:      Puerto 389 (actualizar a TLS)                 │
│                                                              │
│ Probar LDAPS:  openssl s_client -connect host:636            │
│ Probar STLS:   ldapsearch -H ldap://host:389 -ZZ             │
│                                                              │
│ Cliente:       /etc/openldap/ldap.conf                       │
│                TLS_CACERT /path/to/ca.crt                    │
│                TLS_REQCERT demand                            │
│                                                              │
│ Logs:          journalctl -u slapd | grep TLS                │
└──────────────────────────────────────────────────────────────┘

⚠️ ¡La clave debe ser propiedad del usuario 'ldap'!
✅ Usar FreeIPA para gestión LDAP+TLS más fácil

🧪 Laboratorio Práctico

Lab 09: LDAPS de OpenLDAP

Configura LDAPS para servicios de directorio seguros

• 📁 Ubicación: labs/es_ES/09-openldap-ldaps/
• ⏱️ Tiempo: 35-40 minutos
• 🎯 Nivel: Intermedio

Navegación del Capítulo

Capítulo 18: TLS en Bases de Datos (PostgreSQL, MySQL)

Datos en Tránsito: Protege las conexiones de base de datos con cifrado TLS. Aprende cómo configurar PostgreSQL y MySQL/MariaDB con certificados en RHEL.

18.1 ¿Por Qué TLS en Bases de Datos?

Proteger Datos Sensibles:

• ✅ Cifrar consultas y resultados de base de datos
• ✅ Prevenir escucha clandestina de credenciales
• ✅ Autenticar servidores de bases de datos
• ✅ Habilitar autenticación de certificado de cliente
• ✅ Cumplir requisitos de cumplimiento (PCI-DSS, HIPAA)

Modelo de Amenaza:

• Sin TLS: Contraseñas y datos viajan en texto claro
• Con TLS: Toda comunicación cifrada

18.2 PostgreSQL con SSL/TLS

Instalación

#============================================#
# INSTALAR POSTGRESQL
#============================================#

# RHEL 7/8/9/10
sudo dnf install postgresql-server -y

# Inicializar base de datos
sudo postgresql-setup --initdb

# Habilitar e iniciar
sudo systemctl enable postgresql
sudo systemctl start postgresql

# Verificar
systemctl status postgresql
ss -tlnp | grep 5432

Generar Certificados PostgreSQL

#============================================#
# GENERAR CERTIFICADOS POSTGRESQL
#============================================#

# Paso 1: Generar clave del servidor
sudo -u postgres openssl genpkey -algorithm RSA \
  -out /var/lib/pgsql/data/server.key \
  -pkeyopt rsa_keygen_bits:2048

# Paso 2: Establecer permisos (¡crítico!)
sudo chmod 600 /var/lib/pgsql/data/server.key
sudo chown postgres:postgres /var/lib/pgsql/data/server.key

# Paso 3: Generar CSR
sudo -u postgres openssl req -new \
  -key /var/lib/pgsql/data/server.key \
  -out /tmp/postgres.csr \
  -subj "/CN=db.example.com" \
  -addext "subjectAltName=DNS:db.example.com,DNS:postgres.example.com"

# Paso 4: Obtener certificado de CA

# Paso 5: Instalar certificado
sudo cp postgres.crt /var/lib/pgsql/data/server.crt
sudo chmod 600 /var/lib/pgsql/data/server.crt
sudo chown postgres:postgres /var/lib/pgsql/data/server.crt

# Paso 6: Instalar certificado CA
sudo cp ca.crt /var/lib/pgsql/data/root.crt
sudo chmod 644 /var/lib/pgsql/data/root.crt

Configurar PostgreSQL para SSL

#============================================#
# CONFIGURAR POSTGRESQL SSL
#============================================#

# Editar /var/lib/pgsql/data/postgresql.conf
sudo -u postgres vi /var/lib/pgsql/data/postgresql.conf

# Habilitar SSL
ssl = on

# Archivos de certificado (relativos al directorio de datos)
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
ssl_ca_file = 'root.crt'

# RHEL 7: Especificar versión TLS mínima
# ssl_min_protocol_version = 'TLSv1.2'

# RHEL 8/9/10: Usa crypto-policy del sistema
# (no necesitas especificar ssl_min_protocol_version)

# Opcional: Preferir cifrados del servidor
ssl_prefer_server_ciphers = on

# Reiniciar PostgreSQL
sudo systemctl restart postgresql

Configurar Autenticación de Cliente

#============================================#
# /var/lib/pgsql/data/pg_hba.conf
#============================================#

# Requerir SSL para todas las conexiones
hostssl all all 0.0.0.0/0 md5

# Requerir certificado de cliente
hostssl all alice 0.0.0.0/0 cert clientcert=verify-full

# Recargar configuración
sudo systemctl reload postgresql

Tipos HBA:

• host: Permitir sin SSL
• hostssl: Requerir SSL
• hostnossl: Prohibir explícitamente SSL

Opciones de Cert de Cliente:

• md5: SSL requerido, autenticación por contraseña
• cert: SSL + certificado de cliente requerido
• clientcert=verify-full: Verificar cert de cliente contra CA

Probar PostgreSQL SSL

#============================================#
# PROBAR POSTGRESQL SSL
#============================================#

# Prueba 1: Conectar con SSL requerido
psql "host=db.example.com port=5432 user=testuser dbname=testdb sslmode=require"

# Prueba 2: Conectar con verificación completa
psql "host=db.example.com port=5432 user=testuser dbname=testdb sslmode=verify-full sslrootcert=/etc/pki/tls/certs/ca-bundle.crt"

# Prueba 3: Con certificado de cliente
psql "host=db.example.com port=5432 user=alice dbname=mydb sslmode=verify-full sslcert=/home/alice/.postgresql/client.crt sslkey=/home/alice/.postgresql/client.key sslrootcert=/etc/pki/tls/certs/ca-bundle.crt"

# Prueba 4: Verificar SSL desde dentro de PostgreSQL
psql -h db.example.com -U testuser -d testdb -c "SELECT ssl, version FROM pg_stat_ssl WHERE pid = pg_backend_pid();"

# Prueba 5: Prueba OpenSSL
openssl s_client -connect db.example.com:5432 -starttls postgres

Modos SSL:

• disable: Sin SSL
• allow: Intentar SSL, volver a no-SSL
• prefer: Preferir SSL, fallback permitido
• require: Requerir SSL (no verificar cert)
• verify-ca: Requerir SSL, verificar CA
• verify-full: Requerir SSL, verificar hostname + CA

18.3 MySQL/MariaDB con SSL/TLS

Instalación

#============================================#
# INSTALAR MARIADB (REEMPLAZO MYSQL EN RHEL 8+)
#============================================#

# RHEL 8/9/10
sudo dnf install mariadb-server -y

# Iniciar y habilitar
sudo systemctl enable mariadb
sudo systemctl start mariadb

# Instalación segura
sudo mysql_secure_installation

# Verificar
systemctl status mariadb
ss -tlnp | grep 3306

Generar Certificados MySQL/MariaDB

#============================================#
# GENERAR CERTIFICADOS MYSQL/MARIADB
#============================================#

# Crear directorio de certificados
sudo mkdir -p /etc/mysql/certs
sudo chmod 755 /etc/mysql/certs

# Paso 1: Generar clave del servidor
sudo openssl genpkey -algorithm RSA \
  -out /etc/mysql/certs/server.key \
  -pkeyopt rsa_keygen_bits:2048

sudo chmod 600 /etc/mysql/certs/server.key
sudo chown mysql:mysql /etc/mysql/certs/server.key

# Paso 2: Generar CSR
sudo openssl req -new \
  -key /etc/mysql/certs/server.key \
  -out /tmp/mysql.csr \
  -subj "/CN=db.example.com" \
  -addext "subjectAltName=DNS:db.example.com,DNS:mysql.example.com"

# Paso 3: Obtener certificado de CA

# Paso 4: Instalar certificado y CA
sudo cp mysql.crt /etc/mysql/certs/server.crt
sudo cp ca.crt /etc/mysql/certs/ca.crt
sudo chmod 644 /etc/mysql/certs/{server.crt,ca.crt}
sudo chown mysql:mysql /etc/mysql/certs/{server.crt,ca.crt}

Configurar MySQL/MariaDB para SSL

#============================================#
# CONFIGURAR MYSQL/MARIADB SSL
#============================================#

# Editar /etc/my.cnf.d/server.cnf (o /etc/my.cnf)
sudo vi /etc/my.cnf.d/server.cnf

[mysqld]
# Configuración SSL/TLS
ssl-ca=/etc/mysql/certs/ca.crt
ssl-cert=/etc/mysql/certs/server.crt
ssl-key=/etc/mysql/certs/server.key

# Requerir transporte seguro (opcional, fuerza TLS para todos)
require_secure_transport=ON

# RHEL 7: Especificar versión TLS
# tls_version=TLSv1.2,TLSv1.3

# Reiniciar MySQL/MariaDB
sudo systemctl restart mariadb

Verificar que SSL está Habilitado

#============================================#
# VERIFICAR MYSQL SSL
#============================================#

# Conectar y verificar estado SSL
mysql -u root -p -e "SHOW VARIABLES LIKE '%ssl%';"

# Debería mostrar:
# have_ssl           | YES
# ssl_ca             | /etc/mysql/certs/ca.crt
# ssl_cert           | /etc/mysql/certs/server.crt
# ssl_key            | /etc/mysql/certs/server.key

# Verificar conexiones activas
mysql -u root -p -e "SHOW STATUS LIKE 'Ssl_cipher';"

Probar Conexión SSL MySQL

#============================================#
# PROBAR CONEXIÓN SSL MYSQL
#============================================#

# Conectar con SSL
mysql --ssl-ca=/etc/mysql/certs/ca.crt \
  --ssl-mode=REQUIRED \
  -h db.example.com \
  -u testuser \
  -p

# Verificar SSL en uso
mysql> \s
# Buscar: "SSL: Cipher in use is ..."

# O verificar desde línea de comandos
mysql -h db.example.com -u testuser -p -e "STATUS" | grep SSL

18.4 Autenticación de Certificado de Cliente

PostgreSQL con Certificados de Cliente

#============================================#
# AUTENTICACIÓN CERT CLIENTE POSTGRESQL
#============================================#

# Lado servidor: pg_hba.conf
hostssl all alice 0.0.0.0/0 cert clientcert=verify-full

# Generar certificado de cliente
openssl genpkey -algorithm RSA -out alice.key -pkeyopt rsa_keygen_bits:2048
openssl req -new -key alice.key -out alice.csr -subj "/CN=alice"
# Obtener firmado por CA

# Conexión de cliente
psql "host=db.example.com user=alice dbname=mydb sslmode=verify-full sslcert=alice.crt sslkey=alice.key sslrootcert=ca.crt"

MySQL/MariaDB con Certificados de Cliente

#============================================#
# AUTENTICACIÓN CERT CLIENTE MYSQL/MARIADB
#============================================#

# Crear usuario requiriendo X.509
mysql -u root -p << EOF
CREATE USER 'alice'@'%' REQUIRE X509;
GRANT ALL ON mydb.* TO 'alice'@'%';
FLUSH PRIVILEGES;
EOF

# Conexión de cliente
mysql --ssl-ca=ca.crt \
  --ssl-cert=alice.crt \
  --ssl-key=alice.key \
  -h db.example.com \
  -u alice \
  -p mydb

18.5 Solución de Problemas Database TLS

Solución de Problemas PostgreSQL

#============================================#
# SOLUCIÓN DE PROBLEMAS SSL POSTGRESQL
#============================================#

# Verificar que SSL está habilitado
sudo -u postgres psql -c "SHOW ssl;"
# Debería mostrar: on

# Ver ajustes SSL
sudo -u postgres psql -c "SHOW ssl_cert_file; SHOW ssl_key_file; SHOW ssl_ca_file;"

# Verificar archivos de certificado
ls -l /var/lib/pgsql/data/server.{crt,key}

# Verificar ownership
# Debería ser: postgres:postgres

# Verificar permisos
# server.key debería ser 600

# Probar conexión con depuración SSL
psql "host=db.example.com sslmode=require" -d postgres -U testuser --set=sslcompression=on

# Verificar logs de PostgreSQL
sudo tail -f /var/lib/pgsql/data/log/postgresql-*.log | grep -i ssl

Solución de Problemas MySQL/MariaDB

#============================================#
# SOLUCIÓN DE PROBLEMAS SSL MYSQL/MARIADB
#============================================#

# Verificar variables SSL
mysql -u root -p -e "SHOW VARIABLES LIKE '%ssl%';"

# Si have_ssl = NO, verificar:
# 1. Que existan archivos de certificado
ls -l /etc/mysql/certs/

# 2. Permisos
# Deberían ser legibles por usuario mysql

# 3. Reiniciar base de datos
sudo systemctl restart mariadb

# Verificar log de errores
sudo tail -f /var/log/mariadb/mariadb.log | grep -i ssl

# Probar conexión
mysql --ssl-ca=/etc/mysql/certs/ca.crt \
  --ssl-mode=REQUIRED \
  -h localhost \
  -u root \
  -p \
  -e "STATUS" | grep SSL

18.6 Problemas Comunes y Soluciones

Problema 1: PostgreSQL “Permission denied” en server.key

Síntoma: PostgreSQL no inicia, logs muestran error de permiso

Solución:

# Establecer permisos correctos
sudo chmod 600 /var/lib/pgsql/data/server.key
sudo chown postgres:postgres /var/lib/pgsql/data/server.key

# Corregir contexto SELinux
sudo restorecon -Rv /var/lib/pgsql/data/

# Reiniciar
sudo systemctl restart postgresql

Problema 2: MySQL “SSL connection error”

Diagnóstico:

# Verificar si SSL está disponible
mysql -u root -p -e "SHOW VARIABLES LIKE 'have_ssl';"
# Debería mostrar: YES

# Si muestra: DISABLED
# Verificar rutas de certificado en my.cnf

Solución:

# Verificar rutas en /etc/my.cnf.d/server.cnf
[mysqld]
ssl-ca=/etc/mysql/certs/ca.crt
ssl-cert=/etc/mysql/certs/server.crt
ssl-key=/etc/mysql/certs/server.key

# Reiniciar
sudo systemctl restart mariadb

Problema 3: Certificado de Cliente Rechazado

Síntoma: La conexión falla con cert de cliente

Solución PostgreSQL:

# Verificar pg_hba.conf
cat /var/lib/pgsql/data/pg_hba.conf | grep hostssl

# Asegurar que CA de cliente está instalada
sudo cp client-ca.crt /var/lib/pgsql/data/root.crt

# Recargar
sudo systemctl reload postgresql

Solución MySQL:

# Verificar que usuario requiere X.509
mysql -u root -p -e "SELECT user, host, ssl_type FROM mysql.user WHERE user='alice';"
# Debería mostrar: X509

# Verificar archivo CA configurado
mysql -u root -p -e "SHOW VARIABLES LIKE 'ssl_ca';"

18.7 Consideraciones Específicas por Versión

Versiones PostgreSQL en RHEL

Versiones MySQL/MariaDB en RHEL

18.8 Consideraciones de Rendimiento

Rendimiento SSL PostgreSQL

#============================================#
# AJUSTE DE RENDIMIENTO SSL POSTGRESQL
#============================================#

# /var/lib/pgsql/data/postgresql.conf

# SSL habilitado
ssl = on

# Compresión SSL (deshabilitada por seguridad, ataque CRIME)
ssl_compression = off

# Cifrados SSL (RHEL 7 - manual)
# ssl_ciphers = 'HIGH:!aNULL:!MD5'

# RHEL 8/9/10: crypto-policy maneja cifrados

# Connection pooling ayuda (usar pgBouncer)
# Terminación SSL en proxy puede mejorar rendimiento

Rendimiento SSL MySQL

#============================================#
# RENDIMIENTO SSL MYSQL
#============================================#

# [mysqld] en /etc/my.cnf.d/server.cnf

# SSL habilitado
ssl-ca=/etc/mysql/certs/ca.crt
ssl-cert=/etc/mysql/certs/server.crt
ssl-key=/etc/mysql/certs/server.key

# Deshabilitar cifrados débiles (RHEL 7)
# tls_version=TLSv1.2,TLSv1.3
# ssl_cipher='ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256'

# RHEL 8/9/10: crypto-policy lo maneja

# Connection pooling (usar ProxySQL o similar)

18.9 Monitorear Database TLS

Monitoreo PostgreSQL

#============================================#
# MONITOREAR SSL POSTGRESQL
#============================================#

# Verificar conexiones SSL
sudo -u postgres psql -c "SELECT datname, usename, ssl, version FROM pg_stat_ssl JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid;"

# Contar SSL vs no-SSL
sudo -u postgres psql -c "SELECT ssl, COUNT(*) FROM pg_stat_ssl GROUP BY ssl;"

# Verificar expiración de certificado
openssl x509 -in /var/lib/pgsql/data/server.crt -noout -checkend $((86400*30))

# Monitorear conexiones
sudo -u postgres psql -c "SELECT COUNT(*) FROM pg_stat_activity WHERE ssl = true;"

Monitoreo MySQL

#============================================#
# MONITOREAR SSL MYSQL
#============================================#

# Verificar estado SSL
mysql -u root -p -e "SHOW STATUS LIKE 'Ssl%';"

# Contar conexiones SSL
mysql -u root -p -e "SHOW STATUS LIKE 'Ssl_accepts';"

# Conexiones SSL actuales
mysql -u root -p -e "SELECT user, host, connection_type FROM information_schema.processlist WHERE connection_type = 'SSL/TLS';"

# Expiración de certificado
openssl x509 -in /etc/mysql/certs/server.crt -noout -checkend $((86400*30))

18.10 Scripts de Configuración Completos

Script de Configuración SSL PostgreSQL

#!/bin/bash
# setup-postgresql-ssl.sh

echo "=== Configuración SSL PostgreSQL ==="

# Generar cert autofirmado (¡reemplazar con cert apropiado de CA!)
sudo -u postgres openssl req -new -x509 -days 365 -nodes \
  -out /var/lib/pgsql/data/server.crt \
  -keyout /var/lib/pgsql/data/server.key \
  -subj "/CN=$(hostname -f)"

# Establecer permisos
sudo chmod 600 /var/lib/pgsql/data/server.{crt,key}
sudo chown postgres:postgres /var/lib/pgsql/data/server.{crt,key}

# Habilitar SSL en postgresql.conf
sudo -u postgres psql -c "ALTER SYSTEM SET ssl = on;"

# Reiniciar
sudo systemctl restart postgresql

# Probar
sudo -u postgres psql -c "SHOW ssl;"

echo "✅ SSL PostgreSQL habilitado"
echo "⚠️ Reemplazar cert autofirmado con certificado apropiado de CA"

18.11 Conclusiones Clave

1. PostgreSQL y MySQL soportan SSL/TLS
2. Ownership de archivo crítico - postgres:postgres o mysql:mysql
3. Permisos: 600 para claves, 644 para certs
4. pg_hba.conf controla acceso PostgreSQL (hostssl)
5. sslmode importante para clientes PostgreSQL
6. Certificados de cliente habilitan autenticación fuerte
7. Probar exhaustivamente antes de forzar TLS
8. Monitorear uso SSL - Asegurar que los clientes realmente lo usen

Tarjeta de Referencia Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA DATABASE TLS                               │
├──────────────────────────────────────────────────────────────┤
│ === POSTGRESQL ===                                           │
│ Config:       /var/lib/pgsql/data/postgresql.conf            │
│ Acceso:       /var/lib/pgsql/data/pg_hba.conf                │
│ Certs:        /var/lib/pgsql/data/server.{crt,key}           │
│ Owner:        postgres:postgres                              │
│ Habilitar:    ssl = on                                       │
│ Probar:       psql "sslmode=require"                         │
│                                                              │
│ === MYSQL/MARIADB ===                                        │
│ Config:       /etc/my.cnf.d/server.cnf                       │
│ Certs:        /etc/mysql/certs/server.{crt,key}              │
│ Owner:        mysql:mysql                                    │
│ Habilitar:    ssl-ca, ssl-cert, ssl-key en [mysqld]          │
│ Probar:       mysql --ssl-mode=REQUIRED                      │
│                                                              │
│ Permisos:     chmod 600 *.key                                │
│               chmod 644 *.crt                                │
└──────────────────────────────────────────────────────────────┘

⚠️ ¡Ownership y permisos de archivos son críticos!
✅ Usar hostssl en pg_hba.conf para requerir SSL

🧪 Laboratorio Práctico

Lab 10: TLS de PostgreSQL

Configura TLS para conexiones de base de datos PostgreSQL

• 📁 Ubicación: labs/es_ES/10-postgresql-tls/
• ⏱️ Tiempo: 25-30 minutos
• 🎯 Nivel: Intermedio

Navegación del Capítulo

Capítulo 19: Servicios de Certificados FreeIPA

CA Empresarial: FreeIPA es la solución integrada de gestión de identidad y certificados de Red Hat. Es la forma recomendada de ejecutar una CA interna en RHEL.

19.1 ¿Qué es FreeIPA?

FreeIPA (Identidad, Política, Auditoría) es una solución integrada de gestión de información de seguridad que combina:

• 🔐 Gestión de Identidad (directorio LDAP)
• 🎫 Autenticación (Kerberos)
• 🔏 Autoridad Certificadora (Dogtag PKI)
• 📋 Gestión de Políticas (sudo, HBAC)
• 🔍 DNS (integración BIND)

¿Por Qué FreeIPA para Certificados?

En lugar de:

• ❌ Gestionar manualmente certificados por servidor
• ❌ Costos de CA externa
• ❌ Infraestructura PKI compleja

FreeIPA Proporciona:

• ✅ CA interna (¡gratis!)
• ✅ Inscripción automática de certificados
• ✅ Renovación automática vía certmonger
• ✅ Perfiles de certificados
• ✅ Gestión por UI web y CLI
• ✅ Integración con servicios RHEL

19.2 Instalación de FreeIPA (Servidor)

Prerrequisitos

#============================================#
# PRERREQUISITOS PARA SERVIDOR FREEIPA
#============================================#

# Requisitos:
# - RHEL 7/8/9/10
# - Mínimo 2 GB RAM (4 GB recomendado)
# - Hostname completamente cualificado
# - Resolución DNS apropiada
# - Dirección IP estática

# Verificar hostname
hostnamectl
# Debe mostrar FQDN: ipa.example.com

# Verificar DNS
nslookup $(hostname -f)

# Establecer hostname si es necesario
sudo hostnamectl set-hostname ipa.example.com

Instalar Servidor FreeIPA

#============================================#
# INSTALAR SERVIDOR FREEIPA
#============================================#

# Instalar paquetes
sudo dnf install ipa-server ipa-server-dns -y

# Ejecutar asistente de instalación
sudo ipa-server-install \
  --realm EXAMPLE.COM \
  --domain example.com \
  --ds-password 'DirectoryPassword123!' \
  --admin-password 'AdminPassword123!' \
  --hostname ipa.example.com \
  --setup-dns \
  --forwarder 8.8.8.8 \
  --forwarder 8.8.4.4 \
  --unattended

# La instalación toma 5-15 minutos

# Abrir firewall
sudo firewall-cmd --add-service={http,https,dns,ntp,freeipa-ldap,freeipa-ldaps,freeipa-replication} --permanent
sudo firewall-cmd --reload

# Verificar
sudo ipactl status

# Debería mostrar múltiples servicios ejecutándose:
# - Directory Service (389-ds)
# - Certificate Authority (pki-tomcatd)
# - Kerberos KDC
# - Apache Web Server
# - DNS (named)

Acceder a la UI Web de FreeIPA

# Obtener ticket Kerberos
kinit admin
# Contraseña: AdminPassword123!

# Acceder a UI Web
# https://ipa.example.com/
# Usuario: admin
# Contraseña: AdminPassword123!

19.3 Inscribir Clientes

Instalación de Cliente

#============================================#
# INSCRIBIR CLIENTE A FREEIPA
#============================================#

# En sistema cliente (web01.example.com)

# Instalar cliente IPA
sudo dnf install ipa-client -y

# Inscribir
sudo ipa-client-install \
  --domain example.com \
  --realm EXAMPLE.COM \
  --server ipa.example.com \
  --principal admin \
  --password 'AdminPassword123!' \
  --mkhomedir \
  --unattended

# Verificar
# sudo ipa-client-install --uninstall  # ¡Solo bromeando, no ejecutar esto!

# Verificar inscripción
ipa ping
# Pong!

# Verificar rastreo de certificados
sudo getcert list
# Muestra certmonger rastreando certificado de host

19.4 Solicitar Certificados de FreeIPA

Método 1: UI Web

1. Navegar a https://ipa.example.com/
2. Identidad → Hosts → Seleccionar host → Acciones → Nuevo Certificado
3. O: Identidad → Servicios → Agregar servicio → Solicitar certificado

Método 2: CLI (Recomendado)

#============================================#
# SOLICITAR CERTIFICADO DE FREEIPA
#============================================#

# Para servicio HTTP en web01
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/web01.crt \
  -k /etc/pki/tls/private/web01.key \
  -K HTTP/web01.example.com@EXAMPLE.COM \
  -D web01.example.com \
  -C "systemctl reload httpd"

# Para servicio personalizado
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/myapp.crt \
  -k /etc/pki/tls/private/myapp.key \
  -K myapp/web01.example.com@EXAMPLE.COM \
  -D myapp.example.com

# Verificar estado
sudo getcert list

# Esperar estado MONITORING (cert emitido)

Método 3: ipa cert-request (Avanzado)

#============================================#
# AVANZADO: IPA CERT-REQUEST
#============================================#

# Generar CSR
openssl req -new -key server.key -out server.csr \
  -subj "/CN=server.example.com"

# Solicitar certificado vía IPA
ipa cert-request server.csr \
  --principal HTTP/server.example.com@EXAMPLE.COM

# Obtener ID de certificado de la salida
# Certificate: MIIDXTCCAkWgAwIBAgI...
# Request ID: 12345

# Recuperar certificado
ipa cert-show 12345 --out server.crt

19.5 Perfiles de Certificados

Perfiles Disponibles

#============================================#
# PERFILES DE CERTIFICADOS FREEIPA
#============================================#

# Listar perfiles disponibles
ipa certprofile-find

# Perfiles comunes:
# - caIPAserviceCert: Certificados de servicio (HTTP, LDAP, etc.)
# - IECUserRoles: Certificados de usuario
# - smimeUserCert: Certificados email S/MIME
# - caSelfSignedCert: CA autofirmada

# Ver detalles del perfil
ipa certprofile-show caIPAserviceCert

# Crear perfil personalizado
ipa certprofile-import MyCustomProfile \
  --file custom-profile.cfg \
  --store TRUE

Usar Perfil Específico

# Solicitar con perfil específico
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/custom.crt \
  -k /etc/pki/tls/private/custom.key \
  -K HTTP/web01.example.com@EXAMPLE.COM \
  -T caIPAserviceCert  # Especificar perfil

19.6 Renovación Automática

Cómo Funciona

FreeIPA + certmonger = ¡Ciclo de Vida Automático de Certificados!

#============================================#
# RENOVACIÓN AUTOMÁTICA CON FREEIPA
#============================================#

# certmonger automáticamente:
# 1. Rastrea expiración de certificado
# 2. Envía solicitud de renovación a IPA
# 3. Obtiene certificado renovado
# 4. Guarda en archivo
# 5. Ejecuta comando post-guardado (ej: reload httpd)

# Verificar estado de renovación
sudo getcert list

# Salida de ejemplo:
# Request ID '20240101000000':
#   status: MONITORING
#   stuck: no
#   key pair storage: type=FILE,location='/etc/pki/tls/private/web.key'
#   certificate: type=FILE,location='/etc/pki/tls/certs/web.crt'
#   CA: IPA
#   issuer: CN=Certificate Authority,O=EXAMPLE.COM
#   subject: CN=web01.example.com,O=EXAMPLE.COM
#   expires: 2025-01-01 00:00:00 UTC
#   pre-save command:
#   post-save command: systemctl reload httpd
#   track: yes
#   auto-renew: yes

# ¡La renovación ocurre automáticamente ~28 días antes de expirar!

Renovación Manual (Si Se Necesita)

# Forzar renovación ahora
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/web.crt

# O por ID de solicitud
sudo ipa-getcert resubmit -i 20240101000000

# Verificar si fue exitosa
sudo getcert list -f /etc/pki/tls/certs/web.crt

19.7 FreeIPA como CA Empresarial

Gestión de Certificados CA

#============================================#
# GESTIÓN CA DE FREEIPA
#============================================#

# Ver certificado CA
ipa ca-show ipa

# Exportar certificado CA
ipa ca-show ipa --certificate --out /tmp/ipa-ca.crt

# Instalar en clientes (automático durante ipa-client-install)
# Manual: Copiar a almacén de confianza
sudo cp /tmp/ipa-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# Renovar certificado CA (cuando sea necesario)
sudo ipa-cacert-manage renew

# Verificar expiración CA
sudo getcert list -d /var/lib/ipa | grep "CA:"

Sub-CAs (Avanzado)

#============================================#
# SUB-CA DE FREEIPA (RHEL 8+)
#============================================#

# Crear sub-CA
ipa ca-add subca \
  --subject "CN=SubCA,O=EXAMPLE.COM" \
  --desc "Sub-CA de Departamento"

# Emitir certificado de sub-CA
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/dept.crt \
  -k /etc/pki/tls/private/dept.key \
  -X subca \
  -K HTTP/dept.example.com@EXAMPLE.COM

19.8 Ejemplos de Integración de Servicios

Apache con Certificados FreeIPA

#============================================#
# CONFIGURACIÓN COMPLETA APACHE + FREEIPA
#============================================#

# 1. Inscribir sistema a IPA (si aún no)
sudo ipa-client-install

# 2. Solicitar certificado para Apache
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/$(hostname -f).crt \
  -k /etc/pki/tls/private/$(hostname -f).key \
  -K HTTP/$(hostname -f)@EXAMPLE.COM \
  -D $(hostname -f) \
  -C "systemctl reload httpd"

# 3. Esperar certificado
until sudo getcert list -f /etc/pki/tls/certs/$(hostname -f).crt | grep -q "MONITORING"; do
  sleep 5
  echo "Esperando certificado..."
done

# 4. Configurar Apache para usarlo
# /etc/httpd/conf.d/ssl.conf:
# SSLCertificateFile /etc/pki/tls/certs/$(hostname -f).crt
# SSLCertificateKeyFile /etc/pki/tls/private/$(hostname -f).key

# 5. Recargar Apache
sudo systemctl reload httpd

# ¡El certificado se renueva automáticamente!

LDAP con Certificados FreeIPA

# El servicio LDAP propio de FreeIPA usa automáticamente certificados IPA
# ¡No se necesita configuración manual!

# Probar
ldapsearch -H ldaps://ipa.example.com:636 -x -b "dc=example,dc=com"

19.9 Solución de Problemas de Certificados FreeIPA

Problemas Comunes

Problema 1: CA_UNREACHABLE

# Síntoma
sudo getcert list
# status: CA_UNREACHABLE

# Diagnóstico
# 1. Verificar conectividad con servidor IPA
ipa ping

# 2. Verificar ticket Kerberos
klist

# 3. Renovar ticket si expiró
kinit -k host/$(hostname -f)@EXAMPLE.COM

# 4. Verificar servicios IPA
ssh ipa.example.com "sudo ipactl status"

# 5. Reintentar
sudo ipa-getcert resubmit -i <request-id>

Problema 2: Solicitud de Certificado Denegada

# Verificar estado de solicitud
sudo getcert list -v

# Causas comunes:
# 1. Principal de servicio no existe
ipa service-find HTTP/$(hostname -f)

# Si no se encuentra, agregarlo:
ipa service-add HTTP/$(hostname -f)

# 2. Host no inscrito
ipa host-show $(hostname -f)

# 3. Permisos insuficientes
# Debe solicitar como principal de host inscrito

Problema 3: Certificado No Renovado

# Verificar logs de certmonger
sudo journalctl -u certmonger | tail -50

# Verificar estado CA de IPA
sudo ipactl status | grep "CA"

# Forzar renovación
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/web.crt

# Verificar expiración de certificado CA
sudo openssl x509 -in /etc/ipa/ca.crt -noout -dates

19.10 Características Avanzadas

Soporte ACME (RHEL 9+)

¡FreeIPA puede actuar como servidor ACME!

#============================================#
# HABILITAR ACME EN FREEIPA (RHEL 9+)
#============================================#

# En servidor IPA (RHEL 9+)
sudo ipa-acme-manage enable

# Verificar que ACME está disponible
curl https://ipa.example.com/acme/directory

# En cliente: Usar certbot o certmonger con ACME
sudo certbot register --server https://ipa.example.com/acme/directory
sudo certbot certonly --server https://ipa.example.com/acme/directory \
  -d web01.example.com

Retención/Revocación de Certificados

#============================================#
# REVOCAR CERTIFICADOS
#============================================#

# Poner certificado en retención (temporal)
ipa cert-revoke 12345 --revocation-reason 6

# Revocar permanentemente
ipa cert-revoke 12345 --revocation-reason 1

# Razones:
# 0: unspecified
# 1: keyCompromise
# 2: cACompromise
# 4: superseded
# 6: certificateHold (puede ser removido)

# Remover de retención
ipa cert-remove-hold 12345

# Verificar estado de revocación
ipa cert-show 12345

19.11 Monitorear PKI de FreeIPA

Verificaciones de Salud

#============================================#
# MONITOREO DE SALUD PKI FREEIPA
#============================================#

# Verificar estado general de IPA
sudo ipactl status

# Verificar subsistema CA
sudo systemctl status pki-tomcatd@pki-tomcat

# Verificar expiraciones de certificados
ipa-healthcheck --source ipahealthcheck.ipa.certs

# Verificar rastreo de certificados
sudo getcert list | grep -E "(Request|status|expires)"

# Monitorear certificado CA
openssl x509 -in /etc/ipa/ca.crt -noout -dates

# Verificar certificados expirando
ipa cert-find --validnotafter-from=$(date -d '+60 days' +%Y-%m-%d)

19.12 Respaldo y Recuperación

Respaldar Servidor IPA

#============================================#
# RESPALDAR FREEIPA (INCLUYENDO CA)
#============================================#

# Respaldo completo
sudo ipa-backup --data --online

# Ubicación de respaldo
ls -lh /var/lib/ipa/backup/

# Incluir claves CA (¡solo respaldo offline!)
sudo ipactl stop
sudo ipa-backup --data --gpg
# Ingresar passphrase GPG
sudo ipactl start

Restaurar Servidor IPA

# Restaurar desde respaldo
sudo ipactl stop
sudo ipa-restore /var/lib/ipa/backup/ipa-full-YYYY-MM-DD-HH-MM-SS/
sudo ipactl start

19.13 Mejores Prácticas

Mejores Prácticas de Certificados FreeIPA

✅ Usar FreeIPA para todos los certificados internos
✅ Dejar que certmonger maneje renovación (no renovar manualmente)
✅ Usar principales de servicio (HTTP/host, ldap/host, etc.)
✅ Agregar SANs al solicitar certificados
✅ Establecer comandos post-guardado (flag -C) para recarga de servicio
✅ Monitorear salud del servidor IPA regularmente
✅ Respaldar servidor IPA semanalmente (incluyendo claves CA)
✅ Tener al menos 2 réplicas IPA (HA)
✅ Monitorear expiración de certificado CA
✅ Probar renovación de certificado antes de expirar
✅ Usar perfiles de certificados para estandarización

19.14 Ejemplos de Integración

Configuración Completa de Servicio con FreeIPA

#!/bin/bash
# setup-service-with-ipa.sh
# Flujo de trabajo completo para certificado de servicio desde FreeIPA

SERVICE_NAME="HTTP"  # O LDAP, postgresql, etc.
HOST=$(hostname -f)
PRINCIPAL="${SERVICE_NAME}/${HOST}@EXAMPLE.COM"
CERT_FILE="/etc/pki/tls/certs/${HOST}.crt"
KEY_FILE="/etc/pki/tls/private/${HOST}.key"
POST_COMMAND="systemctl reload httpd"

echo "=== Solicitando Certificado de FreeIPA ==="

# 1. Asegurar que el principal de servicio existe
if ! ipa service-show "${SERVICE_NAME}/${HOST}" &>/dev/null; then
  echo "Creando principal de servicio..."
  ipa service-add "${SERVICE_NAME}/${HOST}"
fi

# 2. Solicitar certificado
sudo ipa-getcert request \
  -f "$CERT_FILE" \
  -k "$KEY_FILE" \
  -K "$PRINCIPAL" \
  -D "$HOST" \
  -C "$POST_COMMAND"

# 3. Esperar certificado
echo "Esperando emisión de certificado..."
until sudo getcert list -f "$CERT_FILE" | grep -q "MONITORING"; do
  sleep 5
done

# 4. Verificar
echo "✅ ¡Certificado emitido!"
sudo openssl x509 -in "$CERT_FILE" -noout -subject -issuer -dates

# 5. ¡El certificado se renovará automáticamente!
echo "✅ Rastreo de certificado habilitado - renovación automática activa"

19.15 Conclusiones Clave

1. FreeIPA es la CA interna recomendada de Red Hat
2. Combina identidad + certificados + autenticación
3. Integración con certmonger es automática
4. Los certificados se renuevan automáticamente (¡sin trabajo manual!)
5. Usar principales de servicio (HTTP/host, ldap/host)
6. Soporte ACME en RHEL 9+ (puede reemplazar Let’s Encrypt para interno)
7. UI Web y CLI ambos disponibles
8. Escala a empresa - Soporta réplicas, sub-CAs

Tarjeta de Referencia Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA SERVICIOS CERTIFICADOS FREEIPA             │
├──────────────────────────────────────────────────────────────┤
│ Instalar:         dnf install ipa-server                     │
│ Configurar:       ipa-server-install                         │
│ Estado:           ipactl status                              │
│ UI Web:           https://ipa.example.com/                   │
│                                                              │
│ Inscribir:        ipa-client-install                         │
│ Solicitar:        ipa-getcert request -K service/host@REALM  │
│ Listar:           getcert list                               │
│ Reenviar:         ipa-getcert resubmit -f /path/to/cert.crt  │
│                                                              │
│ Principal:        HTTP/host.example.com@REALM                │
│                   ldap/host.example.com@REALM                │
│                   postgresql/host.example.com@REALM          │
│                                                              │
│ Renovación auto:  Automática vía certmonger                  │
│ ACME:             ipa-acme-manage enable (RHEL 9+)           │
└──────────────────────────────────────────────────────────────┘

✅ Mejor para gestión de certificados empresarial interno
✅ Completamente integrado con RHEL
✅ ¡No se necesita renovación manual!

Navegación del Capítulo

Capítulo 20: Otros Servicios RHEL con Certificados

Más Allá de lo Básico: Muchos otros servicios RHEL usan certificados. Este capítulo cubre Cockpit, servicios VPN, registros de contenedores y más.

20.1 Servicios Cubiertos

Este capítulo proporciona guías de inicio rápido para:

• 🖥️ Cockpit (Consola de administración basada en web)
• 🔒 OpenVPN (Servicio VPN)
• 🛡️ strongSwan (VPN IPsec)
• 📦 Registro de Contenedores (Registro Podman/Docker)
• 📡 HAProxy (Balanceador de carga)
• 🔌 Redis con TLS (usando stunnel)
• ⚙️ Ansible Tower/AWX (Plataforma de automatización)

20.2 Consola Web Cockpit

¿Qué es Cockpit?

Cockpit es la interfaz de administración basada en web integrada de RHEL.

Predeterminado: Usa certificado autofirmado Objetivo: Reemplazar con certificado apropiado

Configurar Cockpit con Certificados

#============================================#
# COCKPIT CON CERTIFICADO APROPIADO
#============================================#

# Instalar Cockpit
sudo dnf install cockpit -y
sudo systemctl enable --now cockpit.socket

# Abrir firewall
sudo firewall-cmd --add-service=cockpit --permanent
sudo firewall-cmd --reload

# Ubicación de certificado de Cockpit
ls -l /etc/cockpit/ws-certs.d/

# Método 1: Colocar certificado con nombre específico
# Cockpit usa certificados en /etc/cockpit/ws-certs.d/
# Formato de nombre de archivo: NN-name.cert (donde NN = prioridad, menor = mayor prioridad)

sudo cat server.crt server.key > /etc/cockpit/ws-certs.d/01-server.cert
sudo chmod 644 /etc/cockpit/ws-certs.d/01-server.cert

# Reiniciar Cockpit
sudo systemctl restart cockpit.socket

# Método 2: Usar certmonger
sudo ipa-getcert request \
  -f /etc/cockpit/ws-certs.d/01-cockpit.cert \
  -k /etc/cockpit/ws-certs.d/01-cockpit.cert \
  -K HTTP/$(hostname -f)@REALM \
  -D $(hostname -f) \
  -C "systemctl restart cockpit.socket" \
  -F /etc/cockpit/ws-certs.d/01-cockpit.cert  # Cert+clave combinados

# Acceder a Cockpit
# https://server.example.com:9090/

Nota: ¡Cockpit espera cert+clave combinados en un solo archivo!

20.3 OpenVPN

Configuración de Servidor con Certificados

#============================================#
# SERVIDOR OPENVPN CON CERTIFICADOS
#============================================#

# Instalar OpenVPN (de EPEL en RHEL 7, repos en RHEL 8+)
sudo dnf install openvpn -y

# Generar u obtener certificados:
# - Certificado CA
# - Certificado de servidor + clave
# - Certificados de cliente

# /etc/openvpn/server/server.conf
port 1194
proto udp
dev tun

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dh2048.pem

tls-auth /etc/openvpn/server/ta.key 0
cipher AES-256-GCM
auth SHA256

server 10.8.0.0 255.255.255.0

# Iniciar OpenVPN
sudo systemctl enable --now openvpn-server@server

# Abrir firewall
sudo firewall-cmd --add-port=1194/udp --permanent
sudo firewall-cmd --reload

Probar OpenVPN

# Verificar si está ejecutándose
systemctl status openvpn-server@server

# Probar desde cliente
openvpn --config client.ovpn --verb 3

20.4 strongSwan IPsec VPN

Configurar con Certificados

#============================================#
# STRONGSWAN CON CERTIFICADOS
#============================================#

# Instalar
sudo dnf install strongswan -y

# Ubicaciones de certificados
# CA: /etc/strongswan/ipsec.d/cacerts/
# Certs Servidor/Cliente: /etc/strongswan/ipsec.d/certs/
# Claves privadas: /etc/strongswan/ipsec.d/private/

# Copiar certificados
sudo cp ca.crt /etc/strongswan/ipsec.d/cacerts/
sudo cp server.crt /etc/strongswan/ipsec.d/certs/
sudo cp server.key /etc/strongswan/ipsec.d/private/
sudo chmod 600 /etc/strongswan/ipsec.d/private/server.key

# /etc/strongswan/ipsec.conf
config setup
    charondebug="ike 2, knl 2, cfg 2"

conn example-ipsec
    left=%any
    leftid=@server.example.com
    leftcert=server.crt
    leftsubnet=10.0.0.0/24

    right=%any
    rightid=@client.example.com
    rightcert=client.crt

    auto=add
    type=tunnel
    keyexchange=ikev2

# Iniciar strongSwan
sudo systemctl enable --now strongswan

# Verificar estado
sudo swanctl --list-sas

20.5 Registro de Contenedores con TLS

Registro Podman/Docker

#============================================#
# REGISTRO DE CONTENEDOR CON TLS
#============================================#

# Instalar registry
sudo dnf install -y podman
sudo podman pull docker.io/library/registry:2

# Crear certificado para registry
sudo mkdir -p /etc/registry/certs
sudo openssl genpkey -algorithm RSA \
  -out /etc/registry/certs/registry.key \
  -pkeyopt rsa_keygen_bits:2048

sudo openssl req -new -x509 -days 365 \
  -key /etc/registry/certs/registry.key \
  -out /etc/registry/certs/registry.crt \
  -subj "/CN=registry.example.com" \
  -addext "subjectAltName=DNS:registry.example.com"

# Ejecutar registry con TLS
sudo podman run -d \
  --name registry \
  -p 5000:5000 \
  -v /etc/registry/certs:/certs:ro \
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/registry.crt \
  -e REGISTRY_HTTP_TLS_KEY=/certs/registry.key \
  registry:2

# Probar
curl https://registry.example.com:5000/v2/_catalog

Configuración de Cliente

# Agregar CA del registry al almacén de confianza del sistema
sudo cp /etc/registry/certs/registry.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# Probar pull
podman pull registry.example.com:5000/myimage:latest

20.6 Terminación TLS de HAProxy

Balanceador de Carga con TLS

#============================================#
# TERMINACIÓN TLS HAPROXY
#============================================#

# Instalar HAProxy
sudo dnf install haproxy -y

# HAProxy requiere cert+clave+cadena combinados en UN archivo
cat server.crt intermediate.crt server.key > /etc/haproxy/certs/bundle.pem
sudo chmod 600 /etc/haproxy/certs/bundle.pem

# /etc/haproxy/haproxy.cfg
frontend https-in
    bind *:443 ssl crt /etc/haproxy/certs/bundle.pem
    mode http
    default_backend web_servers

    # Forzar HTTPS
    http-request redirect scheme https unless { ssl_fc }

    # Encabezados de seguridad
    http-response set-header Strict-Transport-Security "max-age=31536000"

backend web_servers
    mode http
    balance roundrobin
    server web1 10.0.1.10:80 check
    server web2 10.0.1.11:80 check
    server web3 10.0.1.12:80 check

# Iniciar HAProxy
sudo systemctl enable --now haproxy

# Probar
curl -v https://loadbalancer.example.com/

20.7 Redis con TLS (vía stunnel)

Proxy TLS de Redis

#============================================#
# REDIS CON TLS USANDO STUNNEL
#============================================#

# Instalar Redis y stunnel
sudo dnf install redis stunnel -y

# Configurar Redis (escuchar solo en localhost)
# /etc/redis/redis.conf
bind 127.0.0.1

# Iniciar Redis
sudo systemctl enable --now redis

# Configurar stunnel
# /etc/stunnel/redis.conf
[redis-tls]
accept = 0.0.0.0:6380
connect = 127.0.0.1:6379
cert = /etc/pki/tls/certs/redis.crt
key = /etc/pki/tls/private/redis.key
CAfile = /etc/pki/tls/certs/ca-bundle.crt

# Opcional: Requerir certificados de cliente
verify = 2
CApath = /etc/pki/tls/certs/

# Iniciar stunnel
sudo systemctl enable --now stunnel@redis

# Probar
openssl s_client -connect localhost:6380
# Luego escribir: PING
# Debería responder: +PONG

20.8 Ansible Tower/AWX

Tower/AWX con Certificado Personalizado

#============================================#
# CERTIFICADO PERSONALIZADO ANSIBLE TOWER/AWX
#============================================#

# Ubicación de certificado de Tower
# /etc/tower/tower.cert
# /etc/tower/tower.key

# Reemplazar con certificado apropiado
sudo cp tower.example.com.crt /etc/tower/tower.cert
sudo cp tower.example.com.key /etc/tower/tower.key
sudo chmod 600 /etc/tower/tower.key

# Reiniciar servicios de Tower
sudo ansible-tower-service restart

# O para AWX (containerizado)
# Actualizar docker-compose.yml o secretos k8s

# Probar
curl -v https://tower.example.com/

20.9 SSH con Certificados (Avanzado)

Autenticación de Certificado SSH

Nota: ¡Diferente de claves SSH! Esto usa certificados X.509.

#============================================#
# SSH CON CERTIFICADOS X.509 (AVANZADO)
#============================================#

# Requiere: openssh-server con parche X.509 o ssh-keysign

# Generar certificado para usuario SSH
openssl genpkey -algorithm RSA -out ssh-user.key -pkeyopt rsa_keygen_bits:2048
openssl req -new -key ssh-user.key -out ssh-user.csr -subj "/CN=user@example.com"
# Obtener firmado por CA

# Configurar sshd (experimental, no estándar RHEL)
# /etc/ssh/sshd_config
# X509KeyAlgorithm x509v3-rsa2048-sha256
# X509TrustAnchor /etc/ssh/ca.crt

# Enfoque estándar: Usar claves SSH, no X.509
# El soporte X.509 SSH es limitado en RHEL

Recomendación: Usar autenticación basada en claves SSH estándar para SSH, usar X.509 para otros servicios.

20.10 Monitorear Múltiples Servicios

Verificación de Certificados Multi-Servicio

#!/bin/bash
# check-all-services.sh
# Verificar certificados para todos los servicios

echo "=== Verificación de Certificados Multi-Servicio ==="

# Apache
echo "1. Apache (puerto 443):"
timeout 3 openssl s_client -connect localhost:443 </dev/null 2>&1 | grep -E "(subject=|issuer=)" | head -2

# NGINX (si está instalado)
echo "2. NGINX (puerto 8443 o personalizado):"
timeout 3 openssl s_client -connect localhost:8443 </dev/null 2>&1 | grep -E "(subject=|issuer=)" | head -2

# Postfix
echo "3. Postfix SMTPS (puerto 465):"
timeout 3 openssl s_client -connect localhost:465 </dev/null 2>&1 | grep -E "(subject=|issuer=)" | head -2

# LDAPS
echo "4. LDAP (puerto 636):"
timeout 3 openssl s_client -connect localhost:636 </dev/null 2>&1 | grep -E "(subject=|issuer=)" | head -2

# PostgreSQL
echo "5. PostgreSQL (puerto 5432):"
sudo -u postgres psql -c "SHOW ssl;" 2>/dev/null

# Cockpit
echo "6. Cockpit (puerto 9090):"
timeout 3 openssl s_client -connect localhost:9090 </dev/null 2>&1 | grep -E "(subject=|issuer=)" | head -2

# Rastreo de certmonger
echo ""
echo "7. Certificados rastreados por certmonger:"
sudo getcert list | grep -c "Request ID"
echo "total de certificados rastreados"

echo ""
echo "=== Verificación Completa ==="

20.11 Referencias Rápidas Específicas por Servicio

Cockpit

# Instalar: dnf install cockpit
# Ubicación cert: /etc/cockpit/ws-certs.d/
# Formato: Cert+clave combinados
# Recargar: systemctl restart cockpit.socket
# Probar: https://server:9090/

OpenVPN

# Instalar: dnf install openvpn (EPEL)
# Ubicación cert: /etc/openvpn/server/
# Archivos: ca.crt, server.crt, server.key
# Iniciar: systemctl start openvpn-server@server
# Probar: openvpn --config client.ovpn

strongSwan

# Instalar: dnf install strongswan
# Ubicación cert: /etc/strongswan/ipsec.d/
# Subdirectorios: cacerts/, certs/, private/
# Iniciar: systemctl start strongswan
# Probar: swanctl --list-sas

HAProxy

# Instalar: dnf install haproxy
# Formato cert: PEM combinado (cert+clave+cadena)
# Ubicación: /etc/haproxy/certs/
# Config: bind *:443 ssl crt /path/to/bundle.pem
# Probar: curl -v https://loadbalancer/

Registro de Contenedor

# Ejecutar: podman run -d -p 5000:5000 registry:2
# Certs: Montar como volúmenes (-v)
# Variables de entorno: REGISTRY_HTTP_TLS_CERTIFICATE
#                       REGISTRY_HTTP_TLS_KEY
# Probar: curl https://registry:5000/v2/_catalog

20.12 Certificados Comodín para Múltiples Servicios

Cuándo Usar Comodines

Escenario: Múltiples subdominios en el mismo servidor

web.example.com    → Apache
api.example.com    → NGINX
admin.example.com  → Cockpit
mail.example.com   → Postfix

Solución: Usar certificado comodín *.example.com

Generar Certificado Comodín

#============================================#
# CERTIFICADO COMODÍN
#============================================#

# Generar clave
openssl genpkey -algorithm RSA -out wildcard.key -pkeyopt rsa_keygen_bits:2048

# Generar CSR
openssl req -new -key wildcard.key -out wildcard.csr \
  -subj "/CN=*.example.com" \
  -addext "subjectAltName=DNS:*.example.com,DNS:example.com"

# Enviar a CA, recibir wildcard.crt

# Usar para múltiples servicios
sudo cp wildcard.crt /etc/pki/tls/certs/
sudo cp wildcard.key /etc/pki/tls/private/
sudo chmod 600 /etc/pki/tls/private/wildcard.key

# Configurar cada servicio para usarlo
# Apache: SSLCertificateFile /etc/pki/tls/certs/wildcard.crt
# NGINX: ssl_certificate /etc/pki/tls/certs/wildcard.crt
# Postfix: smtpd_tls_cert_file = /etc/pki/tls/certs/wildcard.crt

Pros:

• ✅ Un certificado para múltiples subdominios
• ✅ Gestión más fácil
• ✅ Rentable (si se compra)

Contras:

• ⚠️ Si se compromete, afecta todos los subdominios
• ⚠️ No funciona para multi-nivel (..example.com)
• ⚠️ Algunas políticas de seguridad prohíben comodines

20.13 Matriz de Certificados por Servicio

Requisitos de Certificado por Servicio

20.14 Guía Rápida de Solución de Problemas

Solución de Problemas TLS Genérica de Servicio

#============================================#
# SOLUCIÓN DE PROBLEMAS TLS UNIVERSAL
#============================================#

# 1. Identificar servicio y puerto
ss -tlnp | grep <servicio>

# 2. Verificar si TLS está habilitado
# (comando específico del servicio)

# 3. Probar conexión TLS
openssl s_client -connect localhost:<puerto>
# O con STARTTLS:
openssl s_client -connect localhost:<puerto> -starttls <protocolo>

# 4. Verificar archivos de certificado
ls -lZ /path/to/certs/

# 5. Verificar ownership/permisos
# - Certificado: 644, propiedad del usuario del servicio
# - Clave: 600, propiedad del usuario del servicio

# 6. Verificar configuración
# (archivo de configuración específico del servicio)

# 7. Verificar logs
sudo journalctl -u <servicio> | grep -i tls
sudo tail -f /var/log/<servicio>/ | grep -i tls

# 8. Probar desde cliente remoto
openssl s_client -connect server.example.com:<puerto>

20.15 Gestión Centralizada de Certificados

Usar certmonger para Todos los Servicios

#============================================#
# ESTRATEGIA DE GESTIÓN CENTRALIZADA DE CERTIFICADOS
#============================================#

# Rastrear todos los certificados de servicio con certmonger

# Apache
sudo ipa-getcert request -f /etc/pki/tls/certs/apache.crt \
  -k /etc/pki/tls/private/apache.key \
  -K HTTP/$(hostname -f)@REALM \
  -C "systemctl reload httpd"

# NGINX
sudo ipa-getcert request -f /etc/pki/tls/certs/nginx.crt \
  -k /etc/pki/tls/private/nginx.key \
  -K HTTP/$(hostname -f)@REALM \
  -C "systemctl reload nginx"

# Postfix
sudo ipa-getcert request -f /etc/pki/tls/certs/postfix.crt \
  -k /etc/pki/tls/private/postfix.key \
  -K smtp/$(hostname -f)@REALM \
  -C "postfix reload"

# OpenLDAP
sudo ipa-getcert request -f /etc/openldap/certs/ldap.crt \
  -k /etc/openldap/certs/ldap.key \
  -K ldap/$(hostname -f)@REALM \
  -o ldap:ldap \
  -m 600 \
  -C "systemctl restart slapd"

# Monitorear todos
sudo getcert list

Beneficios:

• ✅ Herramienta única para todos los servicios
• ✅ Renovación automática
• ✅ Monitoreo centralizado
• ✅ Enfoque consistente

20.16 Conclusiones Clave

1. Muchos servicios usan certificados más allá de servidores web
2. Cada servicio tiene requisitos únicos - Verificar ownership, permisos
3. certmonger funciona con la mayoría de servicios para automatización
4. Certificados comodín pueden simplificar configuraciones multi-servicio
5. Probar cada servicio independientemente
6. Rastreo centralizado con certmonger recomendado
7. Documentar configuraciones específicas de servicio

Tarjeta de Referencia Rápida

┌───────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA CERTIFICADOS OTROS SERVICIOS                │
├───────────────────────────────────────────────────────────────┤
│ Cockpit:     /etc/cockpit/ws-certs.d/NN-name.cert             │
│              (cert+clave combinados)                          │
│                                                               │
│ OpenVPN:     /etc/openvpn/server/{ca,server}.{crt,key}        │
│              PKI complejo con certs de cliente                │
│                                                               │
│ strongSwan:  /etc/strongswan/ipsec.d/{cacerts,certs,private}/ │
│              Configuración específica IPsec                   │
│                                                               │
│ HAProxy:     PEM combinado (cert+clave+cadena en un archivo)  │
│              /etc/haproxy/certs/bundle.pem                    │
│                                                               │
│ Registry:    Variables de entorno para contenedor             │
│              REGISTRY_HTTP_TLS_CERTIFICATE/KEY                │
│                                                               │
│ Genérico:    Verificar ownership, permisos, SELinux           │
│              Probar con: openssl s_client -connect :port      │
└───────────────────────────────────────────────────────────────┘

✅ Usar certmonger para automatización donde sea posible
✅ Cada servicio tiene requisitos únicos de formato/ubicación de archivo

Navegación del Capítulo

Capítulo 21: Mejores Prácticas para Certificados de Servicios

Crítico para Operaciones: Aprende las mejores prácticas que previenen el 90% de los problemas de certificados antes de que sucedan.

21.1 El Costo de la Mala Gestión de Certificados

Impactos del mundo real:

• ❌ Certificado expirado → Sitio web caído (pérdida de ingresos)
• ❌ Permisos incorrectos → Servicio falla al iniciar (tiempo de inactividad)
• ❌ Sin respaldo → Fallo de CA significa reemisión manual (horas/días)
• ❌ Nomenclatura pobre → Confusión durante incidente (respuesta retrasada)
• ❌ Sin monitoreo → Expiración sorpresa (respuesta de emergencia)

Este capítulo previene estos problemas.

21.2 Mejores Prácticas de Organización de Archivos

Estructura de Directorio Estándar

/etc/pki/tls/
├── certs/                      # Archivos de certificado (públicos)
│   ├── service-name.crt        # Certificados reales
│   ├── service-name-chain.crt  # Con cadena intermedia
│   └── ca-bundle.crt           # Paquete CA
│
├── private/                    # Claves privadas (¡protegidas!)
│   └── service-name.key        # Claves privadas (modo 600)
│
├── csr/                        # Solicitudes de certificado (opcional)
│   └── service-name.csr        # CSRs para rastreo
│
└── backup/                     # Respaldos (opcional pero recomendado)
    └── YYYY-MM-DD/
        ├── service-name.crt
        └── service-name.key

Convenciones de Nomenclatura

Una buena nomenclatura previene confusión:

# ✅ BUENO - Claro, descriptivo
/etc/pki/tls/certs/web01-example-com.crt
/etc/pki/tls/certs/mail-smtp-example-com.crt
/etc/pki/tls/certs/ldap-primary-example-com.crt

# ❌ MALO - Poco claro, genérico
/etc/pki/tls/certs/cert1.crt
/etc/pki/tls/certs/new.crt
/etc/pki/tls/certs/temp.crt

Patrón de nomenclatura:

[servicio]-[hostname/función]-[dominio].crt
[servicio]-[hostname/función]-[dominio].key

Ejemplos:
apache-web01-example-com.crt
nginx-www-example-com.crt
postfix-mail-example-com.crt
ldap-dir01-example-com.crt
postgresql-db-primary-example-com.crt

Estándares de Permisos de Archivo

#============================================#
# CRÍTICO: Permisos Apropiados
#============================================#

# Certificados (públicos) - legibles por todos
/etc/pki/tls/certs/*.crt           → 644 (rw-r--r--)
/etc/pki/tls/certs/                → 755 (rwxr-xr-x)

# Claves privadas (¡secretas!) - solo legibles por propietario
/etc/pki/tls/private/*.key         → 600 (rw-------)
/etc/pki/tls/private/              → 711 (rwx--x--x)

# Claves específicas de servicio - propiedad del usuario del servicio
/etc/pki/tls/private/apache.key    → 600, owner: root o apache
/etc/pki/tls/private/postgres.key  → 600, owner: postgres

Script para establecer permisos:

#!/bin/bash
# set-cert-permissions.sh
# Establece permisos apropiados en archivos de certificado

CERT_DIR="/etc/pki/tls/certs"
KEY_DIR="/etc/pki/tls/private"

# Directorio de certificados
chmod 755 "$CERT_DIR"
chmod 644 "$CERT_DIR"/*.crt 2>/dev/null

# Directorio de claves privadas
chmod 711 "$KEY_DIR"
chmod 600 "$KEY_DIR"/*.key 2>/dev/null

# Verificar
echo "Permisos de certificados:"
ls -ld "$CERT_DIR" "$CERT_DIR"/*.crt 2>/dev/null

echo ""
echo "Permisos de claves privadas:"
ls -ld "$KEY_DIR" "$KEY_DIR"/*.key 2>/dev/null

# Verificar claves excesivamente permisivas
echo ""
echo "Verificando problemas de seguridad:"
find "$KEY_DIR" -type f -not -perm 600 -ls 2>/dev/null && \
  echo "⚠️ ADVERTENCIA: ¡Algunas claves tienen permisos incorrectos!" || \
  echo "✅ Todas las claves apropiadamente protegidas"

21.3 Gestión del Ciclo de Vida de Certificados

Cronograma de Renovación

Ciclo de Vida del Certificado (validez 365 días):

Día   0: Certificado emitido
Día  30: Primer recordatorio de renovación (quedan 335 días)
Día  60: Segundo recordatorio (quedan 305 días)
Día 300: Comienza ventana crítica de renovación (quedan 65 días)
Día 330: URGENTE - Renovación necesaria (quedan 35 días)
Día 350: CRÍTICO - Renovación atrasada (quedan 15 días)
Día 365: EXPIRADO - ¡Interrupción del servicio!

Acciones Recomendadas:
- Días 300-330: Planificar y ejecutar renovación
- Días 330-350: Renovación de emergencia si se perdió
- Días 350+: Respuesta a incidente, cert temporal

Estrategias de Renovación

Estrategia 1: Automatizada (Recomendado)

# Usando certmonger (RHEL)
sudo getcert request \
  -f /etc/pki/tls/certs/web01-example-com.crt \
  -k /etc/pki/tls/private/web01-example-com.key \
  -D web.example.com \
  -K host/web.example.com@REALM \
  -C "systemctl reload httpd"  # Auto-recargar servicio

# Renovación automática ocurre a 2/3 del tiempo de vida del cert
# Cert de 365 días → renueva en día 243 (quedan 122 días)

Estrategia 2: Renovación Manual Programada

# Tarea cron para verificación manual de renovación
# /etc/cron.weekly/check-certificates

#!/bin/bash
# Verificar certificados expirando en 60 días
find /etc/pki/tls/certs/ -name "*.crt" | while read cert; do
  if openssl x509 -in "$cert" -noout -checkend $((86400*60)); then
    echo "✅ $cert: OK"
  else
    echo "⚠️ $cert: ¡Expira dentro de 60 días!"
    # Enviar alerta
    mail -s "Certificado Expirando Pronto: $cert" admin@example.com
  fi
done

Estrategia 3: Recordatorios de Calendario

# Para entornos sin automatización
# Crear entradas de calendario:
# - 90 días antes de expiración: Comenzar renovación
# - 60 días antes: Verificar renovación en progreso
# - 30 días antes: Completar renovación
# - 7 días antes: Emergencia si no está hecho

21.4 Rastreo de Metadatos de Certificados

Inventario de Certificados

Mantener un inventario de certificados (hoja de cálculo o base de datos):

Service,Hostname,Certificate_Path,Key_Path,Issuer,Issue_Date,Expiry_Date,SANs,Owner,Notes
Apache,web01,/etc/pki/tls/certs/web01-example-com.crt,/etc/pki/tls/private/web01.key,Internal CA,2024-01-01,2025-01-01,"web01.example.com,www.example.com",Juan Pérez,Producción
NGINX,web02,/etc/pki/tls/certs/web02-example-com.crt,/etc/pki/tls/private/web02.key,Let's Encrypt,2024-06-15,2024-09-15,"web02.example.com",María López,Staging

Script para generar inventario:

#!/bin/bash
# generate-cert-inventory.sh
# Crea inventario de certificados desde el sistema

echo "Service,Hostname,Certificate_Path,Issuer,Issue_Date,Expiry_Date,Days_Remaining"

# Escanear ubicaciones comunes de certificados
for cert in /etc/pki/tls/certs/*.crt /etc/httpd/conf/ssl/*.crt /etc/nginx/ssl/*.crt; do
  [ -f "$cert" ] || continue

  subject=$(openssl x509 -in "$cert" -noout -subject 2>/dev/null | sed 's/subject=//')
  issuer=$(openssl x509 -in "$cert" -noout -issuer 2>/dev/null | sed 's/issuer=//')
  notbefore=$(openssl x509 -in "$cert" -noout -startdate 2>/dev/null | cut -d= -f2)
  notafter=$(openssl x509 -in "$cert" -noout -enddate 2>/dev/null | cut -d= -f2)

  # Calcular días restantes
  expiry_epoch=$(date -d "$notafter" +%s 2>/dev/null)
  now_epoch=$(date +%s)
  days_remaining=$(( ($expiry_epoch - $now_epoch) / 86400 ))

  # Determinar servicio desde la ruta
  service="Desconocido"
  [[ "$cert" =~ httpd ]] && service="Apache"
  [[ "$cert" =~ nginx ]] && service="NGINX"

  echo "$service,$(hostname),$cert,\"$issuer\",$notbefore,$notafter,$days_remaining"
done

21.5 Respaldo y Recuperación

Qué Respaldar

Archivos críticos para respaldar:
✅ Claves privadas (archivos .key)
✅ Certificados (archivos .crt)
✅ Certificados CA
✅ Cadenas de certificados
✅ CSRs (para referencia)
✅ Archivos de configuración (Apache ssl.conf, etc.)
⚠️ NO contraseñas o frases de contraseña (almacenar separadamente en bóveda)

Script de Respaldo

#!/bin/bash
# backup-certificates.sh
# Respalda todos los certificados y claves

BACKUP_DIR="/var/backups/certificates"
DATE=$(date +%Y-%m-%d)
BACKUP_PATH="$BACKUP_DIR/$DATE"

# Crear directorio de respaldo
mkdir -p "$BACKUP_PATH"

# Respaldar certificados
echo "Respaldando certificados..."
cp -a /etc/pki/tls/certs/*.crt "$BACKUP_PATH/" 2>/dev/null

# Respaldar claves privadas (¡cifradas!)
echo "Respaldando claves privadas..."
tar czf - /etc/pki/tls/private/*.key 2>/dev/null | \
  openssl enc -aes-256-cbc -salt -out "$BACKUP_PATH/keys.tar.gz.enc" -pass pass:CHANGEME

# Respaldar archivos de configuración
echo "Respaldando configuraciones..."
cp -a /etc/httpd/conf.d/ssl.conf "$BACKUP_PATH/" 2>/dev/null
cp -a /etc/nginx/nginx.conf "$BACKUP_PATH/" 2>/dev/null

# Crear inventario
ls -lh "$BACKUP_PATH"

# Establecer permisos
chmod 700 "$BACKUP_PATH"

echo "✅ Respaldo completo: $BACKUP_PATH"
echo "⚠️ ¡Recuerda cambiar la contraseña de cifrado!"

Procedimiento de Recuperación

#============================================#
# PROCEDIMIENTO DE RECUPERACIÓN DE CERTIFICADO
#============================================#

# 1. Detener servicio afectado
sudo systemctl stop httpd

# 2. Restaurar certificado
sudo cp /var/backups/certificates/2024-11-15/web.crt /etc/pki/tls/certs/

# 3. Restaurar clave privada (descifrar)
cd /var/backups/certificates/2024-11-15/
openssl enc -aes-256-cbc -d -in keys.tar.gz.enc -pass pass:CHANGEME | \
  sudo tar xzf - -C /

# 4. Establecer permisos
sudo chmod 600 /etc/pki/tls/private/*.key
sudo chmod 644 /etc/pki/tls/certs/*.crt

# 5. Verificar archivos
sudo openssl x509 -in /etc/pki/tls/certs/web01-example-com.crt -noout -text
sudo openssl rsa -in /etc/pki/tls/private/web01-example-com.key -check

# 6. Iniciar servicio
sudo systemctl start httpd

# 7. Probar
curl -v https://localhost/

21.6 Mejores Prácticas de Seguridad

Protección de Clave Privada

#============================================#
# LISTA DE VERIFICACIÓN SEGURIDAD CLAVE PRIVADA
#============================================#

✅ Permisos: 600 (o 400 para protección extra)
✅ Ownership: Solo root o usuario del servicio
✅ Ubicación: /etc/pki/tls/private/ (modo 711)
✅ SELinux: Contexto apropiado (cert_t)
✅ Respaldo: Cifrado en reposo
✅ Nunca: Enviar por email, pegar en tickets, commit a git
✅ Nunca: Compartir entre sistemas (generar nueva)
✅ Auditar: Registrar acceso con auditd

# Verificar seguridad
ls -lZ /etc/pki/tls/private/*.key
# -rw------- root root unconfined_u:object_r:cert_t:s0 server01-example-com.key

Mejores Prácticas de Generación de Claves

#============================================#
# GENERAR CLAVES SEGURAS
#============================================#

# RSA 2048 (mínimo para RHEL 8+)
openssl genpkey -algorithm RSA -out server01-example-com.key -pkeyopt rsa_keygen_bits:2048

# RSA 4096 (recomendado para certs de larga duración)
openssl genpkey -algorithm RSA -out server01-example-com.key -pkeyopt rsa_keygen_bits:4096

# EC P-256 (moderno, más pequeño, rápido)
openssl genpkey -algorithm EC -out server01-example-com.key -pkeyopt ec_paramgen_curve:P-256

# ¡Establecer permisos inmediatamente!
chmod 600 server.key

# ❌ NUNCA hacer esto:
# openssl genrsa -out server01-example-com.key 1024   # ¡Muy débil!
# chmod 644 server01-example-com.key                  # ¡Muy permisivo!

Validación de Certificado Antes de Despliegue

#!/bin/bash
# validate-certificate.sh
# Valida certificado antes de despliegue

CERT=$1
KEY=$2

echo "=== Validación de Certificado Pre-Despliegue ==="

# Verificación 1: Archivo de certificado existe y es legible
if [ ! -f "$CERT" ]; then
  echo "❌ Archivo de certificado no encontrado: $CERT"
  exit 1
fi

# Verificación 2: Clave privada existe y es legible
if [ ! -f "$KEY" ]; then
  echo "❌ Clave privada no encontrada: $KEY"
  exit 1
fi

# Verificación 3: Certificado es X.509 válido
if ! openssl x509 -in "$CERT" -noout 2>/dev/null; then
  echo "❌ Certificado X.509 inválido"
  exit 1
fi

# Verificación 4: Certificado no expirado
if ! openssl x509 -in "$CERT" -noout -checkend 0; then
  echo "❌ ¡El certificado está expirado!"
  exit 1
fi

# Verificación 5: Par certificado/clave coinciden
CERT_MOD=$(openssl x509 -noout -modulus -in "$CERT" | openssl md5)
KEY_MOD=$(openssl rsa -noout -modulus -in "$KEY" 2>/dev/null | openssl md5)

if [ "$CERT_MOD" != "$KEY_MOD" ]; then
  echo "❌ ¡Certificado y clave no coinciden!"
  exit 1
fi

# Verificación 6: SANs presentes (requerido para navegadores modernos)
if ! openssl x509 -in "$CERT" -noout -ext subjectAltName 2>/dev/null | grep -q "DNS:"; then
  echo "⚠️ ADVERTENCIA: No se encontraron Subject Alternative Names"
fi

# Verificación 7: Algoritmo de firma fuerte
SIG_ALG=$(openssl x509 -in "$CERT" -noout -text | grep "Signature Algorithm" | head -2)
if echo "$SIG_ALG" | grep -qi "sha1\|md5"; then
  echo "❌ Algoritmo de firma débil: $SIG_ALG"
  exit 1
fi

# Verificación 8: Tamaño de clave adecuado
KEY_SIZE=$(openssl x509 -in "$CERT" -noout -text | grep "Public-Key:" | grep -oP '\d+')
if [ "$KEY_SIZE" -lt 2048 ]; then
  echo "❌ Tamaño de clave muy pequeño: $KEY_SIZE bits (mínimo 2048)"
  exit 1
fi

echo ""
echo "✅ ¡Validación de certificado exitosa!"
echo "   Sujeto: $(openssl x509 -in "$CERT" -noout -subject)"
echo "   Emisor: $(openssl x509 -in "$CERT" -noout -issuer)"
echo "   Expira: $(openssl x509 -in "$CERT" -noout -enddate | cut -d= -f2)"
echo "   Tamaño Clave: $KEY_SIZE bits"

21.7 Coordinación Multi-Servicio

Cuando Múltiples Servicios Comparten Certificados

# Escenario: Balanceador de carga + múltiples servidores web

# Problema: Certificado en LB, servicios detrás necesitan mismo CN/SANs

# Solución 1: Usar mismo certificado en todos (si hostnames coinciden)
# web01, web02, web03 todos usan cert para: web.example.com

# Solución 2: Certificado comodín
# *.example.com funciona para web01.example.com, web02.example.com, etc.

# Solución 3: SANs comprehensivos
# Cert único con SANs: web.example.com, web01.example.com, web02.example.com

Flujo de Trabajo de Despliegue de Certificados

#============================================#
# DESPLIEGUE MULTI-SERVIDOR
#============================================#

# Paso 1: Generar certificado en nodo de gestión
openssl genpkey -algorithm RSA -out web.key -pkeyopt rsa_keygen_bits:2048
openssl req -new -key web.key -out web.csr \
  -subj "/CN=web.example.com" \
  -addext "subjectAltName=DNS:web.example.com,DNS:web01.example.com,DNS:web02.example.com"

# Paso 2: Obtener certificado de CA
# (enviar web.csr a CA, recibir web.crt)

# Paso 3: Validar localmente
./validate-certificate.sh web.crt web.key

# Paso 4: Distribuir de forma segura
for host in web01 web02 web03; do
  scp web.crt root@$host:/etc/pki/tls/certs/
  scp web.key root@$host:/etc/pki/tls/private/
  ssh root@$host "chmod 644 /etc/pki/tls/certs/web01-example-com.crt"
  ssh root@$host "chmod 600 /etc/pki/tls/private/web01-example-com.key"
done

# Paso 5: Recargar servicios
for host in web01 web02 web03; do
  ssh root@$host "systemctl reload httpd"
done

# Paso 6: Probar cada servidor
for host in web01 web02 web03; do
  echo "Probando $host..."
  curl -vk https://$host/ 2>&1 | grep "subject:"
done

21.8 Estándares de Documentación

Plantilla de Documentación de Certificado

## Certificado: web.example.com

### Información Básica
- **Servicio:** Apache (httpd)
- **Servidor:** web01.example.com
- **Ruta de Certificado:** `/etc/pki/tls/certs/web-example-com.crt`
- **Ruta de Clave:** `/etc/pki/tls/private/web-example-com.key`
- **Propietario:** Equipo Web (webadmin@example.com)

### Detalles del Certificado
- **Common Name (CN):** web.example.com
- **SANs:** web.example.com, www.example.com
- **Emisor:** CA Interna (ca.example.com)
- **Fecha de Emisión:** 2024-01-01
- **Fecha de Expiración:** 2025-01-01
- **Tipo de Clave:** RSA 2048

### Proceso de Renovación
- **Método:** certmonger automático
- **Ventana de Renovación:** 65 días antes de expirar
- **Post-Renovación:** `systemctl reload httpd`
- **Contacto:** webadmin@example.com

### Configuración de Servicio
- **Archivo de Config:** `/etc/httpd/conf.d/ssl.conf`
- **Servicio:** `httpd.service`
- **Comando de Reinicio:** `systemctl reload httpd`

### Solución de Problemas
- **Logs:** `/var/log/httpd/ssl_error_log`
- **Comando de Prueba:** `curl -v https://web.example.com/`
- **Problemas Comunes:** Ninguno reportado

### Historial de Cambios
- 2024-01-01: Despliegue inicial
- 2024-06-15: Agregado SAN www.example.com

21.9 Monitoreo y Alertas

Qué Monitorear

✅ Expiración de certificado (60, 30, 7 días antes)
✅ Validez de certificado (no expirado, aún no válido)
✅ Coincidencia de par certificado/clave
✅ Cadena de confianza de certificado
✅ Salud del servicio (¿está usando el cert?)
✅ Estado de rastreo de certmonger
✅ Éxito/fallo de renovación

Script Simple de Monitoreo

#!/bin/bash
# monitor-certificates.sh
# Monitoreo simple de certificados

WARN_DAYS=30
CRIT_DAYS=7
EMAIL="admin@example.com"

check_cert() {
  local cert=$1
  local name=$(basename "$cert")

  # Verificar si expira dentro del período de advertencia
  if ! openssl x509 -in "$cert" -noout -checkend $((86400*WARN_DAYS)); then
    if ! openssl x509 -in "$cert" -noout -checkend $((86400*CRIT_DAYS)); then
      echo "🚨 CRÍTICO: ¡$name expira dentro de $CRIT_DAYS días!"
      return 2
    else
      echo "⚠️ ADVERTENCIA: $name expira dentro de $WARN_DAYS días"
      return 1
    fi
  fi

  return 0
}

# Verificar todos los certificados
WARNINGS=0
CRITICALS=0

for cert in /etc/pki/tls/certs/*.crt; do
  [ -f "$cert" ] || continue
  check_cert "$cert"
  ret=$?
  [ $ret -eq 1 ] && ((WARNINGS++))
  [ $ret -eq 2 ] && ((CRITICALS++))
done

# Alertar si se encuentran problemas
if [ $CRITICALS -gt 0 ] || [ $WARNINGS -gt 0 ]; then
  echo "Problemas de certificados encontrados: $CRITICALS críticos, $WARNINGS advertencias" | \
    mail -s "Alerta de Certificados: $(hostname)" "$EMAIL"
fi

21.10 Procedimientos de Respuesta a Incidentes

Incidente de Expiración de Certificado

#============================================#
# EMERGENCIA DE CERTIFICADO EXPIRADO
#============================================#

# Paso 1: Evaluar impacto
systemctl status httpd
journalctl -xe | grep -i cert

# Paso 2: Solución rápida - Obtener cert temporal
# Opción A: Autofirmado (¡solo para interno!)
openssl req -x509 -nodes -days 30 -newkey rsa:2048 \
  -keyout /etc/pki/tls/private/temp-web01-example-com.key \
  -out /etc/pki/tls/certs/temp-web01-example-com.crt \
  -subj "/CN=$(hostname)"

# Opción B: Restaurar desde respaldo
cp /var/backups/certificates/latest/*.crt /etc/pki/tls/certs/
cp /var/backups/certificates/latest/*.key /etc/pki/tls/private/

# Paso 3: Actualizar configuración del servicio para usar cert temporal
# Editar /etc/httpd/conf.d/ssl.conf
# SSLCertificateFile /etc/pki/tls/certs/temp-web01-example-com.crt
# SSLCertificateKeyFile /etc/pki/tls/private/temp-web01-example-com.key

# Paso 4: Reiniciar servicio
systemctl restart httpd

# Paso 5: Obtener certificado apropiado LO ANTES POSIBLE
# Seguir proceso normal de solicitud de cert

# Paso 6: Documentar incidente
# Qué sucedió, por qué, cómo se arregló, prevención

21.11 Lista de Verificación de Mejores Prácticas

## Lista de Verificación de Gestión de Certificados

### Organización de Archivos
- [ ] Estructura de directorio estándar usada
- [ ] Convención de nomenclatura consistente
- [ ] Permisos de archivo apropiados (600 para claves, 644 para certs)
- [ ] Contextos SELinux correctos

### Gestión del Ciclo de Vida
- [ ] Proceso de renovación definido y documentado
- [ ] Recordatorios de renovación establecidos (60, 30, 7 días)
- [ ] Renovación automatizada si es posible (certmonger)
- [ ] Acciones post-renovación definidas

### Seguridad
- [ ] Claves privadas protegidas (permisos 600)
- [ ] Claves nunca compartidas/enviadas por email
- [ ] Algoritmo de clave fuerte (RSA 2048+ o EC P-256)
- [ ] Firma fuerte (SHA-256+)

### Respaldo
- [ ] Certificados respaldados
- [ ] Claves privadas respaldadas (cifradas)
- [ ] Respaldo probado y validado
- [ ] Procedimiento de restauración documentado

### Documentación
- [ ] Inventario de certificados mantenido
- [ ] Cada certificado documentado
- [ ] Procedimientos escritos
- [ ] Contactos listados

### Monitoreo
- [ ] Monitoreo de expiración habilitado
- [ ] Alertas configuradas
- [ ] Verificaciones de salud en lugar
- [ ] Plan de respuesta a incidentes listo

### Validación
- [ ] Validación pre-despliegue
- [ ] Pruebas post-despliegue
- [ ] Auditorías regulares programadas

21.12 Conclusiones Clave

1. La organización previene confusión - Estructura y nomenclatura consistentes
2. Los permisos son críticos - 600 para claves, 644 para certs
3. Automatizar renovación - Usar certmonger cuando sea posible
4. Respaldar todo - Pero cifrar claves privadas
5. Documentar exhaustivamente - Tu yo futuro te lo agradecerá
6. Monitorear proactivamente - No esperar a la expiración
7. Validar antes de desplegar - Capturar problemas temprano
8. Planificar para incidentes - Tener procedimientos de recuperación listos

Referencia Rápida

┌──────────────────────────────────────────────────────────────┐
│ MEJORES PRÁCTICAS CERTIFICADOS DE SERVICIO                   │
├──────────────────────────────────────────────────────────────┤
│ Archivos:    /etc/pki/tls/certs/*.crt (644)                  │
│              /etc/pki/tls/private/*.key (600)                │
│ Nombres:     [servicio]-[host]-[dominio].[crt|key]           │
│ Renovación:  Automatizar con certmonger                      │
│ Respaldo:    Diario, cifrado, probado                        │
│ Monitoreo:   60, 30, 7 días antes de expirar                 │
│ Validar:     Antes de cada despliegue                        │
│ Documentar:  Todo, siempre                                   │
└──────────────────────────────────────────────────────────────┘

Navegación del Capítulo

Capítulo 22: Dominio de certmonger

Configúralo y Olvídalo: certmonger es la herramienta de automatización de certificados integrada en RHEL. Domínala y nunca renovarás un certificado manualmente otra vez.

22.1 ¿Qué es certmonger?

certmonger es un demonio de rastreo de certificados y renovación automática para RHEL.

Piénsalo como:

• 📋 Rastreador de certificados - Monitorea fechas de expiración
• 🔄 Renovador automático - Renueva antes de expirar
• 🔗 Integrador de CA - Funciona con FreeIPA, CAs locales/internas y helpers de CA externa
• ⚙️ Integración de servicios - Ejecuta comandos después de renovación

¿Por Qué certmonger?

Sin certmonger:

❌ Rastreo manual de fechas de expiración
❌ Recordatorios de calendario para renovar
❌ Generación manual de CSR
❌ Reinicio manual de servicio después de renovación
❌ Riesgo de perder renovaciones → interrupciones

Con certmonger:

✅ Rastreo automático
✅ Renovación automática
✅ Recarga automática de servicio
✅ Monitoreo centralizado
✅ ¡Sin intervención manual!

22.2 Instalación y Configuración

Todas las Versiones RHEL

#============================================#
# INSTALAR CERTMONGER
#============================================#

# Instalar
sudo dnf install certmonger -y

# Habilitar e iniciar
sudo systemctl enable certmonger
sudo systemctl start certmonger

# Verificar
systemctl status certmonger
sudo getcert list  # Debería mostrar lista vacía inicialmente

22.3 Uso Básico

Solicitar un Certificado

#============================================#
# SOLICITUD BÁSICA DE CERTIFICADO
#============================================#

# Autofirmado (para pruebas)
sudo getcert request \
  -f /etc/pki/tls/certs/test.crt \
  -k /etc/pki/tls/private/test.key

# De FreeIPA
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/web.crt \
  -k /etc/pki/tls/private/web.key \
  -K HTTP/$(hostname -f)@REALM \
  -D $(hostname -f)

# Para certificados públicos de Let's Encrypt, usa certbot (Capítulo 24).
# certmonger es la opción nativa para IPA, CA local y flujos basados en helpers.

Verificar Estado

#============================================#
# VERIFICAR ESTADO DE CERTIFICADO
#============================================#

# Listar todos los certificados rastreados
sudo getcert list

# Verificar certificado específico por archivo
sudo getcert list -f /etc/pki/tls/certs/web.crt

# Verificar por ID de solicitud
sudo getcert list -i 20240101000000

# Salida verbosa
sudo getcert list -v

Valores de Estado:

• MONITORING: ✅ Certificado emitido, rastreando expiración
• SUBMITTING: 🔄 Enviando solicitud a CA
• CA_UNREACHABLE: ❌ No se puede alcanzar servidor CA
• CA_REJECTED: ❌ CA rechazó solicitud
• NEED_KEY_GEN_PIN: ⏸️ Esperando PIN (HSM/token)
• PRE_SAVE_COMMAND: 🔄 Ejecutando script pre-guardado
• POST_SAVE_COMMAND: 🔄 Ejecutando script post-guardado

22.4 Opciones Avanzadas

Solicitud Completa con Todas las Opciones

#============================================#
# SOLICITUD COMPLETA CERTMONGER
#============================================#

sudo ipa-getcert request \
  -f /etc/pki/tls/certs/web.example.com.crt \              # Archivo de certificado
  -k /etc/pki/tls/private/web.example.com.key \            # Archivo de clave privada
  -K HTTP/web.example.com@EXAMPLE.COM \                    # Principal Kerberos
  -D web.example.com \                                     # Nombre DNS (SAN)
  -D www.example.com \                                     # SAN adicional
  -D api.example.com \                                     # Otro SAN
  -U id-kp-serverAuth \                                    # Uso de clave extendido
  -N CN=web.example.com,O=Example,C=US \                   # DN del sujeto
  -g 2048 \                                                # Tamaño de clave
  -G rsa \                                                 # Tipo de clave
  -T caIPAserviceCert \                                    # Perfil IPA
  -C "systemctl reload httpd" \                            # Comando post-guardado
  -B "systemctl stop httpd" \                              # Comando pre-guardado
  -v \                                                     # Verboso
  -w                                                       # Esperar completitud

# Verificar estado
sudo getcert list -f /etc/pki/tls/certs/web.example.com.crt

Opciones Clave Explicadas:

22.5 Trabajar con Diferentes CAs

FreeIPA (Recomendado para Interno)

#============================================#
# CERTMONGER + FREEIPA
#============================================#

# Prerrequisitos: Sistema inscrito a IPA
ipa-client-install

# Solicitar certificado
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/internal.crt \
  -k /etc/pki/tls/private/internal.key \
  -K HTTP/$(hostname -f)@REALM \
  -D $(hostname -f) \
  -C "systemctl reload httpd"

# certmonger automáticamente:
# ✅ Envía solicitud a CA IPA
# ✅ Obtiene certificado
# ✅ Guarda en archivo
# ✅ Ejecuta comando de recarga
# ✅ Rastrea expiración
# ✅ Renueva ~28 días antes de expirar

ACME público requiere certbot

#============================================#
# ACME PÚBLICO VS FLUJOS NATIVOS DE CERTMONGER
#============================================#

# Certificado público de Let's Encrypt:
# Usa certbot, no un perfil de CA falso en certmonger.
sudo certbot certonly --apache -d public.example.com

# Certificado nativo de FreeIPA / IdM:
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/internal.crt \
  -k /etc/pki/tls/private/internal.key \
  -K HTTP/$(hostname -f)@REALM \
  -D $(hostname -f) \
  -C "systemctl reload httpd"

CA Externa (Envío Manual)

#============================================#
# CERTMONGER CON CA EXTERNA
#============================================#

# Configurar helper de CA externa
sudo getcert add-ca -c external-ca \
  -e '/usr/local/bin/external-ca-submit.sh'

# Solicitar certificado
sudo getcert request \
  -c external-ca \
  -f /etc/pki/tls/certs/external.crt \
  -k /etc/pki/tls/private/external.key

# El script helper debe:
# 1. Leer CSR desde stdin
# 2. Enviar a CA externa
# 3. Retornar certificado en stdout

22.6 Gestionar Certificados Rastreados

Modificar Rastreo

#============================================#
# MODIFICAR RASTREO DE CERTIFICADO EXISTENTE
#============================================#

# Actualizar comando post-guardado sin rekey
sudo getcert stop-tracking -f /etc/pki/tls/certs/web.crt
sudo getcert start-tracking \
  -f /etc/pki/tls/certs/web.crt \
  -k /etc/pki/tls/private/web.key \
  -C "systemctl reload httpd"
# Vuelva a añadir -c, -K, -D, etc. si la entrada original los usaba

# Agregar SAN adicional
sudo getcert resubmit -f /etc/pki/tls/certs/web.crt \
  -D additional.example.com

# Dejar de rastrear (mantener certificado)
sudo getcert stop-tracking -f /etc/pki/tls/certs/web.crt

# Eliminar completamente
sudo getcert stop-tracking -f /etc/pki/tls/certs/web.crt -r

# Comenzar a rastrear certificado existente
sudo getcert start-tracking \
  -f /etc/pki/tls/certs/existing.crt \
  -k /etc/pki/tls/private/existing.key

Forzar Renovación

#============================================#
# FORZAR RENOVACIÓN INMEDIATA
#============================================#

# Por ruta de archivo
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/web.crt

# Por ID de solicitud
sudo getcert resubmit -i 20240101000000

# Esperar renovación
sudo getcert list -f /etc/pki/tls/certs/web.crt
# Esperar estado: MONITORING

22.7 Tiempo de Renovación

Entender Ventanas de Renovación

Ciclo de Vida del Certificado (365 días):

Día   0: Certificado emitido
      │
      │ [Operación normal]
      │
Día 243: Comienza ventana de renovación (certmonger intenta renovación)
      │ (2/3 del tiempo de vida del cert: 365 × 2/3 ≈ 243 días)
      │
      │ [Intentos de renovación cada 8 horas si CA disponible]
      │
Día 335: Advertencia si aún no renovado (quedan 30 días)
      │
Día 350: Crítico si aún no renovado (quedan 15 días)
      │
Día 365: El certificado expira → ¡INTERRUPCIÓN DEL SERVICIO si no se renueva!

Comportamiento Predeterminado:

• La renovación comienza a 2/3 del tiempo de vida del certificado
• Cert de 365 días → Renueva en día 243 (quedan 122 días)
• Cert de 90 días → Renueva en día 60 (quedan 30 días)

22.8 Comandos Post-Guardado

Reload vs Restart

#============================================#
# ESTRATEGIAS DE COMANDO POST-GUARDADO
#============================================#

# PREFERIR: reload (sin tiempo de inactividad)
-C "systemctl reload httpd"
-C "systemctl reload nginx"
-C "postfix reload"

# A VECES NECESARIO: restart
-C "systemctl restart slapd"  # OpenLDAP requiere restart
-C "systemctl restart postgresql"  # PostgreSQL requiere restart

# MÚLTIPLES COMANDOS: Usar script
-C "/usr/local/bin/after-cert-renewal.sh"

# Ejemplo de script:
#!/bin/bash
# /usr/local/bin/after-cert-renewal.sh
systemctl reload httpd
systemctl reload nginx
systemctl reload postfix
logger "Certificados renovados vía certmonger"

22.9 Solución de Problemas certmonger

Problemas Comunes

Problema 1: CA_UNREACHABLE

# Síntoma
sudo getcert list
# status: CA_UNREACHABLE

# Diagnóstico
# Para FreeIPA:
ipa ping  # Verificar conectividad IPA
klist  # Verificar ticket Kerberos

# Solución
kinit -k host/$(hostname -f)@REALM  # Renovar ticket de host
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/web.crt

# Verificar servidor IPA
ssh ipa-server "sudo ipactl status"

Problema 2: CA_REJECTED

# Síntoma
sudo getcert list
# status: CA_REJECTED
# ca-error: Server at https://ipa.example.com/ipa/xml unwilling to issue certificate

# Causas comunes:
# 1. Principal de servicio no existe
ipa service-show HTTP/$(hostname -f)
# Si no se encuentra:
ipa service-add HTTP/$(hostname -f)

# 2. Host no inscrito
ipa host-show $(hostname -f)

# 3. Problema de permisos
# Verificar permisos IPA

# Reintentar
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/web.crt

Problema 3: Renovación No Está Ocurriendo

# Verificar que certmonger está ejecutándose
systemctl status certmonger

# Verificar estado del certificado
sudo getcert list -f /etc/pki/tls/certs/web.crt

# Verificar logs de certmonger
sudo journalctl -u certmonger -f

# Forzar renovación
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/web.crt

# Verificar ventana de renovación
# El certificado renueva a 2/3 del tiempo de vida
# Verificar fecha "expires" en salida de getcert list

22.10 IdM ACME vs Let’s Encrypt público

Mantén separados los flujos

#============================================#
# ELIGE LA HERRAMIENTA CORRECTA PARA LA CA CORRECTA
#============================================#

# Certificado público de Let's Encrypt:
# Usa certbot (ver Capítulo 24).
sudo certbot certonly --apache -d public.example.com -d www.public.example.com

# Certificado nativo de FreeIPA / IdM:
# Usa certmonger + ipa-getcert.
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/internal.example.com.crt \
  -k /etc/pki/tls/private/internal.example.com.key \
  -K HTTP/internal.example.com@REALM \
  -D internal.example.com \
  -C "systemctl reload httpd"

# Si IdM ACME está habilitado, su directorio ACME es tu servidor IPA,
# no Let's Encrypt:
sudo certbot certonly \
  --server https://ipa.example.com/acme/directory \
  -d host.example.com

Distinción importante:

• Let’s Encrypt = CA ACME pública de internet
• IdM/FreeIPA ACME = tu CA IPA interna exponiendo un endpoint ACME
• certmonger = rastreador/renovador nativo de RHEL para IPA y flujos basados en helpers

22.11 Monitorear certmonger

Monitoreo de Estado

#============================================#
# MONITOREAR CERTMONGER
#============================================#

# Resumen de todos los certificados
sudo getcert list

# Contar certificados por estado
sudo getcert list | grep "status:" | sort | uniq -c

# Encontrar certificados expirando pronto (30 días)
for cert in $(sudo getcert list | grep "certificate:" | sed -n "s/.*location='\\([^']*\\)'.*/\\1/p"); do
  if ! openssl x509 -in "$cert" -noout -checkend $((86400*30)) 2>/dev/null; then
    echo "⚠️ Expira pronto: $cert"
  fi
done

# Verificar logs de certmonger
sudo journalctl -u certmonger --since today

# Observar actividad de renovación
sudo journalctl -u certmonger -f

# Verificar próximo tiempo de renovación
sudo getcert list | grep -A15 "Request ID" | grep "expires"

Script de Verificación de Salud

#!/bin/bash
# certmonger-health-check.sh

echo "=== Verificación de Salud certmonger ==="

# ¿certmonger ejecutándose?
if systemctl is-active --quiet certmonger; then
  echo "✅ certmonger está ejecutándose"
else
  echo "❌ ¡certmonger NO está ejecutándose!"
  exit 1
fi

# Contar certificados rastreados
TOTAL=$(sudo getcert list | grep -c "Request ID")
echo "📋 Rastreando $TOTAL certificados"

# Verificar desglose de estado
echo ""
echo "Desglose de estado:"
sudo getcert list | grep "status:" | sort | uniq -c

# Verificar problemas
PROBLEMS=$(sudo getcert list | grep "status:" | grep -v "MONITORING" | wc -l)
if [ $PROBLEMS -gt 0 ]; then
  echo ""
  echo "⚠️ $PROBLEMS certificados necesitan atención:"
  sudo getcert list | grep -B5 "status:" | grep -E "(Request ID|status:)" | grep -v "MONITORING"
fi

# Verificar advertencias de expiración
echo ""
echo "Certificados expirando en 30 días:"
sudo getcert list | grep -A10 "Request ID" | grep "expires:" | \
  while read line; do
    # Parsear y verificar expiración
    # (simplificado - script de producción parsearía fechas apropiadamente)
    echo "$line"
  done

22.12 Configuración de certmonger

Archivo de Configuración Principal

#============================================#
# CONFIGURACIÓN CERTMONGER
#============================================#

# Ubicación de configuración
/etc/certmonger/certmonger.conf

# Ubicación de base de datos (certificados rastreados)
/var/lib/certmonger/

# Listar CAs configuradas
sudo getcert list-cas

# Agregar CA personalizada
sudo getcert add-ca -c my-ca \
  -e '/usr/local/bin/my-ca-submit.sh'

# Eliminar CA
sudo getcert remove-ca -c my-ca

22.13 Mejores Prácticas

Mejores Prácticas de certmonger

✅ **Siempre usar comandos post-guardado** (flag -C) para recargar servicios
✅ **Rastrear todos los certificados de producción** con certmonger
✅ **Monitorear estado semanalmente** con `getcert list`
✅ **Probar renovación** antes de expirar con `resubmit`
✅ **Usar modo verboso** (-v) al resolver problemas
✅ **Configurar monitoreo** para estado CA_UNREACHABLE
✅ **Documentar IDs de solicitud** en tu inventario de certificados
✅ **Usar IPA/certmonger para certificados internos** y certbot para Let's Encrypt público
✅ **Mantener logs de certmonger** para pista de auditoría
✅ **Probar comandos post-guardado** independientemente antes de usar

Qué Rastrear con certmonger

# ✅ RASTREAR con certmonger:
- Certificados de servidor web (Apache, NGINX)
- Certificados de servidor de correo (Postfix, Dovecot)
- Certificados de servidor LDAP (OpenLDAP)
- Certificados de aplicación (APIs, microservicios)
- Certificados de servicio (cualquier servicio habilitado para TLS)

# ❌ NO rastrear con certmonger:
- Certificados raíz CA (gestionados separadamente)
- Certificados de cliente para usuarios (ciclo de vida diferente)
- Certificados de prueba/temporales
- Certificados que gestionas con otras herramientas (certbot)

22.14 certmonger vs certbot

¿Cuándo Usar Cuál?

Recomendación:

• Interno/Empresa: Usar certmonger + FreeIPA
• Público/Simple: Usar certbot (pero saber que requiere EPEL)
• Certificados públicos en cualquier versión RHEL: usar certbot para Let’s Encrypt

22.15 Escenarios Avanzados

Escenario 1: Renovación de Certificado de Alta Disponibilidad

# Múltiples servidores con mismo servicio

# Servidor 1:
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/shared-service.crt \
  -k /etc/pki/tls/private/shared-service.key \
  -K HTTP/service.example.com@REALM \
  -D service.example.com \
  -C "systemctl reload httpd"

# Servidor 2: Misma configuración
# Resultado: Cada servidor gestiona su propio cert independientemente
# O: Usar cert compartido (copiar archivos, no recomendado)

Escenario 2: Certificado Comodín

# Solicitar comodín de FreeIPA
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/wildcard.crt \
  -k /etc/pki/tls/private/wildcard.key \
  -K HTTP/*.example.com@REALM \
  -D *.example.com \
  -D example.com \
  -C "/usr/local/bin/reload-all-services.sh"

Escenario 3: Claves EC (Curva Elíptica)

# Solicitar con clave EC
sudo ipa-getcert request \
  -f /etc/pki/tls/certs/ec-cert.crt \
  -k /etc/pki/tls/private/ec-cert.key \
  -K HTTP/$(hostname -f)@REALM \
  -G ec \
  -g nistp256  # o nistp384, nistp521

22.16 Conclusiones Clave

1. certmonger es la automatización de certificados de RHEL
2. Configúralo y olvídalo - Renovación automática
3. Funciona mejor con FreeIPA, CAs internas y renovaciones basadas en helpers
4. Comandos post-guardado recargan servicios automáticamente
5. Rastrea expiración y renueva a 2/3 del tiempo de vida
6. Estado MONITORING significa que todo está bien
7. getcert list es tu herramienta principal de monitoreo

Tarjeta de Referencia Rápida

┌──────────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA DOMINIO DE CERTMONGER                          │
├──────────────────────────────────────────────────────────────────┤
│ Instalar:        dnf install certmonger                          │
│ Iniciar:         systemctl enable --now certmonger               │
│                                                                  │
│ Solicitar:       ipa-getcert request -f cert -k key -K principal │
│ Listar:          getcert list                                    │
│ Estado:          getcert list -f /path/to/cert.crt               │
│ Reenviar:        ipa-getcert resubmit -f /path/to/cert.crt       │
│ Dejar rastrear:  getcert stop-tracking -f /path/to/cert.crt      │
│                                                                  │
│ Estado:          MONITORING = ✅ Bien                            │
│                  CA_UNREACHABLE = ❌ Verificar IPA/CA            │
│                  CA_REJECTED = ❌ Verificar principal/permisos   │
│                                                                  │
│ Logs:            journalctl -u certmonger -f                     │
│ Renovación:      Automática a 2/3 del tiempo de vida del cert    │
│ Post-save:       -C "systemctl reload <servicio>"                │
└──────────────────────────────────────────────────────────────────┘

✅ Herramienta nativa RHEL (soportada por Red Hat)
✅ Perfecta para integración FreeIPA
✅ Mejor encaje para FreeIPA y flujos de renovación con seguimiento

🧪 Laboratorio Práctico

Lab 11: Fundamentos de certmonger

Automatiza la renovación de certificados con certmonger

• 📁 Ubicación: labs/es_ES/11-certmonger-basics/
• ⏱️ Tiempo: 30-35 minutos
• 🎯 Nivel: Intermedio

Navegación del Capítulo

Capítulo 23: Inmersión Profunda en Crypto-Policies

Característica Revolucionaria: Las crypto-policies de RHEL 8+ proporcionan configuración criptográfica en todo el sistema. Domina esto y controlarás la seguridad en todas las aplicaciones con un solo comando.

23.1 El Problema que crypto-policies Resuelve

Antes de Crypto-Policies (RHEL 7)

Configurar seguridad individualmente para CADA aplicación:

Apache:      /etc/httpd/conf.d/ssl.conf
             SSLProtocol, SSLCipherSuite

NGINX:       /etc/nginx/nginx.conf
             ssl_protocols, ssl_ciphers

Postfix:     /etc/postfix/main.cf
             smtpd_tls_protocols, smtpd_tls_mandatory_ciphers

OpenLDAP:    olcTLSProtocolMin, olcTLSCipherSuite

PostgreSQL:  ssl_min_protocol_version

OpenSSH:     /etc/ssh/sshd_config
             Ciphers, MACs, KexAlgorithms

... ¡y más de 20 aplicaciones!

Resultado: Seguridad inconsistente, pesadilla de configuración

Después de Crypto-Policies (RHEL 8/9/10)

✅ Establecer UNA política en todo el sistema
✅ Todas las aplicaciones cumplen automáticamente
✅ Seguridad consistente en todo el sistema
✅ Cambiar política en segundos, no horas

¡Cambio de juego para gestión empresarial!

23.2 Cómo Funcionan las Crypto-Policies

Arquitectura

┌──────────────────────────────────────────────────┐
│       update-crypto-policies --set DEFAULT       │
│            (Comando del administrador)           │
└───────────────────────┬──────────────────────────┘
                        │
                        ▼
┌──────────────────────────────────────────────────┐
│  /etc/crypto-policies/back-ends/                 │
│  (Archivos de configuración generados para cada  │
│  biblioteca)                                     │
│  ├─ opensslcnf.config                            │
│  ├─ gnutls.config                                │
│  ├─ nss.config                                   │
│  ├─ bind.config                                  │
│  └─ ... más ...                                  │
└───────────────────────┬──────────────────────────┘
                        │
            ┌───────────┼───────────┐
            ▼           ▼           ▼
         OpenSSL     GnuTLS        NSS
            ↓           ↓           ↓
         Apache      NGINX       Firefox
         Postfix     vsftpd      Thunderbird
         OpenSSH     wget        Java apps

Concepto Clave: ¡Las aplicaciones leen de archivos back-end, no directamente de la política!

23.3 Las Cuatro Políticas Principales

Comparación de Políticas

Detalles de Política DEFAULT

# Seguridad y compatibilidad equilibradas
Protocolos:
  - TLS 1.2
  - TLS 1.3

Tamaños Mínimos de Clave:
  - RSA: 2048 bits
  - DH: 2048 bits
  - ECC: secp256r1 (P-256)

Cifrados Permitidos:
  - AES-128-GCM
  - AES-256-GCM
  - ChaCha20-Poly1305
  - AES-128-CBC
  - AES-256-CBC

Algoritmos de Firma:
  - SHA-256
  - SHA-384
  - SHA-512

Bloqueados:
  - TLS 1.0, 1.1
  - MD5
  - Firmas SHA-1
  - 3DES, RC4, DES
  - RSA < 2048 bits
  - Cifrados de exportación

23.4 Ver y Cambiar Políticas

Comandos Básicos

#============================================#
# OPERACIONES BÁSICAS CRYPTO-POLICY
#============================================#

# Ver política actual
update-crypto-policies --show
# Salida: DEFAULT

# Listar políticas disponibles
ls /usr/share/crypto-policies/policies/
# DEFAULT.pol  FUTURE.pol  LEGACY.pol  FIPS.pol

# Establecer política
sudo update-crypto-policies --set FUTURE

# ¡DEBES reiniciar servicios para que los cambios tengan efecto!
sudo systemctl restart httpd nginx postfix slapd

# O reiniciar (asegura que todo recoja los cambios)
sudo reboot

Qué Sucede Cuando Cambias la Política

#============================================#
# DETRÁS DE ESCENA
#============================================#

# Antes
update-crypto-policies --show
# DEFAULT

# Cambiar
sudo update-crypto-policies --set FUTURE

# Actualizaciones generadas:
ls -l /etc/crypto-policies/back-ends/
# -rw-r--r--. opensslcnf.config    ← ¡Actualizado!
# -rw-r--r--. gnutls.config        ← ¡Actualizado!
# -rw-r--r--. nss.config           ← ¡Actualizado!
# -rw-r--r--. bind.config          ← ¡Actualizado!
# ... todos los back-ends actualizados ...

# Ver configuración de OpenSSL
cat /etc/crypto-policies/back-ends/opensslcnf.config
# Muestra configuración real de OpenSSL aplicada

23.5 Subpolíticas (RHEL 9+)

Modificadores de Política

RHEL 9 introdujo subpolíticas - ¡afinar políticas existentes!

#============================================#
# SUBPOLÍTICAS CRYPTO-POLICY (RHEL 9+)
#============================================#

# Política base con modificador
sudo update-crypto-policies --set DEFAULT:NO-SHA1

# Múltiples modificadores
sudo update-crypto-policies --set DEFAULT:NO-SHA1:GOST

# Módulos de subpolítica disponibles
ls /usr/share/crypto-policies/policies/modules/
# AD-SUPPORT.pmod
# GOST.pmod
# NO-CAMELLIA.pmod
# NO-SHA1.pmod
# NO-ENFORCE-EMS.pmod
# ...y más

# Ver detalles del módulo
cat /usr/share/crypto-policies/policies/modules/NO-SHA1.pmod

Subpolíticas Comunes:

23.6 Crear Módulos de Política Personalizados

Ejemplo de Módulo Personalizado

#============================================#
# CREAR MÓDULO DE POLÍTICA PERSONALIZADO
#============================================#

# Crear módulo personalizado
sudo vi /etc/crypto-policies/policies/modules/CUSTOM-SECURITY.pmod

# Contenido de ejemplo:
min_rsa_size = 4096
min_dh_size = 3072
min_dsa_size = 3072
sha1_in_certs = 0
arbitrary_dh_groups = 0
ssh_certs = 0

# Aplicar
sudo update-crypto-policies --set DEFAULT:CUSTOM-SECURITY

# Reiniciar servicios
sudo systemctl restart httpd nginx postfix

# Verificar
openssl ciphers -v | grep -E "RSA|DH"

23.7 Sobrescrituras por Aplicación

Cuándo Sobrescribir

A veces UNA aplicación necesita ajustes diferentes de la política del sistema:

Ejemplo: La aplicación legacy necesita TLS 1.1, pero el sistema usa DEFAULT

Sobrescritura de Apache

#============================================#
# SOBRESCRITURA CRYPTO-POLICY DE APACHE
#============================================#

# /etc/httpd/conf.d/ssl.conf

# Opción 1: Incluir crypto-policy, luego sobrescribir
Include /etc/crypto-policies/back-ends/httpd.config

# Luego agregar sobrescrituras:
SSLProtocol all -SSLv3  # Re-habilitar TLS 1.0/1.1

# Opción 2: Optar completamente por no usar
# No incluir archivo crypto-policy
# Configurar manualmente todo:
SSLProtocol TLSv1.1 TLSv1.2 TLSv1.3
SSLCipherSuite HIGH:!aNULL:!MD5

# ⚠️ Advertencia: Ahora gestionas TLS de Apache manualmente
# Los cambios de crypto-policy del sistema no afectarán Apache

Mejor Enfoque: ¡Crear módulo de política personalizado en lugar de sobrescrituras por app!

23.8 Probar Impacto de Política

Antes de Cambiar Política

#============================================#
# PROBAR IMPACTO DE CAMBIO DE POLÍTICA
#============================================#

# 1. Documentar estado actual
update-crypto-policies --show > /tmp/current-policy.txt
systemctl list-units --type=service --state=running > /tmp/running-services.txt

# 2. Probar aplicaciones
curl https://localhost/
psql -h localhost  # etc.

# 3. Cambiar política en sistema de prueba primero
sudo update-crypto-policies --set FUTURE

# 4. Reiniciar servicios
sudo systemctl restart httpd nginx postfix

# 5. Probar exhaustivamente
./test-all-services.sh

# 6. Si hay problemas: Revertir
sudo update-crypto-policies --set DEFAULT

# 7. Si exitoso: Documentar y desplegar a producción

23.9 Impacto de Política en Certificados

Qué Controlan las Políticas

Crypto-policies afectan:

• ✅ Versiones de protocolo TLS permitidas
• ✅ Suites de cifrado disponibles
• ✅ Tamaños mínimos de clave aceptados
• ✅ Algoritmos de firma permitidos
• ✅ Parámetros Diffie-Hellman
• ✅ Rigurosidad de validación de certificado

Crypto-policies NO afectan:

• ❌ Qué certificados usar (aún configurado por servicio)
• ❌ Ubicaciones de archivos de certificado
• ❌ Almacén de confianza CA (eso es update-ca-trust)
• ❌ Emisión de certificados

Matriz de Compatibilidad de Certificados

23.10 Solución de Problemas Crypto-Policies

Problemas Comunes

Problema 1: La Aplicación Falla Después de Cambio de Política

# Síntoma
sudo update-crypto-policies --set FUTURE
sudo systemctl restart httpd
# httpd falla al iniciar

# Diagnóstico
sudo journalctl -xe -u httpd | grep -i cipher

# Causa común: La aplicación tiene cifrados débiles codificados

# Solución 1: Revertir política
sudo update-crypto-policies --set DEFAULT

# Solución 2: Actualizar configuración de aplicación
# Eliminar especificaciones de cifrado codificadas

# Solución 3: Crear módulo de política personalizado

Problema 2: “No Shared Cipher”

# Síntoma: Los clientes no pueden conectar

# Probar
openssl s_client -connect server:443

# Si muestra "no shared cipher":

# Verificar política
update-crypto-policies --show

# Probar capacidades del cliente
openssl s_client -connect server:443 -cipher 'ALL' -tls1_2

# Solución temporal (no recomendada a largo plazo):
sudo update-crypto-policies --set LEGACY

# Solución apropiada: Actualizar cliente para soportar TLS 1.2+ y cifrados modernos

Problema 3: La Política No Parece Aplicarse

# Verificar si la aplicación está sobrescribiendo la política

# Apache
grep -r "SSLProtocol\|SSLCipherSuite" /etc/httpd/
# Si se encuentra: La app está sobrescribiendo la política

# NGINX
grep -r "ssl_protocols\|ssl_ciphers" /etc/nginx/
# Si se encuentra: La app está sobrescribiendo la política

# Solución: Eliminar sobrescrituras, dejar que crypto-policy lo maneje
# O: Documentar por qué la sobrescritura es necesaria

23.11 Mejores Prácticas

Recomendaciones

✅ **Usar política DEFAULT** para la mayoría de entornos
✅ **Probar antes de desplegar** nuevas políticas
✅ **Documentar elecciones de política** y razones
✅ **Reiniciar servicios** después de cambios de política
✅ **Evitar sobrescrituras por app** cuando sea posible
✅ **Usar subpolíticas** (RHEL 9+) para ajuste fino
✅ **Monitorear problemas** de compatibilidad
✅ **Mantener LEGACY temporal** si se usa
✅ **Planificar migraciones** al cambiar políticas
✅ **Actualizar clientes** en lugar de debilitar política

Cuándo Usar Cada Política

DEFAULT:

• ✅ La mayoría de entornos de producción
• ✅ Seguridad/compatibilidad equilibrada
• ✅ Punto de partida recomendado
• ✅ Probada y mantenida por Red Hat

LEGACY:

• ⚠️ ¡Solo temporal durante migraciones!
• ⚠️ Soportar clientes muy antiguos
• ⚠️ Probar problemas de compatibilidad
• ❌ ¡Nunca a largo plazo!

FUTURE:

• ✅ Entornos de alta seguridad
• ✅ Todos los clientes son modernos
• ✅ Quieres los ajustes más fuertes
• ✅ Planificación para estándares futuros

FIPS:

• ✅ Cumplimiento federal requerido
• ✅ Contratos gubernamentales
• ✅ Industrias reguladas
• ✅ Requisitos de certificación

23.12 Inmersión Profunda en Política FIPS

Habilitar Modo FIPS

#============================================#
# HABILITAR MODO FIPS
#============================================#

# Verificar estado actual
fips-mode-setup --check
# FIPS mode is disabled.

# Habilitar modo FIPS
sudo fips-mode-setup --enable

# SE DEBE reiniciar
sudo reboot

# Verificar después de reiniciar
fips-mode-setup --check
# FIPS mode is enabled.

# Crypto-policy automáticamente establecida a FIPS
update-crypto-policies --show
# FIPS

Requisitos del Modo FIPS:

• Debe habilitarse en instalación O con fips-mode-setup
• Requiere reinicio
• Afecta todo el sistema
• Solo algoritmos aprobados por FIPS disponibles
• Impacto en rendimiento (~10-20% más lento)

Especificaciones de Política FIPS

# Qué permite la política FIPS:
✅ TLS 1.2, 1.3
✅ RSA 2048+ bits
✅ AES-128, AES-256 (modo GCM)
✅ SHA-256, SHA-384, SHA-512
✅ Intercambio de clave ECDHE

# Qué bloquea FIPS:
❌ TLS 1.0, 1.1
❌ RSA < 2048 bits
❌ 3DES, RC4, DES
❌ MD5, SHA-1
❌ Algoritmos no aprobados
❌ Cifrados modo CBC (en algunos casos)

23.13 Monitoreo y Auditoría

Verificar Cumplimiento de Política

#============================================#
# VERIFICAR CUMPLIMIENTO CRYPTO-POLICY
#============================================#

# Política actual
update-crypto-policies --show

# ¿Qué aplicaciones usan crypto-policies?
ls -l /etc/crypto-policies/back-ends/

# Verificar que OpenSSL sigue la política
openssl ciphers -v | head -20

# Verificar configuración específica de aplicación
# Apache
cat /etc/crypto-policies/back-ends/httpd.config

# Probar conexión real
openssl s_client -connect localhost:443 -tls1_3

# Verificar que no haya sobrescrituras
grep -r "SSLProtocol\|SSLCipherSuite" /etc/httpd/ | grep -v crypto-policies
# Debería estar vacío o comentado

23.14 Flujo de Trabajo de Solución de Problemas

Enfoque Sistemático

¿La aplicación falla después de cambio de política?
    │
    ├─ Paso 1: Identificar error
    │   └─ Verificar logs: journalctl -xe
    │
    ├─ Paso 2: Verificar política activa
    │   └─ update-crypto-policies --show
    │
    ├─ Paso 3: Probar con LEGACY
    │   └─ sudo update-crypto-policies --set LEGACY
    │   └─ Si funciona → problema de cifrado/protocolo
    │
    ├─ Paso 4: Identificar incompatibilidad
    │   └─ openssl s_client -cipher 'ALL' -tls1
    │   └─ Encontrar qué necesita cliente/servidor
    │
    ├─ Paso 5: Elegir solución
    │   ├─ A) Actualizar cliente (mejor)
    │   ├─ B) Crear módulo personalizado (bueno)
    │   └─ C) Sobrescritura por app (último recurso)
    │
    └─ Paso 6: Documentar y desplegar
        └─ Por qué se necesita sobrescritura, plan para eliminar

23.15 Conclusiones Clave

1. Crypto-policies son solo RHEL 8+ (no en RHEL 7)
2. Política DEFAULT es recomendada para la mayoría de casos
3. Los cambios requieren reinicios de servicio para tener efecto
4. Afecta TODAS las aplicaciones crypto en todo el sistema
5. Las subpolíticas proporcionan ajuste fino (RHEL 9+)
6. Evitar sobrescrituras por app cuando sea posible
7. Probar antes de desplegar nuevas políticas
8. ¡LEGACY es solo temporal!

Tarjeta de Referencia Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERENCIA RÁPIDA CRYPTO-POLICIES                            │
├──────────────────────────────────────────────────────────────┤
│ Disponible:     Solo RHEL 8, 9, 10 (no RHEL 7)               │
│                                                              │
│ Ver:            update-crypto-policies --show                │
│ Establecer:     sudo update-crypto-policies --set <POLICY>   │
│ Políticas:      DEFAULT, LEGACY, FUTURE, FIPS                │
│                                                              │
│ Subpolítica:    update-crypto-policies --set DEFAULT:NO-SHA1 │
│                 (solo RHEL 9+)                               │
│                                                              │
│ Back-ends:      /etc/crypto-policies/back-ends/              │
│ Módulos:        /usr/share/crypto-policies/policies/modules/ │
│                                                              │
│ Después cambio: systemctl restart <servicios>                │
│                 O reboot                                     │
│                                                              │
│ DEFAULT:        TLS 1.2+, RSA 2048+, Sin SHA-1               │
│ LEGACY:         TLS 1.0+, permite débiles (¡solo temporal!)  │
│ FUTURE:         TLS 1.2+, RSA 3072+, más estricto            │
│ FIPS:           Cumplimiento federal (requiere modo FIPS)    │
└──────────────────────────────────────────────────────────────┘

⚠️ RHEL 7 no tiene crypto-policies (solo config manual)
✅ DEFAULT funciona para 95% de entornos

🧪 Laboratorio Práctico

Lab 12: Crypto-Policies

Comprende y configura crypto-policies a nivel de sistema

• 📁 Ubicación: labs/es_ES/12-crypto-policies/
• ⏱️ Tiempo: 25-30 minutos
• 🎯 Nivel: Intermedio

Navegación del Capítulo

Capítulo 24: Let’s Encrypt y certbot

Certificados Públicos Gratuitos: Let’s Encrypt proporciona certificados gratuitos y automatizados para sitios web públicos. Aprende cómo usarlo en RHEL con certbot.

24.1 ¿Qué es Let’s Encrypt?

Let’s Encrypt es una Autoridad Certificadora gratuita, automatizada y abierta.

Características Clave:

• ✅ Certificados gratuitos (sin costo)
• ✅ Emisión automatizada (vía protocolo ACME)
• ✅ Renovación automática (cada 60-90 días)
• ✅ Ampliamente confiable (en todos los navegadores principales)
• ✅ Validación de dominio (certificados DV)

Limitaciones:

• ❌ Solo dominios públicos (debe ser accesible por internet para validación)
• ❌ Validez de 90 días (corta duración, requiere automatización)
• ❌ Solo Validación de Dominio (no Organization o Extended Validation)
• ❌ Sin comodín con HTTP-01 (requiere desafío DNS-01)

24.2 Let’s Encrypt en RHEL: ACME público y alternativas nativas

Método 1: certbot (Tradicional)

⚠️ CRÍTICO: EPEL Requerido

certbot NO está disponible en repositorios oficiales de RHEL.

Requiere EPEL (Extra Packages for Enterprise Linux), un repositorio mantenido por la comunidad que NO está oficialmente soportado por Red Hat.

Para Entornos de Producción Empresarial:

• Considera FreeIPA con certmonger (Capítulo 19)
• O CA comercial con certmonger (Capítulo 22)
• O gestión manual de certificados

EPEL es adecuado para:

• Entornos de desarrollo/prueba
• Despliegues pequeños donde el riesgo de EPEL es aceptable
• Situaciones donde certificados gratuitos superan preocupaciones de soporte

Herramienta certbot:

• Automatización completa
• Plugins Apache/NGINX
• Configuración automática
• Temporizadores de renovación
• ⚠️ Requiere EPEL

Método 2: certmonger para CAs internas/privadas

Solución Nativa RHEL:

• ✅ No se necesita EPEL
• ✅ Soportado por Red Hat
• ✅ Mejor encaje para flujos de FreeIPA / IdM y CA local
• ⏸️ Config manual de servidor web (sin plugins Apache/NGINX)
• ❌ No es un reemplazo directo de certbot para Let’s Encrypt público

Usaremos certbot para Let’s Encrypt público y certmonger para flujos internos nativos.

24.3 Instalación de certbot

RHEL 7

#============================================#
# INSTALAR CERTBOT EN RHEL 7 (¡REQUIERE EPEL!)
#============================================#

# ⚠️ ADVERTENCIA: Habilitando repositorio de terceros

# Paso 1: Habilitar EPEL
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y

# Verificar EPEL habilitado
yum repolist | grep epel

# Paso 2: Instalar certbot
sudo yum install certbot python2-certbot-apache python2-certbot-nginx -y

# Verificar
certbot --version

RHEL 8

#============================================#
# INSTALAR CERTBOT EN RHEL 8 (¡REQUIERE EPEL!)
#============================================#

# ⚠️ ADVERTENCIA: Habilitando repositorio de terceros

# Paso 1: Habilitar EPEL
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y

# O si tienes suscripción:
sudo dnf install epel-release -y

# Paso 2: Instalar certbot
sudo dnf install certbot python3-certbot-apache python3-certbot-nginx -y

# Verificar
certbot --version

RHEL 9/10

#============================================#
# INSTALAR CERTBOT EN RHEL 9/10 (¡REQUIERE EPEL!)
#============================================#

# ⚠️ ADVERTENCIA: Habilitando repositorio de terceros

# Paso 1: Habilitar EPEL
sudo dnf install epel-release -y

# Paso 2: Instalar certbot
sudo dnf install certbot python3-certbot-apache python3-certbot-nginx -y

# Verificar
certbot --version

Recuerda: EPEL tiene soporte comunitario. Para producción empresarial, considera FreeIPA + certmonger (solución nativa RHEL).

24.4 Uso de certbot - Apache

Configuración Automática de Apache

#============================================#
# CERTBOT CON APACHE (¡AUTOMATIZADO!)
#============================================#

# Prerrequisitos:
# - Apache instalado y ejecutándose
# - Puerto 80 accesible desde internet
# - Dominio resuelve a este servidor
# - Repositorio EPEL habilitado

# Obtener certificado y auto-configurar Apache
sudo certbot --apache -d www.example.com -d example.com

# certbot hará:
# 1. Generar certificado de Let's Encrypt
# 2. Configurar automáticamente Apache SSL
# 3. Configurar redirección HTTP→HTTPS
# 4. Configurar renovación automática

# Prompts interactivos:
# - Dirección de email (para avisos de renovación)
# - Aceptar ToS
# - ¿Redirigir HTTP a HTTPS? (elegir sí)

# No interactivo (automatización):
sudo certbot --apache \
  -d www.example.com \
  -d example.com \
  --non-interactive \
  --agree-tos \
  --email admin@example.com \
  --redirect

# Ubicación del certificado:
# /etc/letsencrypt/live/www.example.com/fullchain.pem
# /etc/letsencrypt/live/www.example.com/privkey.pem

24.5 Uso de certbot - NGINX

Configuración Automática de NGINX

#============================================#
# CERTBOT CON NGINX (¡AUTOMATIZADO!)
#============================================#

# Prerrequisitos:
# - NGINX instalado y ejecutándose
# - Puerto 80 accesible
# - Dominio resuelve al servidor

# Obtener y configurar
sudo certbot --nginx -d api.example.com

# No interactivo
sudo certbot --nginx \
  -d api.example.com \
  --non-interactive \
  --agree-tos \
  --email admin@example.com \
  --redirect

# ¡certbot actualiza configuración de NGINX automáticamente!
# No se necesita configuración SSL manual

24.6 Modo Manual certbot (Standalone)

Sin Plugin de Servidor Web

#============================================#
# CERTBOT STANDALONE (SIN PLUGIN)
#============================================#

# Usar cuando:
# - El servidor web no es Apache/NGINX
# - Quieres control manual sobre configuración
# - Usas servidor web personalizado

# Obtener solo certificado (no configura servidor)
sudo certbot certonly --standalone \
  -d app.example.com \
  --non-interactive \
  --agree-tos \
  --email admin@example.com

# Certificado guardado en:
# /etc/letsencrypt/live/app.example.com/fullchain.pem
# /etc/letsencrypt/live/app.example.com/privkey.pem

# Configurar manualmente tu servicio para usarlo
# Ejemplo Apache:
# SSLCertificateFile /etc/letsencrypt/live/app.example.com/fullchain.pem
# SSLCertificateKeyFile /etc/letsencrypt/live/app.example.com/privkey.pem

24.7 Renovación

Renovación Automática

#============================================#
# RENOVACIÓN AUTOMÁTICA CERTBOT
#============================================#

# certbot configura automáticamente temporizador de renovación
systemctl list-timers | grep certbot
# Debería mostrar: certbot-renew.timer

# Ver detalles del temporizador
systemctl status certbot-renew.timer

# Probar renovación (simulación - no renueva realmente)
sudo certbot renew --dry-run

# Forzar renovación real (si es necesario)
sudo certbot renew --force-renewal

# Verificar expiración de certificado
sudo certbot certificates

# La renovación se ejecuta dos veces al día
# Renueva certificados expirando dentro de 30 días

Hooks de Renovación

#============================================#
# HOOKS DE RENOVACIÓN (COMANDOS DE DESPLIEGUE)
#============================================#

# Agregar hook para recargar servicio después de renovación
sudo certbot renew --deploy-hook "systemctl reload nginx"

# O crear script de hook
sudo vi /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

#!/bin/bash
systemctl reload httpd
systemctl reload nginx
systemctl reload postfix

sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

# Hooks en /etc/letsencrypt/renewal-hooks/:
# - pre/: Ejecutar antes de renovación
# - post/: Ejecutar después de renovación (incluso si falló)
# - deploy/: Ejecutar después solo de renovación exitosa

24.8 Certificados Comodín

Desafío DNS-01 Requerido