Capítulo 1: Criptografia, Estrutura PKI e Fundamentos

Antes de Começar: Este capítulo constrói a base conceitual que você precisa antes de tocar em um único certificado. Ao final, você entenderá por que a criptografia existe, como ela funciona em nível prático, e o que acontece nos bastidores quando duas máquinas estabelecem uma conexão segura.

1.1 Por Que Usar Criptografia?

Imagine enviar um cartão postal. Qualquer pessoa que o manipule—carteiros, vizinhos, desconhecidos—pode lê-lo. Agora imagine que o cartão postal contém sua senha bancária. É assim que o tráfego de rede não criptografado se parece.

Cada pacote que viaja por uma rede pode ser interceptado, lido, modificado ou forjado. Sem criptografia:

A criptografia resolve todos os quatro problemas. Ela não é opcional em sistemas modernos—é a base de toda comunicação segura.

1.2 Os Quatro Pilares da Segurança da Informação

A criptografia fornece quatro garantias fundamentais. Todo sistema seguro depende de uma combinação destas:

Confidencialidade — “Só você pode ler isto”

A confidencialidade garante que os dados são legíveis apenas pelo destinatário pretendido. Mesmo se um atacante interceptar os dados, ele vê apenas ruído sem sentido.

Como é implementada:

• Criptografia simétrica (AES-256): A mesma chave cifra e decifra. Rápida, usada para dados em massa.
• Criptografia assimétrica (RSA, ECC): Chave pública cifra, chave privada decifra. Usada para troca de chaves.

Contra o que protege: Espionagem.

Integridade — “Isto não foi alterado”

A integridade garante que os dados não foram alterados entre remetente e destinatário. Se um único bit mudar, a modificação é detectada.

Como é implementada:

• Funções hash (SHA-256): Produzem uma impressão digital de tamanho fixo dos dados.
• HMAC: Hash combinado com uma chave secreta para integridade autenticada.
• Assinaturas digitais: Hash assinado com uma chave privada.

 Original:  "Transferir R$100 para Bob"  → SHA-256 → a1b2c3d4...
 Adulterado:"Transferir R$900 para Bob"  → SHA-256 → f7e8d9c0...  ← DIFERENTE!

Contra o que protege: Adulteração.

Autenticidade — “Você é quem diz ser”

A autenticidade prova a identidade da parte comunicante. Quando você se conecta ao site do seu banco, precisa ter certeza de que é realmente seu banco, não um impostor.

Como é implementada:

• Certificados digitais (X.509): Vinculam uma chave pública a uma identidade.
• Autoridades Certificadoras (CAs): Terceiros confiáveis que verificam identidades.
• Assinaturas digitais: Provam que uma mensagem foi criada pelo remetente alegado.

Contra o que protege: Personificação.

Não-Repúdio — “Você não pode negar isto”

O não-repúdio garante que o remetente não pode negar ter enviado uma mensagem ou realizado uma ação. É o equivalente digital de uma assinatura manuscrita em um contrato.

Como é implementado:

• Assinaturas digitais com chaves privadas: Apenas o detentor da chave pode produzir a assinatura.
• Carimbos de tempo: Provam quando uma ação ocorreu.
• Logs de auditoria com integridade criptográfica: Registros à prova de adulteração.

Contra o que protege: Repúdio (negar responsabilidade).

Resumo: Os Quatro Pilares

1.3 Funções Hash: Impressões Digitais de Dados

Uma função hash recebe uma entrada de qualquer tamanho e produz uma saída de tamanho fixo. Pense nela como uma impressão digital para dados.

Propriedades Essenciais

1. Determinística — A mesma entrada sempre produz a mesma saída.

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

2. Unidirecional (Resistência a Pré-imagem) — Não é possível descobrir a entrada a partir da saída.

185f8db32271... → ???  (computacionalmente inviável encontrar a entrada)

3. Resistente a Colisões — É praticamente impossível encontrar duas entradas diferentes que produzam a mesma saída.

SHA-256("entrada A") → hash1
SHA-256("entrada B") → hash2
hash1 ≠ hash2  (com probabilidade esmagadora)

4. Efeito Avalanche — Uma mudança mínima na entrada produz uma saída completamente diferente.

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

Hashes São Seguros?

Nem todos os algoritmos hash são iguais. Alguns foram quebrados:

“Quebrado” significa: Um atacante pode encontrar duas entradas diferentes que produzem o mesmo hash (colisão). Isso permite forjar documentos, certificados ou assinaturas.

# Verifique você mesmo — calcule hashes em qualquer sistema RHEL:
echo -n "Hello World" | sha256sum
# a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e

echo -n "Hello World" | md5sum
# b10a8db164e0754105b7a99be72e3fe5  ← NÃO confie nisto para segurança!

Usos Reais de Hashes

1.4 Criptografia Simétrica vs Assimétrica

Simétrica: Uma Chave para Tudo

Remetente e destinatário compartilham a mesma chave secreta. Como um cadeado onde ambas as partes têm uma cópia da mesma chave.

Assimétrica: Duas Chaves, Dois Papéis

Cada parte tem um par de chaves: uma chave pública (compartilhe livremente) e uma chave privada (nunca compartilhe).

Por Que Precisamos de Ambas: Criptografia Híbrida

A criptografia assimétrica resolve o problema de distribuição de chaves, mas é lenta demais para dados em massa. A solução: usar assimétrica para trocar uma chave simétrica, depois usar simétrica para os dados.

Isto é exatamente o que acontece em cada conexão HTTPS.

1.5 Entendendo a Troca de Chaves: A Analogia da Mistura de Cores

Antes de mergulhar no handshake TLS/RSA real, vamos construir uma intuição com uma analogia visual. Isto explica a troca de chaves Diffie-Hellman, o mecanismo usado no TLS moderno para estabelecer um segredo compartilhado.

O Problema

Alice e Bob querem concordar em uma cor secreta compartilhada que Eve (a bisbilhoteira) não consiga descobrir, mesmo que Eve possa ver tudo que eles enviam um ao outro.

Por Que Eve Não Consegue Trapacear

Misturar tinta é fácil de fazer mas impossível de reverter. Não se consegue separar tinta misturada de volta em seus componentes. Em matemática, isto é análogo a:

• Fácil: Multiplicar dois primos grandes → obter um produto (misturar)
• Difícil: Fatorar um produto grande → encontrar os primos (separar)

Esta é a função unidirecional que faz a criptografia funcionar.

De Cores para Números

1.6 O Handshake TLS: Como uma Conexão Segura Realmente Funciona

Agora vamos ver o que realmente acontece quando seu navegador se conecta a https://banco.com. Isto combina tudo que aprendemos: hashes, criptografia assimétrica, criptografia simétrica, certificados e troca de chaves.

Passo a Passo Detalhado

Passos 1-2 (Hello): Cliente e servidor trocam capacidades e números aleatórios. Esses números aleatórios adicionam frescor — garantem que cada sessão é única, mesmo entre as mesmas partes.

Passo 3 (Certificate): O servidor prova sua identidade enviando seu certificado X.509 contendo sua chave pública.

Passo 4 (Verificação): Este é o passo crítico de confiança. O cliente percorre a cadeia de confiança.

Cada assinatura é verificada usando a chave pública do emissor. Se qualquer elo se quebrar, o handshake falha.

Passo 5 (Troca de Chaves): O cliente gera 48 bytes aleatórios (PreMasterSecret), cifra com a chave pública RSA do servidor e envia. Apenas a chave privada do servidor pode decifrar — esta é a mágica assimétrica.

Passo 6 (Derivação de Chaves): Ambos os lados calculam independentemente as mesmas chaves de sessão usando uma Função Pseudo-Aleatória (PRF). É aqui que transitamos de assimétrica lenta para simétrica rápida.

Passos 7-9 (Comunicação Criptografada): A partir daqui, tudo é cifrado com AES-256 — milhares de vezes mais rápido que RSA.

TLS 1.3 Moderno: Mais Simples e Rápido

O TLS 1.3 simplificou o handshake removendo a troca de chaves RSA (sigilo futuro agora é obrigatório) e reduzindo viagens de ida e volta:

1.7 Estrutura PKI: A Arquitetura de Confiança

Infraestrutura de Chaves Públicas (PKI) é o sistema que gerencia certificados digitais e chaves públicas. Ela responde à pergunta: “Como sei que esta chave pública realmente pertence a banco.com?”

Por Que uma Cadeia?

CAs Raiz são extremamente valiosas — se comprometidas, cada certificado que já assinaram torna-se não confiável. Por isso CAs Raiz são:

• Armazenadas em módulos de segurança de hardware (HSMs) offline, isolados da rede
• Usadas apenas para assinar certificados de CAs Intermediárias
• Válidas por 20-30 anos

CAs Intermediárias fazem o trabalho diário de emitir certificados. Se comprometidas:

• Apenas os certificados daquela Intermediária são afetados
• A Raiz pode revogar a Intermediária e criar uma nova
• O dano é contido

Revogação: O Que Acontece Quando a Confiança Quebra

Quando uma chave privada é comprometida ou um certificado não deve mais ser confiável:

1.8 Juntando Tudo: Um Exemplo Completo

Vamos rastrear uma conexão HTTPS completa do início ao fim, vendo cada conceito em ação:

1.9 Conclusões Principais

Antes de prosseguir para o gerenciamento de certificados específico do RHEL, certifique-se de entender:

Navegação do Capítulo

Capítulo 2: Introdução aos Certificados no RHEL

Bem-vindo! Este tutorial levará você de não saber nada sobre certificados digitais a resolver problemas de certificados com confiança em sistemas Red Hat Enterprise Linux.

2.1 Por Que Este Tutorial?

Você é um administrador RHEL. Um dia, algo quebra:

• Apache se recusa a iniciar: SSL_CTX_use_certificate:ca md too weak
• Conexões LDAP falham: TLS: hostname does not match CN
• certmonger mostra: CA_UNREACHABLE
• curl retorna: SSL certificate problem: unable to get local issuer certificate

Parece familiar? Estes são problemas de certificados, e estão em todos os lugares em sistemas Linux modernos.

Este tutorial ensina você a:

• ✅ Entender o que são certificados (perspectiva RHEL)
• ✅ Configurar certificados para serviços comuns RHEL
• ✅ Resolver problemas de certificados (objetivo principal!)
• ✅ Automatizar ciclo de vida de certificados com ferramentas RHEL
• ✅ Lidar com diferenças de versões RHEL (7, 8, 9, 10)
• ✅ Passar auditorias (FIPS, STIG, conformidade)

2.2 Para Quem é Este Tutorial?

Público Principal:

• Administradores e engenheiros RHEL
• Engenheiros de suporte resolvendo problemas de certificados
• Qualquer pessoa gerenciando sistemas RHEL com HTTPS, LDAPS ou TLS

Pré-requisitos:

• Conhecimento básico de linha de comando Linux
• Acesso a sistemas RHEL (7, 8, 9 ou 10)
• Não é necessário conhecimento prévio de certificados!

2.3 O Que São Certificados? (Em 60 Segundos)

Imagine que você visita https://example.com. Como seu navegador sabe que está realmente falando com example.com e não com um impostor?

Resposta: Certificados digitais.

Um certificado é como uma carteira de identidade digital que:

1. Prova identidade (“Eu sou example.com”)
2. Habilita criptografia (comunicação segura)
3. É assinado por autoridade confiável (como uma CA)

Em Sistemas RHEL

Certificados são usados em todos os lugares:

• Servidores web (Apache, NGINX) → HTTPS
• Serviços de diretório (OpenLDAP, FreeIPA) → LDAPS
• Servidores de email (Postfix, Dovecot) → SMTPS/IMAPS
• Bancos de dados (PostgreSQL, MySQL) → Conexões TLS
• APIs e serviços (REST, microserviços) → mTLS
• Túneis VPN → Conexões seguras
• Registros de contêiner → Imagens seguras

Resumo: Se está em rede e é seguro no RHEL, provavelmente usa certificados.

2.4 Sua Primeira Inspeção de Certificado

Vamos ser práticos imediatamente. SSH em qualquer sistema RHEL e execute:

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

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

Você verá uma saída 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

O que você está vendo:

• Issuer: Quem assinou este certificado
• Subject: A quem este certificado pertence
• Validity: Quando é válido (expira 15 de março de 2025)
• Signature Algorithm: Como está protegido (SHA-256 com RSA)

🎉 Parabéns! Você acabou de inspecionar seu primeiro certificado.

2.5 Como Funcionam os Certificados (Contexto RHEL)

Os Três Componentes Chave

1. Certificado (.crt, .pem)

   • Informação pública: “Eu sou server.example.com”
   • Contém a chave pública
   • Armazenado em /etc/pki/tls/certs/ no RHEL

2. Chave Privada (.key, .pem)

   • Segredo! Nunca compartilhe isso
   • Usado para provar que você possui o certificado
   • Armazenado em /etc/pki/tls/private/ no RHEL (modo 600!)

3. Autoridade Certificadora (CA)

   • Emite e assina certificados
   • Pode ser pública (Let’s Encrypt, DigiCert)
   • Ou interna (FreeIPA, CA corporativa)
   • CAs confiáveis armazenadas em /etc/pki/ca-trust/ no RHEL

A Cadeia de Confiança

CA Raiz (confiável pelo sistema RHEL)
  └─ CA Intermediária
      └─ Certificado do Servidor (seu servidor web)

Quando alguém se conecta ao seu servidor RHEL:

1. Servidor envia seu certificado
2. Cliente verifica cadeia de assinatura até CA raiz confiável
3. Se cadeia é válida → conexão prossegue
4. Se cadeia quebra → erro (e você recebe a chamada de suporte!)

2.6 Arquitetura de Certificados do RHEL

Diretórios Chave

/etc/pki/
├── ca-trust/
│   ├── source/anchors/      ← Coloque CAs personalizadas aqui
│   └── extracted/           ← Repositório de confiança do sistema
│       ├── pem/             ← CAs em formato PEM
│       ├── openssl/         ← Confiança OpenSSL
│       └── java/            ← Confiança Java (cacerts)
├── tls/
│   ├── certs/               ← Certificados de servidor
│   ├── private/             ← Chaves privadas (modo 700!)
│   └── cert.pem             ← Link simbólico de certificado padrão
└── nssdb/                   ← Base de dados NSS (Firefox, etc.)

Ferramentas Chave

# OpenSSL - Canivete suíço de certificados
openssl version  # Verificar sua versão

# Ferramentas NSS - Para bases de dados NSS
certutil -L -d /etc/pki/nssdb

# Gestão de Confiança - Adicionar/remover CAs
update-ca-trust  # Atualizador de repositório de confiança do RHEL

# Gerenciador de Certificados - Renovação automática (RHEL 7+)
getcert list  # Mostrar certificados rastreados

# Crypto-Policies - Segurança em todo o sistema (RHEL 8+)
update-crypto-policies --show  # Verificar política atual

2.7 Um Dia na Vida: Cenários de Certificados

Cenário 1: Adicionar uma CA Personalizada

# Você tem uma CA corporativa que assinou seus servidores internos
sudo cp corporate-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

# Agora RHEL confia em certificados assinados por sua CA corporativa!

Cenário 2: Configurar Apache HTTPS

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

# Gerar uma chave privada
sudo openssl genpkey -algorithm RSA -out /etc/pki/tls/private/server.key \
  -pkeyopt rsa_keygen_bits:2048

# Gerar uma solicitação de assinatura 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 para CA, obter certificado de volta, instalá-lo
sudo cp server.crt /etc/pki/tls/certs/

# Configurar Apache, reiniciar
sudo systemctl restart httpd

Cenário 3: Resolver um Certificado Expirado

# Serviço falha com: "certificate has expired"
# Verificar expiração do certificado
sudo openssl x509 -in /etc/pki/tls/certs/server.crt -noout -dates

# Saída mostra:
# notAfter=Jan 15 23:59:59 2024 GMT  ← Ops, expirado!

# Renovar certificado, substituir arquivo, reiniciar serviço

2.8 Diferenças de Versão RHEL (Prévia)

A gestão de certificados evoluiu significativamente entre versões RHEL:

Não se preocupe! O Capítulo 8 cobre essas diferenças de versão em detalhes.

2.9 Problemas Comuns de Certificados (Prévia)

Você aprenderá a resolver:

Problemas de Configuração:

• Desajuste de certificado/chave
• Permissões de arquivo incorretas
• Caminhos incorretos em arquivos de configuração

Problemas de Confiança:

• Certificados autoassinados rejeitados
• Erros de CA desconhecida
• Falhas de validação de cadeia

Problemas de Expiração:

• Certificados expirados
• Problemas de desvio de relógio
• Falhas de renovação

Problemas de Versão:

• Desajustes de versão TLS
• Problemas de suite de cifra
• Conflitos de crypto-policy (RHEL 8+)
• Compatibilidade OpenSSL 3.x (RHEL 9+)

Específicos de Serviço:

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

2.10 Visão Geral do Caminho de Aprendizagem

Este tutorial está organizado para administradores RHEL:

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

Comece aqui. Aprenda básicos de certificados em contexto RHEL.

Parte 2: Específico por Versão (Capítulos 8-13)

Mergulho profundo nas diferenças RHEL 7, 8, 9, 10.

Parte 3: Serviços (Capítulos 14-21)

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

Parte 4: Automatização (Capítulos 22-26)

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

Parte 5: Solução de Problemas (Capítulos 27-33) ⭐

É aqui que você se torna um especialista! Solução sistemática de problemas, erros comuns, procedimentos de emergência.

Parte 6: Migração (Capítulos 34-37)

Atualizações de versão RHEL e migração de certificados.

Parte 7: Segurança (Capítulos 38-41)

Modo FIPS, conformidade, fortalecimento, auditoria.

Apêndices

Tópicos avançados opcionais (Kubernetes, Vault, Zero Trust, etc.)

2.11 Como Usar Este Tutorial

Para Novos Usuários

📖 Leia os capítulos em ordem. Cada um se baseia no conhecimento anterior.

Para Usuários Experientes

🎯 Pule para solução de problemas (Parte 5) ou serviços específicos (Parte 3).

Para Engenheiros de Suporte

🚨 Comece com Capítulo 27 (Metodologia de Solução de Problemas de Certificados RHEL), depois mergulhe em detalhes.

Labs Práticos

Cada capítulo inclui exemplos práticos. Você precisará:

• Um sistema RHEL (VM ou contêiner serve)
• Acesso root ou sudo
• Conectividade à internet (para instalações de pacotes)

2.12 Conceitos Chave a Dominar

Ao final deste tutorial, você entenderá:

• ✅ O que são certificados e por que RHEL os usa
• ✅ Como funciona a confiança em sistemas RHEL
• ✅ Onde vivem os certificados (/etc/pki/)
• ✅ Quais ferramentas usar (openssl, certutil, certmonger)
• ✅ Diferenças de versão (RHEL 7 vs 8 vs 9 vs 10)
• ✅ Como resolver problemas de qualquer certificado
• ✅ Como automatizar o ciclo de vida de certificados
• ✅ Como proteger sistemas (FIPS, conformidade)

2.13 Impacto no Mundo Real

Problemas de certificados causam:

• ❌ Interrupções de serviço (certificados expirados)
• ❌ Vulnerabilidades de segurança (cifras fracas)
• ❌ Migrações falhadas (atualizações RHEL)
• ❌ Falhas de conformidade (rejeições de auditoria)
• ❌ Perda de produtividade (tempo de solução de problemas)

Após este tutorial:

• ✅ Prevenir problemas antes que aconteçam
• ✅ Resolver problemas em minutos, não horas
• ✅ Automatizar gestão de certificados
• ✅ Passar auditorias de segurança
• ✅ Migrar versões RHEL com confiança

2.14 Seu Primeiro Exercício

Vamos verificar que seu sistema RHEL está pronto:

# Verificar versão RHEL
cat /etc/redhat-release

# Verificar OpenSSL
openssl version

# Verificar se certmonger está instalado
rpm -q certmonger

# Verificar se você pode usar sudo
sudo whoami

# Verificar conectividade à internet (para instalações de pacotes)
ping -c 3 access.redhat.com

# Listar CAs confiáveis atuais (amostra)
trust list | head -20

✅ Se todos os comandos funcionam, você está pronto para prosseguir!

2.15 Vamos Começar!

Agora você entende:

• O que são certificados
• Por que importam no RHEL
• Onde vivem no sistema de arquivos
• Quais ferramentas você usará
• O que você aprenderá neste tutorial

Pronto para mergulhar mais fundo?

Referência Rápida

┌─────────────────────────────────────────────────────────────────┐
│ INÍCIO RÁPIDO DE CERTIFICADO (RHEL)                             │
├─────────────────────────────────────────────────────────────────┤
│ Ver cert:           openssl x509 -in cert.crt -noout -text      │
│ Ver expiração:      openssl x509 -in cert.crt -noout -dates     │
│ Adicionar 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+)    │
└─────────────────────────────────────────────────────────────────┘

Localização cert:  /etc/pki/tls/certs/
Localização key:   /etc/pki/tls/private/  (modo 600!)
Confiança CA:      /etc/pki/ca-trust/

🧪 Laboratório Prático

Lab 01: Configuração do Ambiente

Valide seu ambiente RHEL e instale ferramentas essenciais de gerenciamento de certificados

• 📁 Localização: labs/pt_BR/01-environment-setup/
• ⏱️ Tempo: 15-20 minutos
• 🎯 Nível: Iniciante

Navegação do Capítulo

Capítulo 3: Visão Geral das Ferramentas de Certificados do RHEL

Objetivo de Aprendizagem: Familiarize-se com as ferramentas essenciais para gerenciar certificados no RHEL para que você saiba qual ferramenta usar para cada tarefa.

3.1 Sua Caixa de Ferramentas de Certificados

Ao trabalhar com certificados no RHEL, você usará estas ferramentas principais:

3.2 OpenSSL - O Canivete Suíço

Disponível: Todas as versões RHEL Pacote: openssl

Diferenças de Versão

# Verificar sua versão
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 Comuns

#============================================#
# INSPECIONAR CERTIFICADOS
#============================================#

# Ver detalhes do certificado
openssl x509 -in cert.crt -noout -text

# Verificar expiração
openssl x509 -in cert.crt -noout -dates
openssl x509 -in cert.crt -noout -checkend 86400  # Verificar se expira em 24h

# Ver assunto do certificado
openssl x509 -in cert.crt -noout -subject -issuer


#============================================#
# GERAR CHAVES
#============================================#

# Estilo RHEL 7 (ainda funciona em todas as versões)
openssl genrsa -out server.key 2048

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

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


#============================================#
# CRIAR CSR (Solicitação de Assinatura 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 com 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"


#============================================#
# TESTAR CONEXÕES
#============================================#

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

# Testar versão TLS específica
openssl s_client -connect server.example.com:443 -tls1_2
openssl s_client -connect server.example.com:443 -tls1_3

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

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

Diferenças Específicas por Versão

RHEL 7 (OpenSSL 1.0.2k):

• ✅ Estável e bem testado
• ❌ Sem suporte TLS 1.3
• ❌ Sintaxe de comando mais antiga

RHEL 8 (OpenSSL 1.1.1k):

• ✅ Suporte TLS 1.3
• ✅ Sintaxe de comando moderna
• ✅ Melhores padrões

RHEL 9/10 (OpenSSL 3.5.5):

• ✅ Arquitetura de provedores
• ✅ Suporte FIPS aprimorado
• ⚠️ Mudanças na API (afeta apps personalizadas)
• ⚠️ Algoritmos legados requerem -provider legacy

3.3 certutil - Ferramenta de Base de Dados NSS

Disponível: Todas as versões RHEL Pacote: nss-tools

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

Usos Comuns

#============================================#
# GERENCIAR BASE DE DADOS NSS
#============================================#

# Criar nova base de dados
certutil -N -d /etc/pki/nssdb

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

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

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

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

Quando Usar certutil

• Gerenciar certificados Firefox/Thunderbird
• Trabalhar com aplicações que usam NSS (muitos serviços Red Hat)
• Quando você vê arquivos .db em /etc/pki/nssdb/

3.4 update-ca-trust - Gerenciamento de Repositório de Confiança

Disponível: Todas as versões RHEL Pacote: ca-certificates (instalado por padrão)

Gerencia quais Autoridades Certificadoras (CAs) seu sistema confia.

Como Funciona

Suas 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 OpenSSL)
  └── java/cacerts                (Aplicações Java)

Usos Comuns

#============================================#
# ADICIONAR CA PERSONALIZADA
#============================================#

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

# Passo 2: Atualizar repositório de confiança
sudo update-ca-trust extract

# É isso! Agora todas as aplicações confiam nesta CA


#============================================#
# REMOVER/BLOQUEAR CA (RHEL 8+)
#============================================#

# Bloquear uma CA comprometida
sudo cp compromised-ca.crt /etc/pki/ca-trust/source/blacklist/
sudo update-ca-trust extract


#============================================#
# VERIFICAR CONFIANÇA
#============================================#

# Verificar se certificado é confiável
openssl verify /path/to/cert.crt

# Listar todas as CAs confiáveis
trust list | grep "certificate-authority"

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

Diretórios Chave

/etc/pki/ca-trust/
├── source/
│   ├── anchors/          ← Adicione suas CAs confiáveis aqui
│   └── blacklist/        ← CAs na lista negra (RHEL 8+)
└── extracted/
    ├── pem/              ← Usado pela maioria das apps
    ├── openssl/          ← Específico OpenSSL
    └── java/             ← Aplicações Java

3.5 certmonger - Renovação Automática de Certificados

Disponível: Todas as versões RHEL Pacote: certmonger

A ferramenta “configure e esqueça” para certificados.

O Que Faz

certmonger:

• Rastreia datas de expiração de certificados
• Renova automaticamente antes de expirar
• Funciona com múltiplas CAs (IPA, Let’s Encrypt, externa)
• Executa comandos pós-renovação (ex: reiniciar serviços)

Fluxo de Trabalho Básico

#============================================#
# INSTALAÇÃO
#============================================#

sudo dnf install certmonger
sudo systemctl enable --now certmonger


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

# De 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

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


#============================================#
# MONITORAR CERTIFICADOS
#============================================#

# Listar todos os certificados rastreados
sudo getcert list

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

# Observar renovação
sudo journalctl -u certmonger -f

Recursos Chave por Versão

RHEL 7:

• Rastreamento e renovação básicos
• Integração IPA
• Configuração manual

RHEL 8:

• Integração IPA aprimorada
• Melhor relatório de erros
• Comandos pós-salvamento

RHEL 9:

• Suporte ACME (Let’s Encrypt!)
• Monitoramento aprimorado
• Melhor relatório de status

# RHEL 9 - Integração 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 - Segurança em Todo o Sistema (RHEL 8+)

Disponível: Apenas RHEL 8, 9, 10 Pacote: crypto-policies (instalado por padrão)

MUDANÇA DE JOGO: Controle versões TLS, cifras e tamanhos de chave em todo o sistema!

A Grande Ideia

Em vez de configurar cada aplicação individualmente:

❌ FORMA ANTIGA (RHEL 7):
- Configurar cifras SSL do Apache
- Configurar cifras SSL do NGINX
- Configurar ajustes TLS do Postfix
- Configurar ajustes TLS do OpenLDAP
- Configurar cada aplicação...

✅ FORMA NOVA (RHEL 8+):
- Definir UMA política do sistema
- Todas as aplicações seguem automaticamente!

Políticas Disponíveis

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

# Políticas:
# DEFAULT  - Segurança equilibrada (TLS 1.2+, RSA 2048+)
# LEGACY   - Modo de compatibilidade (permite TLS 1.0/1.1)
# FUTURE   - Segurança mais rigorosa (TLS 1.2+, RSA 3072+)
# FIPS     - Modo de conformidade federal

Comparação de Políticas

Usos Comuns

#============================================#
# MUDAR POLÍTICA
#============================================#

# Definir política FUTURE (mais rigorosa)
sudo update-crypto-policies --set FUTURE
# Reiniciar ou reiniciar serviços

# Usar temporariamente LEGACY (para sistemas antigos)
sudo update-crypto-policies --set LEGACY
# Nota: LEGACY deve ser temporário!


#============================================#
# 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
#============================================#

# Se serviço falha após mudança de política:
# 1. Verificar política atual
update-crypto-policies --show

# 2. Verificar configuração de aplicação
cat /etc/crypto-policies/back-ends/opensslcnf.config

# 3. Testar com LEGACY temporariamente
sudo update-crypto-policies --set LEGACY
sudo systemctl restart <service>

O Que crypto-policies Controla

Configura automaticamente:

• OpenSSL
• GnuTLS
• NSS
• OpenJDK/Java
• BIND
• Kerberos
• OpenSSH
• E mais!

Resumo: Mude uma configuração, atualize a segurança de todo o sistema. Brilhante!

3.7 Guia de Seleção de Ferramenta

“Qual ferramenta devo usar?”

┌─────────────────────────────────────────────────────────────┐
│ ÁRVORE DE DECISÃO DE FERRAMENTA DE CERTIFICADO              │
└─────────────────────────────────────────────────────────────┘

Eu preciso...
│
├─ Inspecionar um certificado
│  └─ Usar: openssl x509 -in cert.crt -noout -text
│
├─ Gerar uma chave/CSR
│  └─ Usar: openssl genpkey / openssl req
│
├─ Testar uma conexão TLS
│  └─ Usar: openssl s_client -connect host:port
│
├─ Adicionar uma CA confiável em todo o sistema
│  └─ Usar: copiar para /etc/pki/ca-trust/source/anchors/
│           depois: update-ca-trust
│
├─ Renovar certificados automaticamente
│  └─ Usar: certmonger (getcert/ipa-getcert)
│
├─ Mudar política TLS do sistema (RHEL 8+)
│  └─ Usar: update-crypto-policies --set <POLICY>
│
├─ Trabalhar com bases de dados Firefox/NSS
│  └─ Usar: certutil
│
└─ Resolver problemas de certificados
   └─ Usar: Metodologia do Capítulo 27!

3.8 Matriz de Disponibilidade de Ferramentas

3.9 Verificação de Instalação

Verifique que você tem as ferramentas essenciais:

#============================================#
# VERIFICAR FERRAMENTAS INSTALADAS
#============================================#

# OpenSSL (deve estar instalado por padrão)
openssl version

# Ferramentas NSS
rpm -q nss-tools || echo "Instalar com: sudo dnf install nss-tools"

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

# Verificar crypto-policies (apenas RHEL 8+)
which update-crypto-policies &>/dev/null && \
  echo "Crypto-policies disponível: $(update-crypto-policies --show)" || \
  echo "Crypto-policies não disponível (RHEL 7 ou anterior)"

3.10 Comandos de Referência Rápida

# === OpenSSL ===
openssl version                          # Verificar versão
openssl x509 -in cert.crt -noout -text   # Inspecionar certificado
openssl s_client -connect host:443       # Testar HTTPS

# === Repositório de Confiança ===
sudo cp ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust                     # Adicionar CA confiável

# === 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 atual
sudo update-crypto-policies --set <POL>  # Mudar política

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

3.11 O Que Vem a Seguir?

Agora que você conhece as ferramentas, você aprenderá:

• Capítulo 4: Conceitos básicos de criptografia
• Capítulo 5: Entendendo certificados X.509
• Capítulo 6: Mergulho profundo em repositório de confiança RHEL
• Capítulo 22: Domínio de certmonger (detalhado)
• Capítulo 23: Mergulho profundo em Crypto-policies (detalhado)

Cartão de Referência Rápida

┌────────────────────────────────────────────────────────────┐
│ FOLHA DE DICAS DE FERRAMENTAS DE CERTIFICADOS RHEL         │
├────────────────────────────────────────────────────────────┤
│ Inspecionar:   openssl x509 -in cert.crt -noout -text      │
│ Testar:        openssl s_client -connect host:443          │
│ Adicionar 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               │
└────────────────────────────────────────────────────────────┘

Navegação do Capítulo

Capítulo 4: Criptografia Básica para Administradores RHEL

Foco Prático: Aprenda os conceitos de criptografia necessários para gerenciar certificados no RHEL - não é necessário um doutorado!

4.1 Simétrica vs Assimétrica

Criptografia simétrica (ex. AES) depende de um único segredo compartilhado. Em contraste, criptografia assimétrica fornece duas chaves complementares:

• Chave pública — compartilhe livremente, usada para criptografia ou verificação de assinatura.
• Chave privada — mantenha secreta, usada para descriptografia ou assinatura.

4.2 RSA em Poucas Palavras

1. Selecione dois números primos grandes p e q.
2. Calcule o módulo n = p × q.
3. Derive o expoente público e e o expoente privado d tal que e × d ≡ 1 (mod φ(n)).
4. O par (n, e) é público; (n, d) é privado.

A força deriva da dificuldade de fatorar n.

4.3 Criptografia de Curva Elíptica (ECC)

ECC oferece segurança comparável com tamanhos de chave muito menores ao operar sobre pontos em curvas elípticas. Curvas populares incluem secp256r1 (P-256) e Curve25519.

4.4 Lab de Geração de Chaves (OpenSSL)

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

# Extrair chave pública
openssl pkey -in rsa.key.pem -pubout -out rsa.pub.pem

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

Reutilizaremos essas chaves em capítulos posteriores para criar certificados.

4.5 Criptografia Híbrida

No TLS, uma chave de sessão simétrica é trocada usando criptografia assimétrica (RSA ou ECDHE). Isso fornece o melhor dos dois mundos: eficiência e troca segura de chaves.

4.6 Considerações Específicas do RHEL

Geração de Chaves no RHEL por Versão

RHEL 7 (OpenSSL 1.0.2k):

# Estilo antigo (ainda funciona em todas as versões)
openssl genrsa -out server.key 2048

# Extrair chave 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

# Extrair chave pública
openssl pkey -in server.key -pubout -out server.pub

Tamanhos Mínimos de Chave por Versão RHEL

Recomendação: Sempre use RSA 2048+ ou ECC P-256+ para compatibilidade!

Testes no RHEL

# Gerar par de chaves de teste (RHEL 8+)
openssl genpkey -algorithm RSA -out test.key -pkeyopt rsa_keygen_bits:2048

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

# Criar dados de teste
echo "Olá RHEL" > message.txt

# Assinar com chave privada
openssl dgst -sha256 -sign test.key -out message.sig message.txt

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

Referência Rápida

┌─────────────────────────────────────────────────────────────────┐
│ CRIPTOGRAFIA PARA ADMINISTRADORES RHEL                          │
├─────────────────────────────────────────────────────────────────┤
│ Assimétrica:   Chave pública (compartilhar) + Privada (secreta) │
│ Algoritmos:    RSA, ECC (Curva Elíptica)                        │
│                                                                 │
│ Tamanhos RSA:  2048 bits (mínimo no 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                             │
│ Segurança:     Chave privada DEVE ser protegida (chmod 600)     │
└─────────────────────────────────────────────────────────────────┘

🧪 Laboratório Prático

Lab 02: Geração de Chaves

Gere pares de chaves RSA e ECC, extraia chaves públicas e compare algoritmos

• 📁 Localização: labs/pt_BR/02-key-generation/
• ⏱️ Tempo: 20-25 minutos
• 🎯 Nível: Iniciante

Navegação do Capítulo

Capítulo 5: Certificados X.509 no RHEL

Formato Padrão: X.509 é o padrão de certificado usado em todos os lugares no RHEL. Aprenda sua estrutura e como trabalhar com ele em sistemas Red Hat.

5.1 Origens do Padrão

X.509 emergiu do projeto de diretório X.500 (ITU-T, 1988) para definir um certificado de identidade padrão—um documento que vincula uma chave pública a um nome de assunto, assinado por uma autoridade confiável.

5.2 Anatomia do Certificado

5.3 Extensões Comuns

• Subject Alternative Name (SAN) — Hosts/IPs vinculados ao cert.
• Key Usage / Extended Key Usage — Operações permitidas (servidor TLS, assinatura de código…).
• Basic Constraints — Indica se cert pode assinar outros (CA:TRUE).

5.4 Visualizar um Certificado

openssl x509 -in server.crt -noout -text

Observe que cada seção corresponde à tabela acima.

5.5 Codificações PEM vs DER

• PEM — Base64 + cabeçalhos -----BEGIN CERTIFICATE----- (mais comum no RHEL).
• DER — ASN.1 binário, útil para dispositivos embarcados.

5.6 X.509 em Sistemas RHEL

Localizações de Certificados no RHEL

# Localizações padrão de certificados RHEL
/etc/pki/tls/certs/          # Certificados de servidor (públicos)
/etc/pki/tls/private/        # Chaves privadas (modo 600!)
/etc/pki/ca-trust/           # Certificados CA confiáveis
/etc/pki/nssdb/              # Base de dados NSS (Firefox, etc.)

# Localizações específicas de serviço
/etc/httpd/conf/ssl.crt/     # Apache (alternativa)
/etc/nginx/certs/            # NGINX (personalizado)
/var/lib/pgsql/data/         # PostgreSQL
/etc/openldap/certs/         # OpenLDAP

Visualizar Certificados no RHEL

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

# Verificações rápidas (foco sysadmin RHEL)
openssl x509 -in server.crt -noout -subject             # Para quem é?
openssl x509 -in server.crt -noout -issuer              # Quem assinou?
openssl x509 -in server.crt -noout -dates               # Quando é válido?
openssl x509 -in server.crt -noout -ext subjectAltName  # SANs (crítico!)

# Verificar se expirou
openssl x509 -in server.crt -noout -checkend 0
# Saída 0 = válido, Saída 1 = expirado

Diferenças de Versão RHEL para X.509

Ponto Chave: Navegadores modernos e RHEL 9+ requerem SANs (Subject Alternative Names)!

Criar Certificados X.509 no RHEL

# Fluxo de trabalho completo no RHEL

# Passo 1: Gerar chave privada
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

# Passo 2: Criar CSR (Solicitação de Assinatura 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"

# Passo 3: Autoassinado (apenas para testes!)
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

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

# Passo 5: Instalar no 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

Referência Rápida

┌────────────────────────────────────────────────────────────────────┐
│ CERTIFICADOS X.509 NO RHEL                                         │
├────────────────────────────────────────────────────────────────────┤
│ Padrão:       X.509 v3 (com extensões)                             │
│ Codificação:  PEM (Base64, legível por humanos)                    │
│                                                                    │
│ Ver:          openssl x509 -in cert.crt -noout -text               │
│ Assunto:      openssl x509 -in cert.crt -noout -subject            │
│ Expiração:    openssl x509 -in cert.crt -noout -dates              │
│ SANs:         openssl x509 -in cert.crt -noout -ext subjectAltName │
│                                                                    │
│ Localização:  /etc/pki/tls/certs/ (certificados)                   │
│               /etc/pki/tls/private/ (chaves, modo 600!)            │
│                                                                    │
│ Crítico:      SANs são REQUERIDOS no RHEL 9+                       │
│               Assinatura SHA-256+ requerida no RHEL 8+             │
└────────────────────────────────────────────────────────────────────┘

🧪 Laboratório Prático

Lab 04: Certificados X.509

Crie certificados autoassinados, gere CSRs, inspecione certificados e converta formatos

• 📁 Localização: labs/pt_BR/04-x509-certificates/
• ⏱️ Tempo: 25-30 minutos
• 🎯 Nível: Iniciante

Navegação do Capítulo

Capítulo 6: Mergulho Profundo no Repositório de Confiança RHEL

Arquitetura de Confiança: Entender como o RHEL valida certificados e gerencia CAs confiáveis é essencial para solucionar problemas de certificados. Este capítulo vai além do básico: ele cobre os mecanismos internos do update-ca-trust, como o p11-kit processa fontes de confiança, o que acontece com certificados duplicados e como depurar problemas de confiança com trust list.

6.1 Arquitetura do Repositório de Confiança RHEL

Como o RHEL Valida Certificados

Quando qualquer aplicação no RHEL valida um certificado:

1. Verificar assinatura do certificado usando a chave pública do emissor
2. Encontrar certificado do emissor no repositório de confiança
3. Repetir até alcançar a raiz confiável da CA
4. Verificar se a CA raiz é confiável pelo sistema RHEL

Localização do repositório de confiança: /etc/pki/ca-trust/

O Papel do p11-kit

O repositório de confiança do RHEL não é um arquivo plano que as aplicações leem diretamente. É um sistema gerenciado construído sobre o p11-kit, que fornece um módulo de confiança PKCS#11. Os componentes principais são:

Aplicações como curl, wget, OpenSSL, GnuTLS e NSS consomem os bundles extraídos. Elas nunca leem os diretórios de origem diretamente.

6.2 Estrutura de Diretórios do Repositório de Confiança

RHEL 7/8:

/etc/pki/ca-trust/
├── source/
│   ├── anchors/                   ← Certificados CA confiáveis adicionados pelo admin
│   ├── blacklist/                 ← Certificados desconfiados adicionados pelo admin
│   └── ca-bundle.legacy.crt       ← Bundle legado (apenas para compatibilidade)
├── extracted/
│   ├── pem/
│   │   ├── tls-ca-bundle.pem      ← Para clientes TLS (curl, wget, Python...)
│   │   ├── email-ca-bundle.pem    ← Para validação de email S/MIME
│   │   └── objsign-ca-bundle.pem  ← Para verificação de assinatura de código
│   ├── openssl/
│   │   └── ca-bundle.trust.crt    ← Formato "certificado confiável" do OpenSSL
│   ├── java/
│   │   └── cacerts                ← Keystore JKS do Java
│   └── edk2/
│       └── cacerts.bin            ← Formato de firmware UEFI
└── README

/usr/share/pki/ca-trust-source/
├── anchors/                       ← Âncoras de confiança fornecidas por pacotes (de RPMs)
├── blacklist/                     ← Certificados desconfiados fornecidos por pacotes
└── ca-bundle.trust.p11-kit        ← Bundle de CAs Mozilla fornecido pelo RPM ca-certificates

RHEL 9/10+: O diretório blacklist/ foi renomeado para blocklist/:

/etc/pki/ca-trust/
├── source/
│   ├── anchors/                   ← Certificados CA confiáveis adicionados pelo admin
│   ├── blocklist/                 ← Certificados desconfiados adicionados pelo admin
│   └── ca-bundle.legacy.crt       ← Bundle legado (apenas para compatibilidade)
├── extracted/
│   └── (mesma estrutura acima)
└── README

/usr/share/pki/ca-trust-source/
├── anchors/                       ← Âncoras de confiança fornecidas por pacotes (de RPMs)
├── blocklist/                     ← Certificados desconfiados fornecidos por pacotes
└── ca-bundle.trust.p11-kit        ← Bundle de CAs Mozilla fornecido pelo RPM ca-certificates

Convenção de nomenclatura: Ao longo deste capítulo, blacklist/ refere-se ao nome de diretório do RHEL 7/8 e blocklist/ refere-se ao nome de diretório do RHEL 9/10+. Ambos servem o mesmo propósito. Quando você vir um caminho como source/blacklist/, substitua por source/blocklist/ no RHEL 9+.

Prioridade dos Diretórios de Origem

O pipeline update-ca-trust lê certificados de múltiplos diretórios de origem, processados em uma ordem definida:

Dentro de cada localização:

• anchors/ — Certificados colocados aqui são tratados como CAs confiáveis
• blacklist/ (RHEL 7/8) ou blocklist/ (RHEL 9+) — Certificados colocados aqui são tratados como explicitamente desconfiados

Os caminhos /etc/pki/ sempre sobrescrevem os caminhos /usr/share/pki/. Isso segue a convenção padrão do RHEL: /usr/share/ contém padrões de pacotes, /etc/ contém personalizações do administrador.

6.3 O Que Acontece Quando Você Executa update-ca-trust

O Pipeline de Execução

update-ca-trust é um script shell (inspecione você mesmo: cat /usr/bin/update-ca-trust). Quando você executa sudo update-ca-trust, a seguinte sequência ocorre:

Passo 1: Coletar todas as fontes de confiança

O p11-kit lê cada arquivo de certificado desses diretórios:

/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+

Ele aceita os formatos PEM (.pem, .crt), DER (.der) e objetos de confiança p11-kit (.p11-kit).

Passo 2: Analisar atributos de confiança

Para cada certificado, o p11-kit determina sua disposição de confiança. O formato PEM do arquivo de certificado importa:

• -----BEGIN TRUSTED CERTIFICATE----- (formato “confiável” do OpenSSL) — Contém o certificado mais dados auxiliares de confiança: listas explícitas de OIDs de uso de chave confiáveis e rejeitados. O p11-kit lê esses atributos de confiança/rejeição incorporados diretamente.
• -----BEGIN CERTIFICATE----- (PEM simples) ou DER — Contém apenas o certificado sem metadados de confiança. O p11-kit atribui confiança baseado exclusivamente no diretório onde o arquivo está colocado (anchors/ = confiável, blacklist//blocklist/ = desconfiado).
• Arquivos no formato .p11-kit — Contêm objetos de confiança PKCS#11 com atributos granulares (trusted, x-distrusted, OIDs de propósito). Usado pelo arquivo ca-bundle.trust.p11-kit fornecido com o pacote ca-certificates.

Crítico: Os formatos BEGIN TRUSTED CERTIFICATE e BEGIN CERTIFICATE não são intercambiáveis. Um arquivo BEGIN TRUSTED CERTIFICATE carrega dados auxiliares de confiança — listas explícitas de OIDs de uso confiável e/ou rejeitado. Quando nenhum uso é listado (atributos de confiança vazios), o p11-kit interpreta como “confiável para nada” — efetivamente desconfiado. Se o mesmo certificado também existe como BEGIN CERTIFICATE simples (que implica confiança para todos os propósitos), o p11-kit detecta afirmações de confiança contraditórias e marca o certificado como desconfiado. Este conflito ocorre em dois casos: (1) o BEGIN TRUSTED CERTIFICATE tem usos rejeitados explícitos, ou (2) tem atributos de confiança vazios (nenhum uso confiável, nenhum uso rejeitado). Veja a Seção 6.6 para detalhes.

Passo 3: Mesclar e resolver conflitos

Quando o mesmo certificado (correspondido pelo seu conteúdo codificado em DER) aparece em múltiplas localizações de origem, o p11-kit aplica regras de mesclagem:

1. Desconfiança prevalece sobre confiança. Se um certificado aparece tanto em anchors/ quanto em blacklist//blocklist/, ele é desconfiado.

2. Admin sobrescreve pacotes. Atributos de confiança definidos em /etc/pki/ca-trust/source/ sobrescrevem aqueles de /usr/share/pki/ca-trust-source/.

3. Atributos explícitos sobrescrevem padrões. Um arquivo .p11-kit com restrições de propósito específicas sobrescreve a confiança genérica dada a um PEM simples em anchors/.

4. Formatos de confiança conflitantes causam desconfiança. Se o mesmo certificado (impressão digital idêntica) aparece como BEGIN TRUSTED CERTIFICATE (ou .p11-kit) e como BEGIN CERTIFICATE, a desconfiança ocorre em dois casos:

   • O BEGIN TRUSTED CERTIFICATE tem usos rejeitados explícitos — a rejeição contradiz a confiança implícita total do PEM simples.
   • O BEGIN TRUSTED CERTIFICATE tem atributos de confiança vazios (nenhum uso confiável, nenhum uso rejeitado) — o p11-kit interpreta “nenhum uso listado” como “confiável para nada”, o que contradiz o implícito “confiável para todos os propósitos” do PEM simples.

   Em ambos os casos, o p11-kit marca o certificado como desconfiado.

Esta é a causa mais comum de desconfiança inesperada. Um administrador copia um arquivo PEM simples em source/anchors/ sem perceber que o mesmo certificado já existe em ca-bundle.trust.p11-kit com atributos de uso rejeitado ou confiança vazia. O resultado: a CA é desconfiada após update-ca-trust, e serviços que dependem dela quebram silenciosamente.

Passo 4: Extrair para bundles específicos de formato

O p11-kit executa comandos de extração para cada formato de saída:

# Bundle PEM para TLS (mais comumente consumido)
p11-kit extract --format=pem-bundle \
    --filter=ca-anchors \
    --overwrite \
    --purpose=server-auth \
    /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

# Bundle PEM para email (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

# Bundle PEM para assinatura 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 confiável" do OpenSSL (inclui atributos de confiança/rejeição)
p11-kit extract --format=openssl-bundle \
    --filter=certificates \
    --overwrite \
    /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt

# Keystore 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

Passo 5: Atualizar symlinks de compatibilidade

O sistema mantém symlinks para que caminhos legados apontem para os bundles 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

Estes são funcionalmente idênticos. O script update-ca-trust aceita extract como subcomando, mas executar update-ca-trust sem argumentos assume a ação extract como padrão. Não há diferença no comportamento.

# Esses dois comandos produzem resultados idênticos:
sudo update-ca-trust
sudo update-ca-trust extract

O subcomando extract existe para explicitude em scripts e documentação. Historicamente, update-ca-trust também suportava os subcomandos enable e disable (para alternar entre o novo repositório de confiança gerenciado pelo p11-kit e a abordagem legada de arquivo plano), mas esses não são mais relevantes em sistemas RHEL modernos onde o gerenciamento pelo p11-kit está sempre ativo.

# Verificar status atual (apenas informativo no RHEL moderno)
update-ca-trust check

Verificando o Que Mudou

Após executar update-ca-trust, você pode verificar o resultado:

# Contar CAs confiáveis no bundle PEM
grep -c '^-----BEGIN CERTIFICATE-----' /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

# Listar todas as CAs confiáveis via p11-kit
trust list --filter=ca-anchors | grep "label:" | wc -l

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

6.4 Adicionando Certificados CA Personalizados

Passo a Passo

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

# Passo 2: Atualizar repositório de confiança
sudo update-ca-trust

# Passo 3: Verificar adição
trust list | grep -i "company"

# Passo 4: Testar
curl https://internal-server.example.com

Funciona de forma idêntica no RHEL 7, 8, 9, 10.

Adicionando com Restrições de Propósito

Se uma CA deve ser confiável apenas para autenticação de servidor TLS (não para assinatura de email ou assinatura de código), use o comando trust em vez da abordagem simples de cópia de arquivo:

# Confiar apenas para autenticação de servidor TLS
sudo trust anchor --store /path/to/company-ca.crt

# Ou com restrição explícita de propósito via formato p11-kit
# Criar um arquivo .p11-kit com confiança restrita:
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

O comando trust anchor --store lida com isso automaticamente e é a abordagem recomendada no RHEL 8+.

6.5 Recursos do Repositório de Confiança por Versão RHEL

Evolução do Gerenciamento de Confiança

Aprimoramento RHEL 8+:

# Gerenciamento avançado de confiança (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 uma 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: O Que Acontece e Como Lidar

Variantes de Formato PEM e Implicações de Confiança

Antes de discutir duplicatas, é essencial entender os três formatos de cabeçalho PEM que o RHEL usa, pois o formato em si carrega semântica de confiança:

Você pode inspecionar os atributos de confiança incorporados em um arquivo BEGIN TRUSTED CERTIFICATE:

# Mostrar os dados auxiliares de confiança
openssl x509 -in cert.crt -noout -text -trustout 2>/dev/null | grep -A 5 "Trusted Uses\|Rejected Uses"

Um arquivo BEGIN TRUSTED CERTIFICATE com “Rejected Uses: TLS Web Server Authentication” e um arquivo BEGIN CERTIFICATE para o mesmo cert (que não carrega informação de rejeição) são contraditórios da perspectiva do p11-kit.

Entendendo Certificados “Duplicados”

Dois certificados podem ser duplicados em diferentes níveis:

A distinção crítica: o p11-kit identifica duplicatas pelo conteúdo do certificado codificado em DER, não por campos de metadados. No entanto, “corresponder” o conteúdo DER é apenas metade da história — o que acontece depois depende inteiramente de se os formatos de encapsulamento de confiança concordam:

• Se os bytes DER brutos do certificado são idênticos e todas as fontes concordam na disposição de confiança → deduplicado, confiável
• Se os bytes DER brutos do certificado são idênticos mas uma fonte tem OIDs de uso rejeitado incorporados e a outra não → afirmações de confiança contraditórias → DESCONFIADO
• Se os bytes DER brutos do certificado são idênticos mas uma fonte tem BEGIN TRUSTED CERTIFICATE com atributos de confiança vazios (nenhum uso confiável, nenhum uso rejeitado) → p11-kit interpreta como “confiável para nada” → contradiz confiança implícita total → DESCONFIADO
• Se os bytes DER brutos do certificado são idênticos e uma fonte tem BEGIN TRUSTED CERTIFICATE com apenas usos confiáveis explícitos (sem usos rejeitados) → certificado é aceito com os propósitos de confiança especificados
• Se os bytes DER brutos do certificado diferem (mesmo por um único byte) → o p11-kit os trata como certificados separados e ambos são incluídos

Cenário: Formatos de Confiança Conflitantes (Mais Perigoso)

Este é o problema de “duplicata” mais comum e mais prejudicial. Acontece silenciosamente quando um administrador copia um certificado em source/anchors/ sem perceber que o mesmo certificado já existe no bundle do sistema com OIDs de uso rejeitado ou atributos de confiança vazios em seus dados de confiança.

Exemplo:

/usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit
  → Contém "My Corp CA" como objeto de confiança p11-kit com atributos de confiança específicos
    INCLUINDO usos rejeitados (ex.: "Rejected Uses: TLS Web Server Authentication")
    OU com atributos de confiança vazios (nenhum uso confiável, nenhum uso rejeitado listado)

/etc/pki/ca-trust/source/anchors/my-corp-ca.crt
  → Mesmo "My Corp CA" como PEM simples (-----BEGIN CERTIFICATE-----)
    (sem atributos de confiança — depende do posicionamento no diretório para confiança implícita)

Resultado: O mesmo conteúdo DER do certificado agora tem descrições de confiança contraditórias. O objeto de confiança p11-kit ou rejeita explicitamente certos usos, ou não lista nenhum uso (o que o p11-kit interpreta como “confiável para nada”). O PEM simples não carrega metadados de confiança, implicando confiança para todos os propósitos. O p11-kit não consegue reconciliar estas contradições, e marca o certificado como desconfiado. Após executar update-ca-trust:

• O certificado desaparece de tls-ca-bundle.pem
• trust list o mostra com trust: distrusted
• Todos os serviços que dependem desta CA começam a falhar com certificate verify failed

O mesmo problema ocorre com o formato BEGIN TRUSTED CERTIFICATE do OpenSSL quando contém usos rejeitados OU confiança vazia:

/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
  → Contém o certificado como -----BEGIN TRUSTED CERTIFICATE-----
    (com OIDs de "Rejected Uses" incorporados, OU sem nenhum uso confiável/rejeitado listado)

/etc/pki/ca-trust/source/anchors/certificate.crt
  → Mesmo certificado como -----BEGIN CERTIFICATE-----
    (sem dados de confiança incorporados — sem informação de rejeição)

Resultado: Mesmo resultado — a rejeição ou confiança vazia em uma fonte contradiz a confiança implícita na outra, certificado marcado como desconfiado.

Informação chave: Em um BEGIN TRUSTED CERTIFICATE, “nenhum uso confiável/rejeitado listado” NÃO significa “confiável para todos os propósitos.” Significa “confiável para nada.” Esta é a distinção crítica em relação a um BEGIN CERTIFICATE simples em anchors/, onde o posicionamento no diretório concede confiança implícita total. Para depurar, procure certificados duplicados em /etc/pki/ca-trust/source/ e /usr/share/pki/ca-trust-source/ e verifique se existe algum BEGIN TRUSTED CERTIFICATE com nenhum Reject ou confiança vazia que possa conflitar com uma cópia PEM simples.

Como corrigir:

# Opção 1: Remover o PEM simples duplicado de anchors/
sudo rm /etc/pki/ca-trust/source/anchors/my-corp-ca.crt
sudo update-ca-trust

# Opção 2: Se você PRECISA do cert em anchors/, converta-o para o
# formato confiável correspondente aos atributos de confiança 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 a correção
trust list --filter=ca-anchors | grep -A 3 "My Corp CA"

Cenário: Desconfiança Explícita

/usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit
  → Contém "Legacy Corp CA" com confiança total

/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+
  → Mesmo "Legacy Corp CA" como PEM simples, colocado no diretório de desconfiança

Resultado: A desconfiança prevalece por design. O certificado é excluído de tls-ca-bundle.pem e marcado como desconfiado no bundle do OpenSSL. Este é o comportamento esperado quando um admin intencionalmente desconfia de uma CA.

Cenário: Certificados Quase Idênticos (DER Diferente)

Um problema mais sutil ocorre quando dois certificados parecem iguais, mas não são idênticos byte a byte:

• Um certificado CA foi baixado de duas fontes diferentes com quebra de linha PEM ligeiramente diferente
• Um certificado CA foi recodificado (PEM → DER → PEM) e ganhou metadados de cabeçalho diferentes
• Uma CA foi reemitida com o mesmo Subject DN, mas um novo par de chaves e número serial

Nesses casos, o p11-kit os trata como certificados distintos, e ambos acabam nos bundles extraídos. Isso pode causar:

• Saída confusa de trust list com aparentes duplicatas
• Tamanho de bundle aumentado (questão cosmética)
• Confusão na construção de cadeia se uma cópia é desconfiada e a outra é confiável, mas elas têm conteúdo DER diferente

Como Detectar Certificados Duplicados

Método 1: Comparação de impressão digital + formato

Extraia impressões digitais de todos os certificados de origem e verifique duplicatas, incluindo qual formato cada arquivo usa:

# Verificar todos os diretórios de origem para impressões digitais SHA-256 duplicadas
# E relatar o formato PEM de cada arquivo
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

# Procurar mesma impressão digital aparecendo com formatos diferentes:
# Se você vê a mesma impressão digital com "BEGIN CERTIFICATE" e
# "BEGIN TRUSTED CERTIFICATE", essa é a origem do conflito de confiança.

Se a mesma impressão digital aparece com cabeçalhos PEM diferentes, você encontrou um conflito de formato de confiança que causará desconfiança.

Método 2: Usando trust list para identificar duplicatas

# Extrair todos os rótulos e procurar duplicatas
trust list --filter=ca-anchors | grep "^    label:" | sort | uniq -c | sort -rn | head -20

Se qualquer rótulo aparece mais de uma vez, investigue mais:

# Mostrar detalhes completos para uma duplicata suspeita
trust list | grep -B 2 -A 10 "label: DigiCert Global Root G2"

Método 3: Comparar o bundle extraído com arquivos de origem

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

# Contar certificados únicos por impressão 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-*

Se a contagem de certificados excede a contagem de impressões digitais únicas, duplicatas existem no bundle extraído.

Como Identificar Diferenças Entre Duplicatas Suspeitas

Quando você tem dois arquivos de certificado que parecem ser a mesma CA, compare-os em quatro níveis:

Nível 1: Verificar o formato PEM (causa mais comum de conflitos)

# Verificar qual cabeçalho PEM cada arquivo usa
head -1 cert1.crt
head -1 cert2.crt

# "-----BEGIN CERTIFICATE-----"         → PEM simples, sem dados de confiança
# "-----BEGIN TRUSTED CERTIFICATE-----" → Formato confiável do OpenSSL, TEM dados de confiança

Se um diz BEGIN CERTIFICATE e o outro diz BEGIN TRUSTED CERTIFICATE, você encontrou o problema. Eles causarão um conflito de confiança mesmo se o certificado subjacente for idêntico.

Nível 2: Comparar conteúdo do certificado codificado em DER

# Comparar conteúdo codificado em DER (remove cabeçalhos PEM, diferenças de espaço em branco)
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"

Nível 3: Comparar campos do certificado

# Comparar subject, issuer, serial, validade e chave
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

Nível 4: Comparar atributos de confiança incorporados (se formato TRUSTED CERTIFICATE)

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

Descobertas comuns:

Limpando Duplicatas

Se o certificado já está no bundle do sistema (caso mais comum):

Um certificado em anchors/ que já existe em ca-bundle.trust.p11-kit nem sempre é inofensivo — se a cópia no bundle do sistema tem OIDs de uso rejeitado ou atributos de confiança vazios, a duplicata PEM simples causa desconfiança. Sempre verifique os atributos de confiança antes de assumir que uma duplicata é benigna.

# 1. Verificar o formato do arquivo em anchors/
head -1 /etc/pki/ca-trust/source/anchors/suspect.crt

# 2. Encontrar a impressão digital
openssl x509 -in /etc/pki/ca-trust/source/anchors/suspect.crt -noout -fingerprint -sha256

# 3. Verificar se esse certificado existe no bundle do sistema
trust list | grep -B5 -A5 "<subject do cert>"

# 4. Se o certificado já existe no bundle do sistema com atributos
#    de confiança adequados, remova a duplicata de anchors/:
sudo rm /etc/pki/ca-trust/source/anchors/suspect.crt
sudo update-ca-trust

# 5. Verificar se o certificado agora está confiável (não desconfiado)
trust list --filter=ca-anchors | grep -A 3 "<subject do cert>"

Se você precisa manter o certificado em anchors/ (CA personalizada que não está no bundle do sistema):

# Garantir que o formato do arquivo corresponda ao que o p11-kit espera.
# Para CAs personalizadas que não estão no bundle do sistema, PEM simples está correto:
openssl x509 -in suspect.crt -out /etc/pki/ca-trust/source/anchors/suspect.crt
sudo update-ca-trust

6.7 Usando trust list para Identificar Certificados Desconfiados

O comando trust list é a ferramenta principal para inspecionar o estado do repositório de confiança após update-ca-trust ter sido executado.

Uso Básico

# Listar todos os objetos de confiança (confiáveis + desconfiados)
trust list

# Listar apenas âncoras de CA confiáveis
trust list --filter=ca-anchors

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

# Listar todos os certificados (sem filtrar por disposição de confiança)
trust list --filter=certificates

Anatomia da Saída de trust list

Cada entrada na saída de trust list se parece com isto:

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

Encontrando Certificados Desconfiados

# Listar todos os certificados desconfiados com seus rótulos
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 um certificado desconfiado específico
trust list --filter=blocklist | grep -B 1 -A 4 "Symantec"  # RHEL 9+

Rastreando um Certificado Desconfiado até Sua Origem

Quando trust list --filter=blacklist (RHEL 7/8) ou trust list --filter=blocklist (RHEL 9+) mostra um certificado que você não esperava estar desconfiado, você precisa encontrar de onde a desconfiança se origina:

# Passo 1: Obter o rótulo do certificado desconfiado
trust list --filter=blacklist     # RHEL 7/8
trust list --filter=blocklist     # RHEL 9+
# Exemplo de saída:
# pkcs11:id=%AB%CD...;type=cert
#     type: certificate
#     label: Suspicious CA
#     trust: distrusted
#     category: authority

# Passo 2: Verificar diretório de desconfiança do admin
# 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

# Passo 3: Verificar diretório de desconfiança fornecido por pacotes
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

# Passo 4: Verificar o bundle principal do p11-kit para atributos de desconfiança inline
grep -A 5 "Suspicious CA" /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit
# Procurar por "x-distrusted: true" ou "nss-mozilla-ca-policy: false"

Interpretação dos resultados:

Exemplo Prático: Depurando uma CA Desconfiada

Um serviço falha com certificate verify failed e você suspeita que a CA foi desconfiada:

# 1. Identificar a CA a partir do certificado que está falhando
openssl x509 -in /etc/pki/tls/certs/server.crt -noout -issuer
# issuer=CN = Internal Corp CA, O = CorpCo

# 2. Verificar se o emissor é confiável
trust list --filter=ca-anchors | grep -A 3 "Internal Corp CA"
# Nenhuma saída significa que NÃO está nas âncoras confiáveis

# 3. Verificar se está ativamente 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+
# Se encontrado aqui, a CA está explicitamente desconfiada

# 4. Verificar se está presente
trust list | grep -A 3 "Internal Corp CA"
# Se não encontrado em nenhum lugar, nunca foi adicionado ao repositório de confiança

# 5. Se desconfiado, encontrar o arquivo de origem (verifica caminhos RHEL 7/8 e 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. Se NÃO encontrado em nenhum diretório de desconfiança, verificar conflitos de formato de confiança:
#    procurar um PEM simples em anchors/ que duplica um cert no bundle do 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 "DUPLICATA EM ANCHORS: $f"
        echo "  Formato: $(head -1 "$f")"
        echo "  Verifique se o mesmo cert existe em ca-bundle.trust.p11-kit com formato de confiança diferente"
    fi
done

# 7. Verificar também o bundle principal do p11-kit
grep -B 2 -A 10 "Internal Corp CA" \
    /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit

Restaurando Confiança para um Certificado Desconfiado

Se você determinar que um certificado foi incorretamente desconfiado:

# Se a entrada de desconfiança está em /etc/pki/ (gerenciada pelo admin)
# 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

# Se a desconfiança vem do pacote ca-certificates, você precisa
# sobrescrevê-la adicionando o certificado como âncora confiável:
sudo cp the-cert.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust
# Nota: isso funciona porque âncoras do admin sobrescrevem desconfiança
# de nível de pacote para certificados correspondidos por conteúdo DER.

# Verificar se o certificado agora está confiável
trust list --filter=ca-anchors | grep -A 3 "The Cert Label"

Aviso: Sobrescrever uma decisão de desconfiança da Mozilla/Red Hat só deve ser feito se você tiver uma razão de negócio específica e entender as implicações de segurança. CAs são desconfiadas por motivo (comprometimento, emissão incorreta, violações de política).

6.8 Depuração Avançada com trust e p11-kit

Inspecionando Objetos de Confiança Individuais

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

# Listar todos os atributos de todos os objetos de confiança (verboso, saída grande)
trust dump

Verificando o Pipeline de Extração

Se você suspeita que update-ca-trust não está produzindo a saída esperada:

# Executar a extração manualmente com saída verbosa
p11-kit extract --format=pem-bundle \
    --filter=ca-anchors \
    --purpose=server-auth \
    /tmp/test-tls-bundle.pem

# Comparar com o bundle do sistema
diff <(sort /tmp/test-tls-bundle.pem) \
     <(sort /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem)

# Executar com log de depuração do p11-kit
P11_KIT_DEBUG=all update-ca-trust 2>&1 | head -100

Verificando Completude da Cadeia de Certificados

# Verificar um certificado de servidor contra o repositório de confiança do sistema
openssl verify -CAfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem server.crt

# Se a cadeia tem intermediários, inclua-os:
openssl verify -CAfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem \
    -untrusted intermediate.crt server.crt

# Mostrar a cadeia completa que o OpenSSL construiria:
openssl verify -show_chain -CAfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem server.crt

Verificação Cruzada do Bundle OpenSSL

O formato “certificado confiável” do OpenSSL (ca-bundle.trust.crt) inclui atributos de confiança/rejeição incorporados que são distintos do bundle PEM simples. Você pode inspecioná-los:

# Mostrar atributos de confiança para certificados no bundle 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"

Verificando a Keystore Java

# Listar todas as entradas no repositório de confiança Java
keytool -list -cacerts -storepass changeit 2>/dev/null | grep "trustedCertEntry" | wc -l

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

6.9 Solução de Problemas de Confiança

Abordagem Sistemática

Sintoma: Verificação de certificado falhou

Passo 1: Identificar qual certificado está falhando e quem o emitiu

# Obter a cadeia de emissores de um servidor remoto
openssl s_client -connect server.example.com:443 -showcerts </dev/null 2>/dev/null | \
    openssl x509 -noout -issuer -subject

# Ou de um arquivo de certificado local
openssl x509 -in server.crt -noout -issuer -subject -serial

Passo 2: Verificar se a CA emissora está no repositório de confiança

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

Passo 3: Verificar se a CA emissora 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+

Passo 4: Se ausente, adicione-a

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

Passo 5: Se desconfiada, encontre a origem e decida a ação

# Rastrear a origem da desconfiança (veja Seção 6.7)
# Verifica caminhos RHEL 7/8 (blacklist) e 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 Comuns do Repositório de Confiança

Referência Rápida

┌────────────────────────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA DO REPOSITÓRIO DE CONFIANÇA RHEL                             │
├────────────────────────────────────────────────────────────────────────────────┤
│                                                                                │
│  Adicionar 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) ou .../source/blocklist/ (RHEL 9+)                  │
│                 sudo update-ca-trust                                           │
│                                                                                │
│  Verificar:     trust list --filter=ca-anchors | grep "Nome da 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+)                       │
│                                                                                │
│  Duplicatas:    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 origem:   /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)          │
│                                                                                │
│  Prioridade:    blacklist/blocklist > anchors                                  │
│                 /etc/pki/ > /usr/share/pki/                                    │
│                 atributos .p11-kit > padrões PEM simples                       │
│                                                                                │
│  PERIGO:        Nunca adicione um PEM simples "BEGIN CERTIFICATE" em           │
│                 anchors/ se o mesmo cert já existe no bundle do sistema        │
│                 como "BEGIN TRUSTED CERTIFICATE" ou formato .p11-kit.          │
│                 Confiança vazia (sem usos) = "confiável para nada" =           │
│                 DESCONFIADO. Usos rejeitados + PEM simples → também            │
│                 DESCONFIADO.                                                   │
└────────────────────────────────────────────────────────────────────────────────┘

🧪 Laboratório Prático

Lab 05: Gerenciamento do Repositório de Confiança

Adicione CAs personalizadas ao repositório de confiança do sistema, gerencie atributos de confiança, detecte duplicatas e depure certificados desconfiados.

• 📁 Localização: labs/pt_BR/05-trust-store/
• ⏱️ Tempo: 45 minutos
• 🎯 Nível: Intermediário

Navegação do Capítulo

Capítulo 7: Assinaturas Digitais e Verificação no RHEL

Como a Confiança Funciona: Aprenda como as assinaturas digitais habilitam a validação de certificados em sistemas RHEL.

7.1 Funções Hash Criptográficas

Propriedades:

1. Determinísticas
2. Resistência a pré-imagem
3. Resistência a colisões
4. Efeito avalanche

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

7.2 Construir Assinaturas

1. Calcular hash da mensagem.
2. Criptografar hash com chave privada → assinatura.
3. Receptor descriptografa assinatura com chave pública e compara com seu próprio hash.

7.3 Impressões Digitais de Certificados

Uma impressão digital é simplesmente o hash do certificado codificado em DER, usado para identificá-lo uniquamente, ex.:

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

7.4 Lab: Assinar e Verificar um Arquivo

# assinar
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 Resumo

Assinaturas vinculam dados a identidades; hashes asseguram integridade. Juntos sustentam a validação de certificados e todas as operações PKI.

7.6 Algoritmos de Assinatura no RHEL

Aprovados por Versão RHEL

Crítico: RHEL 9+ bloqueia SHA-1 e MD5 por segurança!

Verificar Certificados no RHEL

# Verificar cadeia 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 assinatura
openssl x509 -in server.crt -noout -text | grep "Signature Algorithm"
# Deve ser SHA-256+ no RHEL 8+

Referência Rápida

┌─────────────────────────────────────────────────────────────┐
│ ASSINATURAS DIGITAIS NO RHEL                                │
├─────────────────────────────────────────────────────────────┤
│ Propósito:       Provar autenticidade e integridade         │
│ Como:            Hash + Chave privada = Assinatura          │
│ Verificar:       Assinatura + Chave pública = Hash original │
│                                                             │
│ Aprovados:       SHA-256, SHA-384, SHA-512                  │
│ Obsoleto:        SHA-1 (bloqueado no RHEL 9+)               │
│ Bloqueado:       MD5 (bloqueado no RHEL 9+)                 │
│                                                             │
│ Verificar cert:  openssl verify cert.crt                    │
│ Ver algoritmo:   openssl x509 -noout -text | grep Signature │
│ Impressão:       openssl x509 -noout -fingerprint -sha256   │
└─────────────────────────────────────────────────────────────┘

🧪 Laboratório Prático

Lab 03: Assinaturas Digitais

Assine arquivos, verifique assinaturas e detecte adulterações

• 📁 Localização: labs/pt_BR/03-digital-signatures/
• ⏱️ Tempo: 20 minutos
• 🎯 Nível: Iniciante

Navegação do Capítulo

Capítulo 8: Versões RHEL e Evolução dos Certificados

Objetivo de Aprendizagem: Entender como o gerenciamento de certificados difere entre RHEL 7, 8, 9 e 10 para que você possa identificar rapidamente comportamentos específicos de versão ao resolver problemas.

8.1 Por Que a Versão RHEL Importa

Ao resolver problemas de certificados no RHEL, a primeira pergunta sempre deve ser: “Em qual versão RHEL estou?”

O gerenciamento de certificados evoluiu significativamente entre versões RHEL. O que funciona no RHEL 7 pode falhar no RHEL 9. Entender essas diferenças é crucial para:

• ✅ Escolher a abordagem correta de solução de problemas
• ✅ Identificar erros específicos de versão
• ✅ Planejar migrações
• ✅ Escrever scripts de automatização compatíveis

8.2 Verificação Rápida de Versão

# Método 1: Verificar /etc/redhat-release
cat /etc/redhat-release
# Exemplos de saída:
#   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 versão OpenSSL (indireto mas ú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 Visão Geral de Versões RHEL

Fonte: Ciclo de Vida de Produtos Red Hat

8.4 Resumo de Diferenças Principais

RHEL 7 (Legado)

Características:

• ✅ Estável, bem compreendido
• ✅ Máxima compatibilidade
• ⚠️ TLS 1.0/1.1 habilitado por padrão
• ⚠️ Cifras fracas permitidas
• ⚠️ Gerenciamento manual de certificados

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

Quando Você Verá:

• Sistemas legados ainda não migrados
• Aplicações requerendo versões TLS antigas
• Ambientes conservadores

Comando Chave:

# Gerar chave (estilo RHEL 7)
openssl genrsa -out server.key 2048

RHEL 8 (Padrão Empresarial Atual)

Características:

• ✅ Crypto-policies em todo o sistema (mudança de jogo!)
• ✅ TLS 1.2+ por padrão
• ✅ certmonger para renovação automática
• ✅ Suites de cifra modernas
• ⚠️ Mudanças incompatíveis do RHEL 7

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

Inovação Chave - Crypto-Policies:

# Ver política atual
update-crypto-policies --show
# DEFAULT, LEGACY, FUTURE, ou FIPS

# Controle de segurança em todo o sistema!
sudo update-crypto-policies --set FUTURE

Quando Você Verá:

• Maioria dos deployments empresariais
• Aplicações modernas
• Ambientes FreeIPA

Comando Chave:

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

RHEL 9 (Padrão Moderno)

Características:

• ✅ OpenSSL 3.5.5 com arquitetura de provedores
• ✅ TLS 1.2+ obrigatório
• ✅ Crypto-policies aprimoradas
• ✅ Validação de certificado mais rigorosa
• ⚠️ Mudanças na API OpenSSL 3.x
• ⚠️ Algoritmos legados desabilitados

Pacote: openssl-3.5.5-2.el9_8.x86_64

Mudança Maior - Arquitetura de Provedores:

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

# Algoritmos legados requerem provedor explícito
openssl md5 -provider legacy file.txt

Quando Você Verá:

• Novos deployments
• Ambientes conscientes de segurança
• Últimas versões de aplicações

Comando Chave:

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

RHEL 10 (Lançamento Atual)

Características:

• ✅ Mesmo OpenSSL 3.5.5 do RHEL 9.8
• ✅ Fortalecimento de segurança contínuo
• ✅ Preparação para criptografia pós-quântica
• ✅ Suporte aprimorado de certificado para contêineres
• ⚠️ Padrões ainda mais rigorosos
• ⚠️ Remoções legadas adicionais

Pacote: openssl-3.5.5-2.el10_2.x86_64

Nota: RHEL 10.0 GA foi em 20 de maio de 2025. Recursos e capacidades podem evoluir entre versões menores (10.1, 10.2, etc.). Sempre consulte a documentação oficial para seu lançamento específico RHEL 10.x.

Foco Chave:

• Base de criptografia resistente a quântica
• Práticas de segurança modernas
• Cargas de trabalho nativas de contêiner e nuvem

Quando Você Verá:

• Deployments completamente novos
• Requisitos de segurança de ponta
• Iniciativas de preparação para o futuro

8.5 Diferenças Críticas de Versão

Suporte de Versão TLS

Disponibilidade de Ferramentas de Certificados

Mudanças Chave em Cifra/Algoritmo

8.6 Problemas Comuns Específicos de Versão

Problemas RHEL 7

# Problema: Suites de cifra antigas aceitas
# Impacto: Vulnerabilidades de segurança
# Solução: Configuração manual de cifras Apache/NGINX

Problemas RHEL 8

# Problema: Aplicação falha após migração do RHEL 7
# Razão: TLS 1.0/1.1 desabilitado por padrão
# Solução Rápida: Usar temporariamente política LEGACY (não recomendado a longo prazo)
sudo update-crypto-policies --set LEGACY

# Melhor Solução: Atualizar aplicação para suportar TLS 1.2+

Problemas RHEL 9

# Problema: Comandos OpenSSL falham com erros de provedor
# Razão: Arquitetura de provedores OpenSSL 3.x
# Solução: Especificar provedor explicitamente
openssl md5 -provider legacy file.txt

# Problema: Certificados SHA-1 rejeitados
# Razão: Validação mais rigorosa
# Solução: Reemitir certificados com SHA-256+

Problemas RHEL 10

# Problema: Padrões ainda mais rigorosos que RHEL 9
# Impacto: Certificados legados podem falhar validação
# Solução: Garantir que todos os certificados usem algoritmos modernos
#          Verificar documentação específica RHEL 10.x para sua versão menor

8.7 Impacto de Migração

RHEL 7 → RHEL 8

Impacto em Certificados: MODERADO

• TLS 1.0/1.1 desabilitado
• Cifras fracas removidas
• Integração certmonger requerida para automatização

Ação Requerida:

1. Auditar versões TLS em uso
2. Atualizar configurações de cifra
3. Testar aplicações com TLS 1.2+
4. Considerar crypto-policies

RHEL 8 → RHEL 9

Impacto em Certificados: ALTO

• Mudanças na API OpenSSL 3.x
• Remoção de algoritmos legados
• Validação de certificado mais rigorosa
• Mudanças na arquitetura de provedores

Ação Requerida:

1. Testar todas as operações de certificados
2. Atualizar scripts personalizados usando OpenSSL
3. Validar integridade da cadeia de certificados
4. Verificar uso de SHA-1

RHEL 9 → RHEL 10

Impacto em Certificados: BAIXO-MODERADO

• Mesma base OpenSSL (3.5.5)
• Fortalecimento incremental
• Refinamentos de política

Ação Requerida:

1. Revisar documentação RHEL 10.x
2. Testar compatibilidade de crypto-policy
3. Validar uso de algoritmos modernos

8.8 Escolher a Abordagem Certa

Para Solução de Problemas

# Sempre começar com verificação de versão
cat /etc/redhat-release

# Depois verificar versão OpenSSL
openssl version

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

Árvore de Decisão de Referência Rápida

É RHEL 7?
├─ SIM → Verificar problemas de TLS/cifra legados
│        Configuração manual provavelmente necessária
│        Considerar planejamento de migração
│
└─ NÃO → É RHEL 8?
    ├─ SIM → Verificar crypto-policies primeiro!
    │        Usar certmonger para automatização
    │        Considerar atualização para RHEL 9
    │
    └─ NÃO → É RHEL 9 ou 10?
        └─ SIM → Verificar problemas de provedor OpenSSL 3.x
                 Verificar algoritmos modernos em uso
                 Aproveitar ferramentas aprimoradas

8.9 Conclusões Chave

1. Sempre verificar versão RHEL primeiro ao resolver problemas
2. RHEL 8 introduziu crypto-policies - mudança de jogo para gerenciamento de certificados
3. RHEL 9 usa OpenSSL 3.x - mudanças significativas em API e comportamento
4. RHEL 10 continua base RHEL 9 - melhorias incrementais
5. Algoritmos legados removidos progressivamente entre versões
6. Testes de migração são críticos - comportamento de certificados muda significativamente

8.10 O Que Vem a Seguir?

Agora que você entende as diferenças de versões RHEL, mergulharemos mais fundo em:

• Capítulo 9: Gerenciamento de Certificados no RHEL 7 (detalhado)
• Capítulo 10: RHEL 8 e Crypto-Policies (detalhado)
• Capítulo 11: Segurança Moderna no RHEL 9 (detalhado)
• Capítulo 12: Recursos Atuais do RHEL 10 (detalhado)

Cartão de Referência Rápida

┌────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA VERSÕES RHEL                             │
├─────────────┬───────────┬──────────────┬───────────────────┤
│ RHEL 7      │ 1.0.2k    │ Manual       │ Amigável legacy   │
│ RHEL 8      │ 1.1.1k    │ Crypto-pols  │ Padrão empresa    │
│ RHEL 9      │ 3.5.5     │ OpenSSL 3.x  │ Moderno seguro    │
│ RHEL 10     │ 3.5.5     │ Fortalecido  │ Preparado futuro  │
└─────────────┴───────────┴──────────────┴───────────────────┘

Verificar versão:    cat /etc/redhat-release
Verificar OpenSSL:   openssl version
Verificar política:  update-crypto-policies --show  (RHEL 8+)

Navegação do Capítulo

Capítulo 9: Gerenciamento de Certificados no RHEL 7

Legado mas Importante: RHEL 7 alcançou fim de manutenção em junho 2024, mas muitas empresas ainda executam. Aprenda como gerenciamento de certificados funciona no RHEL 7.

9.1 Visão Geral RHEL 7

Lançamento: 10 de junho de 2014 Suporte Manutenção Terminou: 30 de junho de 2024 Extended Life Cycle Support: Disponível até 2028

Características Chave:

• Versão OpenSSL: 1.0.2k-26 (pacote: openssl-1.0.2k-26.el7_9.x86_64)
• TLS Padrão: TLS 1.0, 1.1, 1.2 todos habilitados
• Repositório de Confiança: /etc/pki/ca-trust/extracted/
• Abordagem Gerenciamento: Primariamente manual
• Crypto-Policies: Não disponíveis (recurso RHEL 8+)

Nota: Se você ainda está no RHEL 7, planeje migração para RHEL 8 ou 9. Atualizações segurança são limitadas.

9.2 Especificações OpenSSL 1.0.2k

Verificação Versão

# Verificar versão OpenSSL no RHEL 7
openssl version
# OpenSSL 1.0.2k-fips  12 Jan 2017

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

Recursos Chave e Limitações

Recursos:

• ✅ Suporte TLS 1.0, 1.1, 1.2
• ✅ Estável e bem testado
• ✅ Compatibilidade ampla
• ✅ Tipos chave RSA, ECC, DSA

Limitações:

• ❌ Sem suporte TLS 1.3
• ❌ Sintaxe comando antiga (genrsa vs genpkey)
• ❌ Cifras padrão mais fracas
• ❌ Suites cifra modernas limitadas

Sintaxe Comando (Estilo RHEL 7)

#============================================#
# GERAR CHAVE RSA (RHEL 7)
#============================================#

# Estilo antigo (comum no RHEL 7)
openssl genrsa -out server.key 2048

# Com proteção passphrase
openssl genrsa -aes256 -out server.key 2048

# Remover passphrase da chave
openssl rsa -in server.key -out server-nopass.key


#============================================#
# GERAR CSR (RHEL 7)
#============================================#

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

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

# ⚠️ Nota: SANs são mais difíceis de adicionar com OpenSSL RHEL 7
# Necessita arquivo config para SANs


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

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

# Apenas expiração
openssl x509 -in server.crt -noout -dates

# Apenas subject
openssl x509 -in server.crt -noout -subject

9.3 Gerenciamento Repositório de Confiança no RHEL 7

Adicionando CAs Customizadas

#============================================#
# ADICIONAR CA CUSTOMIZADA (RHEL 7)
#============================================#

# Passo 1: Copiar certificado CA para diretório anchors
sudo cp corporate-ca.crt /etc/pki/ca-trust/source/anchors/

# Passo 2: Atualizar repositório de confiança
sudo update-ca-trust extract

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

# Verificar aplicações usam
openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt test-cert.crt

Localizações Repositório de Confiança (RHEL 7)

/etc/pki/ca-trust/
├── source/
│   └── anchors/                   ← Adicionar CAs customizadas aqui
│
└── extracted/
    ├── pem/
    │   └── tls-ca-bundle.pem      ← OpenSSL, Python, Ruby
    ├── openssl/
    │   └── ca-bundle.trust.crt    ← OpenSSL específico
    └── java/
        └── cacerts                ← Aplicações Java

9.4 Configuração Serviço (Abordagem RHEL 7)

Apache HTTPS no RHEL 7

#============================================#
# SETUP APACHE SSL/TLS (RHEL 7)
#============================================#

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

# Gerar certificado e chave
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)"

# Obter certificado da CA (ou autoassinado para teste)
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
# Definir:
#   SSLCertificateFile /etc/pki/tls/certs/server.crt
#   SSLCertificateKeyFile /etc/pki/tls/private/server.key
#
#   # Recomendado: Desabilitar versões TLS fracas
#   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
#
#   # Recomendado: Apenas cifras fortes
#   SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!RC4

# Iniciar Apache
sudo systemctl enable httpd
sudo systemctl start httpd

# Testar
curl -vk https://localhost/

NGINX no RHEL 7

#============================================#
# SETUP NGINX SSL/TLS (RHEL 7)
#============================================#

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

# Gerar 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)
# Adicionar ao bloco server:
#   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 Renovação Manual Certificado (RHEL 7)

Sem crypto-policies, sem ferramentas automáticas - tudo é manual!

Processo Renovação

#============================================#
# PROCESSO RENOVAÇÃO MANUAL (RHEL 7)
#============================================#

# Passo 1: Verificar expiração (definir lembrete calendário)
openssl x509 -in /etc/pki/tls/certs/server.crt -noout -dates

# Passo 2: Gerar novo CSR (reusar chave existente)
openssl req -new -key /etc/pki/tls/private/server.key \
  -out /tmp/server-renewal.csr \
  -subj "/CN=server.example.com"

# Passo 3: Submeter CSR para CA

# Passo 4: Receber novo certificado da CA

# Passo 5: Backup certificado antigo
sudo cp /etc/pki/tls/certs/server.crt \
     /etc/pki/tls/certs/server.crt.$(date +%Y%m%d).old

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

# Passo 7: Recarregar serviço
sudo systemctl reload httpd

# Passo 8: Testar
curl -v https://localhost/
openssl s_client -connect localhost:443

Rastreamento Renovações Certificado

#============================================#
# CRIAR RASTREAMENTO RENOVAÇÃO (RHEL 7)
#============================================#

# Job cron para verificar expiração
cat > /etc/cron.weekly/check-cert-expiration << 'EOF'
#!/bin/bash
# Verificar certificados expirando em 60 dias

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 dias!"
    echo "$cert" | mail -s "Certificado Expirando Em Breve" admin@example.com
  fi
done
EOF

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

9.6 Problemas Comuns Certificado RHEL 7

Problema 1: TLS 1.0/1.1 Depreciados

Problema: Clientes modernos rejeitam TLS 1.0/1.1

Sintomas:

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

Correção:

# Atualizar Apache para desabilitar versões TLS antigas
# /etc/httpd/conf.d/ssl.conf
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

# Reiniciar Apache
sudo systemctl restart httpd

Problema 2: Cifras Fracas

Problema: Scans PCI/Segurança marcam cifras fracas

Correção:

# Apache: Usar apenas cifras fortes
# /etc/httpd/conf.d/ssl.conf
SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!RC4:!EXPORT
SSLHonorCipherOrder on

# Testar
openssl s_client -connect localhost:443 -cipher '3DES'
# Deveria falhar se 3DES está desabilitado

Problema 3: SANs Faltando

Problema: Navegadores modernos requerem Subject Alternative Names

Desafio RHEL 7: SANs são mais difíceis de adicionar com OpenSSL 1.0.2

Solução: Usar arquivo config

# Criar config 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

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

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

9.7 certmonger no RHEL 7

Disponível: Sim (versão básica)

#============================================#
# CERTMONGER NO RHEL 7
#============================================#

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

# Solicitar certificado do 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 status certificado específico
sudo getcert list -f /etc/pki/tls/certs/web.crt

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

Limitações RHEL 7:

• Sem suporte ACME (Let’s Encrypt requer certbot manual)
• Saída status menos detalhada
• Menos opções comando post-save

9.8 Considerações Migração

Quando Migrar do RHEL 7

Você deveria migrar se:

• ✅ Suporte terminou (junho 2024) e você necessita atualizações
• ✅ Necessita suporte TLS 1.3
• ✅ Quer crypto-policies para gerenciamento mais fácil
• ✅ Requer recursos segurança modernos
• ✅ Conformidade requer SO suportado

Tarefas Certificado Pré-Migração

#============================================#
# AUDITORIA CERTIFICADO PRÉ-MIGRAÇÃO RHEL 7
#============================================#

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

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

# 3. Verificar algoritmos assinatura (SHA-1 não funcionará no 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
# Se algum encontrado, reemitir antes migração!

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

# 5. Exportar certificados e chaves
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 Fluxos de Trabalho Comuns RHEL 7

Fluxo de Trabalho 1: Configuração Manual Apache HTTPS

# Workflow completo do zero

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

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

# 3. Definir permissões chave
sudo chmod 600 /etc/pki/tls/private/$(hostname -s).key

# 4. Criar 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. Submeter CSR para CA, aguardar 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. Testar configuração
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. Testar
curl -vk https://$(hostname -f)/

Fluxo de Trabalho 2: Integração FreeIPA

#============================================#
# WORKFLOW CERTIFICADO FREEIPA (RHEL 7)
#============================================#

# Pré-requisitos: Sistema deve estar registrado 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 status
sudo getcert list

# Aguardar status MONITORING (certificado emitido)

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

# Recarregar Apache quando cert renova
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 Solução de Problemas Certificados RHEL 7

Comandos Diagnóstico

#============================================#
# DIAGNÓSTICO CERTIFICADO RHEL 7
#============================================#

# Verificar versão OpenSSL
openssl version

# Testar HTTPS localmente
openssl s_client -connect localhost:443

# Verificar configuração SSL Apache
sudo apachectl -t -D DUMP_VHOSTS | grep 443

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

# Verificar negações SELinux
sudo grep AVC /var/log/audit/audit.log | grep cert

# Verificar permissões arquivo
ls -lZ /etc/pki/tls/certs/*.crt
ls -lZ /etc/pki/tls/private/*.key

# Verificar par certificado/chave
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
# Hashes MD5 deveriam coincidir

Erros Comuns RHEL 7

9.11 Fortalecimento Segurança no RHEL 7

Configuração Recomendada

#============================================#
# FORTALECIMENTO APACHE SSL/TLS (RHEL 7)
#============================================#

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

# Desabilitar protocolos antigos
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

# Apenas cifras fortes
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!3DES:!DES

# Honrar preferência cipher servidor
SSLHonorCipherOrder on

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

# OCSP Stapling (não disponível no OpenSSL 1.0.2 RHEL 7 por padrão)
# Disponível em alguns backports

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

9.12 Caminho Migração para RHEL 8+

Passos Migração Específicos Certificado

#============================================#
# PREPARAR CERTIFICADOS PARA MIGRAÇÃO
#============================================#

# 1. Verificar todos certificados usam SHA-256+ (sem SHA-1 nem 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 migração!"

# 2. Verificar tamanhos chave (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: Chave muito pequena ($SIZE bits)"
  fi
done

# 3. Backup de tudo
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 inventário certificado
./generate-cert-inventory.sh > cert-inventory-pre-migration.csv

# 5. Testar compatibilidade TLS 1.2
# Garantir que todos serviços funcionam apenas com TLS 1.2

9.13 Quando RHEL 7 Faz Sentido

Ainda Usando RHEL 7? Considere:

Razões para Ficar (Temporariamente):

• Contrato Extended Life Cycle Support ativo
• Aplicações legadas críticas requerendo TLS 1.0/1.1
• Migração planejada para futuro próximo
• Testando RHEL 8/9 em paralelo

Razões para Migrar:

• ✅ Manutenção estendida terminou junho 2024
• ✅ Sem crypto-policies (mais difícil gerenciar)
• ✅ Sem TLS 1.3
• ✅ Atualizações segurança limitadas
• ✅ Aplicações modernas abandonando suporte TLS 1.0/1.1

9.14 Conclusões Chave

1. RHEL 7 é manual - Sem crypto-policies, configuração cuidadosa necessária
2. OpenSSL 1.0.2k - Sintaxe antiga, sem TLS 1.3
3. TLS 1.0/1.1 habilitados por padrão - Desabilitá-los manualmente
4. SHA-1 ainda funciona - Mas não após migração para RHEL 8+
5. certmonger disponível - Mas básico comparado a RHEL 8+
6. Planejar migração - Suporte RHEL 7 está terminando
7. Documentar tudo - Torna migração mais fácil

Referência Rápida

┌─────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA CERTIFICADO RHEL 7                    │
├─────────────────────────────────────────────────────────┤
│ OpenSSL:     1.0.2k-26                                  │
│ TLS:         1.0, 1.1, 1.2 (sem 1.3)                    │
│ Política:    Configuração manual (sem crypto-policies)  │
│                                                         │
│ Gerar:       openssl genrsa -out key.pem 2048           │
│ CSR:         openssl req -new -key key.pem -out req.csr │
│ Ver:         openssl x509 -in cert.crt -noout -text     │
│ Testar:      openssl s_client -connect host:443         │
│                                                         │
│ Fortalecer:  SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1     │
│              SSLCipherSuite HIGH:!aNULL:!MD5:!3DES      │
└─────────────────────────────────────────────────────────┘

Navegação do Capítulo

Capítulo 10: RHEL 8 e Crypto-Policies

Mudança Radical: RHEL 8 introduziu crypto-policies, revolucionando como certificados e criptografia são gerenciados system-wide. Este é o recurso mais importante para entender no RHEL 8.

10.1 O Que Mudou no RHEL 8?

Lançamento: 7 de maio de 2019 Suporte Até: 31 de maio de 2029 Versão Atual: RHEL 8.10 (em 2024)

Mudanças Principais Relacionadas a Certificados:

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

10.2 Entendendo Crypto-Policies

A Ideia Revolucionária

Problema RHEL 7:

❌ Configurar Apache:     SSLProtocol, SSLCipherSuite
❌ Configurar NGINX:      ssl_protocols, ssl_ciphers
❌ Configurar Postfix:    smtpd_tls_protocols
❌ Configurar OpenLDAP:   olcTLSProtocolMin
❌ Configurar cada aplicação diferentemente!

Solução RHEL 8:

✅ Definir UMA política system-wide
✅ Todas aplicações automaticamente cumprem!

Como 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 Disponíveis

As Quatro Políticas Principais

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

# Políticas disponíveis no RHEL 8:

Detalhes Política

Política DEFAULT:

Versões TLS: 1.2, 1.3
RSA/DH Mínimo: 2048 bits
ECC Mínimo: secp256r1 (P-256)
Cifras: AES-GCM, ChaCha20-Poly1305, AES-CBC
Assinaturas: SHA-256, SHA-384, SHA-512
Bloqueados: MD5, assinaturas SHA-1, 3DES, RC4, DSS

Política LEGACY:

Versões TLS: 1.0, 1.1, 1.2, 1.3
RSA/DH Mínimo: 1024 bits
Cifras: Inclui 3DES, cifras fracas
Assinaturas: Permite SHA-1
Uso: Apenas para compatibilidade sistemas antigos (temporário!)

Política FUTURE:

Versões TLS: 1.2, 1.3 (cifras mais rigorosas)
RSA/DH Mínimo: 3072 bits
ECC Mínimo: secp384r1 (P-384)
Assinaturas: SHA-384, SHA-512 preferidas
Bloqueados: Tudo em DEFAULT, e mais

Política FIPS:

Versões TLS: 1.2, 1.3
Algoritmos: Apenas aprovados FIPS 140-2
Requer: Modo FIPS habilitado
Mais Rigoroso: Requisitos conformidade federal

10.4 Mudando Crypto-Policies

Mudanças Política Básicas

#============================================#
# VER POLÍTICA ATUAL
#============================================#

update-crypto-policies --show
# DEFAULT


#============================================#
# DEFINIR POLÍTICA
#============================================#

# Definir para FUTURE (mais rigorosa)
sudo update-crypto-policies --set FUTURE

# Definir para LEGACY (menos segura, para compatibilidade)
sudo update-crypto-policies --set LEGACY

# Definir para FIPS (requer modo FIPS habilitado)
sudo fips-mode-setup --enable
sudo reboot
sudo update-crypto-policies --set FIPS

# Retornar para DEFAULT
sudo update-crypto-policies --set DEFAULT


#============================================#
# APLICAR POLÍTICA (reiniciar serviços)
#============================================#

# Crypto-policies atualizam arquivos config, mas serviços devem reiniciar
sudo systemctl restart httpd nginx postfix

# Ou reiniciar (garante que tudo pega nova política)
sudo reboot

O Que Acontece Quando Você Muda Política

# Exemplo: Mudando para política FUTURE

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

# Após:
sudo update-crypto-policies --set FUTURE

# Mudanças acontecem em:
ls -l /etc/crypto-policies/back-ends/
# opensslcnf.config      ← Config OpenSSL atualizada
# gnutls.config          ← Config GnuTLS atualizada
# nss.config             ← Config NSS atualizada
# bind.config            ← Config BIND atualizada
# ... e mais

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

10.5 Impacto Política em Certificados

Impacto Política DEFAULT

#============================================#
# O QUE POLÍTICA DEFAULT PERMITE/BLOQUEIA
#============================================#

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

# ❌ BLOQUEADO:
- TLS 1.0, 1.1
- RSA < 2048 bits
- 3DES, RC4, DES
- Assinaturas MD5, SHA-1
- Chaves DSA
- Cifras export

Testando Contra Política Atual

#============================================#
# TESTAR SE SEU CERTIFICADO FUNCIONA
#============================================#

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

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

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

# Ver quais cifras estão disponíveis sob política atual
openssl ciphers -v | head -20

10.6 Recursos OpenSSL 1.1.1 (RHEL 8)

Novos Recursos

#============================================#
# SUPORTE TLS 1.3 (Novo no RHEL 8!)
#============================================#

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

# Benefícios TLS 1.3:
# - Handshake mais rápido
# - Forward secrecy obrigatório
# - Recursos desatualizados removidos


#============================================#
# GERAÇÃO CHAVE MODERNA
#============================================#

# Estilo antigo (ainda funciona)
openssl genrsa -out server.key 2048

# Novo estilo (preferido no RHEL 8)
openssl genpkey -algorithm RSA -out server.key \
  -pkeyopt rsa_keygen_bits:2048

# Chaves EC (elliptic curve)
openssl genpkey -algorithm EC -out ec.key \
  -pkeyopt ec_paramgen_curve:P-256


#============================================#
# GERAÇÃO CSR MELHORADA
#============================================#

# CSR com SANs (muito mais 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 Aprimoramentos certmonger no RHEL 8

Recursos Melhorados

#============================================#
# CERTMONGER NO RHEL 8
#============================================#

# Melhor integração 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-save (melhorado!)

# Saída status aprimorada
sudo getcert list -v

# Melhor relatório erro
sudo getcert list -f /etc/pki/tls/certs/web.crt
# Mostra mensagens erro detalhadas se renovação falha

Melhorias certmonger RHEL 8:

• ✅ Melhores mensagens erro
• ✅ Suporte comando post-save
• ✅ Integração IPA melhorada
• ✅ Renovação mais confiável

10.8 Cenários Comuns RHEL 8

Cenário 1: Migrado do RHEL 7, App TLS 1.0 Quebra

Problema:

# Aplicação funcionava no RHEL 7
# Após migração para RHEL 8: falhas conexão

Diagnóstico:

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

# Verificar logs aplicação
journalctl -xe | grep -i tls
# "wrong version number" ou "no shared cipher"

Correção Rápida (Temporária):

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

Correção Apropriada:

# Atualizar aplicação para suportar TLS 1.2+
# Ou configurar aplicação especificamente (opt-out de política)

Cenário 2: Necessita Suportar Clientes Antigos

Problema: Windows Server 2008, clientes Java 7 não conseguem conectar

Solução:

# Opção 1: Política LEGACY (não recomendado longo prazo)
sudo update-crypto-policies --set LEGACY

# Opção 2: Módulo política customizado
# Criar /etc/crypto-policies/policies/modules/COMPAT-OLD-CLIENTS.pmod
sudo update-crypto-policies --set DEFAULT:COMPAT-OLD-CLIENTS

# Opção 3: Opt-out serviço específico
# Configurar aquele serviço para permitir TLS 1.0/1.1

Cenário 3: Testando Antes de Produção

#============================================#
# TESTAR IMPACTO CRYPTO-POLICY
#============================================#

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

# Testar com política FUTURE
sudo update-crypto-policies --set FUTURE
sudo systemctl restart httpd

# Executar testes
curl https://localhost/
# Suite teste aplicação

# Se problemas:
sudo update-crypto-policies --set $CURRENT  # Reverter
sudo systemctl restart httpd

10.9 Overrides Por Aplicação

Quando Sobrescrever

Às vezes você necessita UMA aplicação optar por fora da política sistema:

Exemplo: App legado necessita TLS 1.0, mas você quer DEFAULT para todo resto

#============================================#
# OVERRIDE APACHE (Opt-Out)
#============================================#

# /etc/httpd/conf.d/ssl.conf
# Adicionar isto para re-habilitar TLS 1.0 apenas para Apache:
SSLProtocol all

# Ou usar Include para carregar crypto-policy
Include /etc/crypto-policies/back-ends/httpd.config
# Então sobrescrever configurações específicas após

# ⚠️ Nota: Isto opta FORA de crypto-policies para Apache
# Você agora gerencia TLS Apache manualmente novamente

Melhor: Usar módulos política (ver Capítulo 23 para detalhes)

10.10 Solução de Problemas de Crypto-Policy

Problemas Comuns

Problema 1: “no shared cipher”

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

# Testar quais cifras estão disponíveis
openssl ciphers -v

# Verificar requisição cliente
openssl s_client -connect localhost:443 -cipher 'ALL'

# Solução: Temporariamente usar LEGACY para identificar problema
sudo update-crypto-policies --set LEGACY
# Se funciona → problema compatibilidade cipher
# Correção apropriada: Atualizar cliente ou criar política customizada

Problema 2: Serviço falha após mudança política

# Sintoma
sudo systemctl status httpd
# Falhou ao iniciar

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

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

10.11 Melhores Práticas para RHEL 8

Recomendação: Usar Política DEFAULT

# Para maioria ambientes:
sudo update-crypto-policies --set DEFAULT

# Razões:
✅ Segurança/compatibilidade balanceadas
✅ Testada pela Red Hat
✅ Cumpre padrões modernos
✅ Bloqueia algoritmos fracos conhecidos
✅ Funciona com maioria clientes

Quando Usar Outras Políticas

Usar LEGACY quando:

• Temporariamente suportando clientes muito antigos
• Período migração do RHEL 7
• Testando compatibilidade
• Mas: Planejar voltar para DEFAULT ASAP!

Usar FUTURE quando:

• Requisitos alta segurança
• Todos clientes são modernos
• Quer configurações mais rigorosas
• Planejando para frente

Usar FIPS quando:

• Conformidade federal requerida
• Contratos governo
• Indústrias regulamentadas
• Certificações segurança necessárias

10.12 Conclusões Chave (RHEL 8)

1. Crypto-policies são O recurso - Aprenda bem
2. Política DEFAULT é boa - Não mude sem razão
3. TLS 1.3 agora disponível - Mais rápido e mais seguro
4. OpenSSL 1.1.1 - Recursos modernos, melhor sintaxe
5. certmonger aprimorado - Melhor automatização
6. Migração do RHEL 7 - Testar completamente
7. Planejar para RHEL 9 - OpenSSL 3.x chegando

Referência Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA CRYPTO-POLICIES RHEL 8                     │
├──────────────────────────────────────────────────────────────┤
│ OpenSSL:      1.1.1k-14                                      │
│ TLS:          1.2, 1.3 (política DEFAULT)                    │
│ Recurso:      Crypto-policies system-wide                    │
│                                                              │
│ Ver política: update-crypto-policies --show                  │
│ Def política: sudo update-crypto-policies --set <POLÍTICA>   │
│ Políticas:    DEFAULT, LEGACY, FUTURE, FIPS                  │
│                                                              │
│ Arq config:   /etc/crypto-policies/back-ends/                │
│ Reiniciar:    systemctl restart <serviços>                   │
│                                                              │
│ Gerar chave:  openssl genpkey -algorithm RSA -out key.pem    │
│ CSR com SANs: openssl req -new -addext "subjectAltName=..."  │
└──────────────────────────────────────────────────────────────┘

Navegação do Capítulo

Capítulo 11: Segurança Moderna no RHEL 9

Padrão Moderno: RHEL 9 representa o estado da arte atual em gerenciamento de certificados Linux com OpenSSL 3.x, crypto-policies aprimoradas, e padrões segurança mais rigorosos.

11.1 Visão Geral RHEL 9

Lançamento: 17 de maio de 2022 Suporte Até: 31 de maio de 2032 Versão Atual: RHEL 9.8

Mudanças Principais do RHEL 8:

Pacote: openssl-3.5.5-2.el9_8.x86_64

11.2 OpenSSL 3.5.5 - Mudanças Principais

Arquitetura Provider (Novo!)

O Que Mudou: OpenSSL 3.x introduziu sistema “provider” para diferentes implementações crypto.

#============================================#
# LISTAR PROVIDERS (RHEL 9)
#============================================#

openssl list -providers

# Saída:
# 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

Algoritmos Legados Requerem Provider Explícito

Mudança Disruptiva: MD5, Blowfish, CAST5 necessitam -provider legacy

#============================================#
# USANDO ALGORITMOS LEGADOS (RHEL 9)
#============================================#

# Isto FALHA no RHEL 9:
openssl md5 file.txt
# Erro: unsupported

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

# Por quê: Algoritmos legados desabilitados por padrão para segurança

Geração Chave Moderna (RHEL 9)

#============================================#
# GERAR CHAVES (RHEL 9)
#============================================#

# RSA 2048 (padrão)
openssl genpkey -algorithm RSA -out server.key \
  -pkeyopt rsa_keygen_bits:2048

# RSA 4096 (mais forte)
openssl genpkey -algorithm RSA -out server.key \
  -pkeyopt rsa_keygen_bits:4096

# EC P-256 (elliptic curve, recomendado)
openssl genpkey -algorithm EC -out ec.key \
  -pkeyopt ec_paramgen_curve:P-256

# EC P-384 (mais forte)
openssl genpkey -algorithm EC -out ec.key \
  -pkeyopt ec_paramgen_curve:P-384


#============================================#
# GERAR CSR COM 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 Aprimoradas (RHEL 9)

Subpolíticas (Novo Recurso!)

RHEL 9 introduz modificadores política:

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

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

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

# Subpolíticas comuns:
# - NO-SHA1: Desabilitar completamente SHA-1 (mesmo em assinaturas)
# - NO-ENFORCE-EMS: Desabilitar Extended Master Secret
# - GOST: Habilitar algoritmos GOST
# - NO-CAMELLIA: Desabilitar cifra Camellia

# Ver módulos disponíveis
ls /usr/share/crypto-policies/policies/modules/

Módulos Crypto-Policy Customizados (RHEL 9)

#============================================#
# CRIAR MÓDULO POLÍTICA CUSTOMIZADO
#============================================#

# Criar módulo customizado
sudo vi /etc/crypto-policies/policies/modules/CUSTOM.pmod

# Conteúdo exemplo:
min_rsa_size = 3072
min_dh_size = 3072
min_dsa_size = 3072

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

# Testar
openssl ciphers -v | head

11.4 Validação Certificado Mais Rigorosa

O Que É Mais Rigoroso no RHEL 9?

#============================================#
# EXEMPLOS VALIDAÇÃO MAIS RIGOROSA
#============================================#

# 1. Assinaturas SHA-1 completamente rejeitadas
openssl verify sha1-signed-cert.crt
# Erro: CA md too weak

# 2. Autoassinado sem trust CA apropriado rejeitado
curl https://self-signed.example.com/
# Erro: certificate verify failed

# 3. Cadeia certificado deve estar completa
# Intermediário faltando → conexão falha

# 4. Hostname deve coincidir (CN ou SAN)
openssl s_client -connect server.example.com:443 -servername different.example.com
# Erro verificação: hostname mismatch

# 5. Chaves < 2048 bits rejeitadas
# (mesmo em política LEGACY, < 1024 rejeitado)

Impacto em Aplicações

Aplicações compiladas contra OpenSSL 3.x:

• Podem necessitar mudanças código se usando APIs depreciadas
• Tratamento erro pode ser diferente
• Código crypto customizado necessita teste

Administradores sistema:

• ✅ Maioria mudanças transparentes
• ✅ Comandos maioria iguais
• ⚠️ Validação mais rigorosa captura mais problemas (isto é bom!)

11.5 Automação no RHEL 9: certmonger, certbot e IdM ACME

Use o cliente certo para a CA certa

#============================================#
# OPÇÕES DE AUTOMAÇÃO NO RHEL 9
#============================================#

# Fluxo nativo do 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"

# Fluxo público do Let's Encrypt
# Use certbot, não uma definição falsa de CA Let's Encrypt no certmonger.
sudo certbot certonly --apache -d web.example.com

# Fluxo IdM ACME (opcional)
# Isto aponta para o diretório ACME do seu servidor IPA, não para o Let's Encrypt.
sudo certbot certonly \
  --server https://ipa.example.com/acme/directory \
  -d host.example.com

Importante: IdM ACME e Let’s Encrypt são CAs diferentes. certmonger continua sendo a ferramenta nativa do RHEL para IPA, CA local e fluxos de renovação com rastreamento.

11.6 Aprimoramentos Repositório de Confiança

Gerenciamento Trust Avançado

#============================================#
# GERENCIAMENTO TRUST RHEL 9
#============================================#

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

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

# Listar trust com detalhes
trust list --filter=ca-anchors

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

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

11.7 Problemas Comuns RHEL 9 e Soluções

Problema 1: Mudanças API OpenSSL 3.x

Problema: Aplicação customizada falha com erros OpenSSL

Sintomas:

Error: EVP_PKEY_RSA no longer supported
Error: Provider not available

Solução:

# Verificar se aplicação está usando APIs depreciadas
# Aplicação necessita recompilação contra OpenSSL 3.x

# Temporário: Definir variável ambiente compat (se disponível)
export OPENSSL_CONF=/etc/pki/tls/openssl-compat.cnf

# Longo prazo: Atualizar aplicação

Problema 2: Certificados SHA-1 Rejeitados

Problema: Certificados legados com assinaturas SHA-1 falham

Sintomas:

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

Solução:

# Reemitir certificado com SHA-256+
# Sem workaround - SHA-1 é bloqueado para segurança

# Verificar assinatura certificado
openssl x509 -in cert.crt -noout -text | grep "Signature Algorithm"
# Deve mostrar: sha256WithRSAEncryption ou melhor

Problema 3: Algoritmo Legado Não Disponível

Problema: Aplicação necessita MD5/RC4/etc.

Sintomas:

openssl md5 file.txt
# Erro: unsupported

Solução:

# Usar provider legado explicitamente
openssl md5 -provider legacy file.txt

# Para aplicações: Atualizar para usar SHA-256+
# Ou configurar para carregar provider legado

11.8 Modo FIPS no RHEL 9

Suporte FIPS Melhorado

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

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

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

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

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

FIPS RHEL 9:

• Usa provider FIPS OpenSSL 3.x
• Módulos validados FIPS 140-2
• Transição para FIPS 140-3 em progresso

11.9 Migração do RHEL 8

Impacto Certificado

Impacto Moderado:

• Mudanças API OpenSSL (afeta apps customizadas)
• Validação mais rigorosa (captura mais problemas)
• Algoritmos legados removidos
• SHA-1 completamente bloqueado

Verificações Pré-Migração

#============================================#
# PRÉ-MIGRAÇÃO CERTIFICADO RHEL 8 → 9
#============================================#

# 1. Verificar por certificados SHA-1 (falharão no 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 quaisquer certs SHA-1 antes migração!

# 2. Verificar aplicações customizadas usando OpenSSL
rpm -qa | grep -E "custom|local"
# Testar estas aplicações em ambiente RHEL 9

# 3. Verificar compatibilidade crypto-policy
update-crypto-policies --show

# 4. Testar operações certificado
openssl s_client -connect localhost:443

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

11.10 Melhores Práticas para RHEL 9

Configuração Recomendada

#============================================#
# SETUP RECOMENDADO (RHEL 9)
#============================================#

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

# 2. Usar certmonger para automação nativa
sudo dnf install certmonger
sudo systemctl enable --now certmonger

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

# 4. Para interno: usar FreeIPA com 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. Gerar chaves EC (menores, mais rápidas)
openssl genpkey -algorithm EC -out ec.key \
  -pkeyopt ec_paramgen_curve:P-256

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

11.11 Novos Recursos Que Você Deveria Usar

Recurso 1: Fluxos mais fortes de certmonger + IPA

# Automação nativa do 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"

# Melhor saída de status no RHEL 9
sudo getcert list -v

Recurso 2: Relatório Status Aprimorado

# Status mais detalhado
sudo getcert list -v

# Melhores mensagens erro
sudo getcert list -f /etc/pki/tls/certs/web.crt
# Mostra razão erro exata se renovação falha

Recurso 3: Subpolíticas Crypto-Policy

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

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

11.12 Mudanças Disruptivas do RHEL 8

Mudanças API

Se você tem aplicações customizadas:

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

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

Impacto: Aplicações compiladas customizadas podem necessitar atualizações

Mudanças Comando

# Maioria comandos funcionam iguais, mas alguns casos extremos:

# RHEL 8: Isto funciona
openssl md5 file.txt

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

# Solução: Usar SHA-256 ao invés
openssl sha256 file.txt

11.13 Cenários Comuns RHEL 9

Cenário 1: Configuração Fresh Apache HTTPS RHEL 9

#============================================#
# SETUP COMPLETO APACHE HTTPS (RHEL 9)
#============================================#

# 1. Instalar Apache com 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. Aguardar certificado (verificar status)
sudo getcert list

# 5. Configurar Apache para usar certificado
# /etc/httpd/conf.d/ssl.conf já aponta para:
#   SSLCertificateFile /etc/pki/tls/certs/localhost.crt
# Atualizar para:
#   SSLCertificateFile /etc/pki/tls/certs/web.crt
#   SSLCertificateKeyFile /etc/pki/tls/private/web.key

# 6. Crypto-policy lida com configurações TLS automaticamente!
# Sem necessidade definir SSLProtocol ou 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. Testar
curl -v https://$(hostname -f)/

# 10. Renovação automática acontece bem antes da expiração!

Resultado: HTTPS interno totalmente automatizado com FreeIPA e certmonger!

11.14 Solução de Problemas Certificados RHEL 9

Comandos Diagnóstico

#============================================#
# DIAGNÓSTICO CERTIFICADO RHEL 9
#============================================#

# Verificar versão OpenSSL
openssl version
# OpenSSL 3.5.5

# Verificar providers
openssl list -providers

# Verificar crypto-policy
update-crypto-policies --show

# Testar conexão com TLS 1.3
openssl s_client -connect server:443 -tls1_3

# Verificar algoritmo assinatura certificado
openssl x509 -in cert.crt -noout -text | grep "Signature Algorithm"
# Deve ser SHA-256+ no RHEL 9

# Testar com provider legado (se necessário)
openssl md5 -provider legacy file.txt

# Verificar rastreamento certmonger
sudo getcert list

# Ver logs certmonger
sudo journalctl -u certmonger -f

Erros Comuns RHEL 9

11.15 Quando Usar RHEL 9

Ideal Para:

✅ Novas implantações - Começar com segurança moderna ✅ Ambientes focados segurança - Padrões mais rigorosos ✅ Aplicações modernas - Beneficiar de TLS 1.3 ✅ Suporte longo prazo - 10 anos manutenção ✅ Requisitos conformidade - Padrões segurança modernos

Timing Migração:

Do RHEL 7:

• ✅ Sim! Manutenção RHEL 7 terminou junho 2024
• Planejar cuidadosamente - grande salto (testar completamente)

Do RHEL 8:

• Moderado - OpenSSL 3.x é mudança principal
• Testar aplicações customizadas primeiro
• Certificados SHA-1 devem ser reemitidos

11.16 Conclusões Chave

1. Arquitetura provider OpenSSL 3.5.5 - Entender providers
2. Validação mais rigorosa - Captura problemas segurança (bom!)
3. SHA-1 completamente bloqueado - Reemitir certificados antigos
4. Subpolíticas crypto-policy - Ajustar fino segurança
5. certmonger continua valioso para IPA e fluxos de renovação com rastreamento
6. Suporte TLS 1.3 obrigatório - Mais rápido, mais seguro
7. Planejar teste - Apps customizadas podem necessitar atualizações

Referência Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA CERTIFICADO RHEL 9                         │
├──────────────────────────────────────────────────────────────┤
│ OpenSSL:        3.5.5 (arquitetura provider)                 │
│ TLS:            1.2, 1.3 (1.0/1.1 removidos completamente)   │
│ Recurso:        Subpolíticas, validação mais rigorosa        │
│                                                              │
│ Providers:      openssl list -providers                      │
│ Política:       update-crypto-policies --show                │
│ Subpolítica:    update-crypto-policies --set DEFAULT:NO-SHA1 │
│                                                              │
│ Gerar chave:    openssl genpkey -algorithm RSA -out key.pem  │
│ Chave 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 legado:    openssl md5 -provider legacy file.txt        │
└──────────────────────────────────────────────────────────────┘

⚠️ SHA-1 está BLOQUEADO - reemitir certificados antigos!
✅ Usar certmonger para IPA e automação com rastreamento
✅ Política DEFAULT funciona para maioria casos

Navegação do Capítulo

Capítulo 12: Recursos Atuais do RHEL 10

Vanguarda: O RHEL 10 GA foi lançado em 20 de maio de 2025; o RHEL 10.2 é a versão menor atual. Aprenda sobre os recursos mais recentes e prepare-se para o futuro do gerenciamento de certificados no Red Hat Enterprise Linux.

12.1 Visão Geral RHEL 10

Lançamento GA: 20 de maio de 2025 Versão Atual: RHEL 10.2 Suporte Até: 31 de maio de 2035 Status: ✅ Lançamento Produção

Características Chave:

• Versão OpenSSL: 3.5.5-2 (pacote: openssl-3.5.5-2.el10_2.x86_64)
• Mesma base que: RHEL 9.8 (OpenSSL 3.5.5)
• Foco: Fortalecimento contínuo, preparação pós-quântica, cloud-native
• Filosofia: Melhoria incremental sobre RHEL 9

Importante: Recursos RHEL 10 podem evoluir através das versões menores (10.1, 10.2, etc.). Sempre consulte documentação oficial Red Hat para seu lançamento RHEL 10.x específico.

12.2 O Que Há de Novo vs. RHEL 9?

Diferenças Chave

Pacote: openssl-3.5.5-2.el10_2.x86_64

Não É Mudança Revolucionária

Diferente RHEL 7→8 (crypto-policies) ou RHEL 8→9 (OpenSSL 3.x), RHEL 10 é melhoria incremental.

Pense nisso como:

• RHEL 7 → 8: 🚀 Revolucionário (crypto-policies)
• RHEL 8 → 9: 🔄 Principal (OpenSSL 3.x)
• RHEL 9 → 10: ⬆️ Incremental (refinamentos)

12.3 Gerenciamento de Certificados no RHEL 10

Mesma Fundação que RHEL 9

#============================================#
# BÁSICOS CERTIFICADO RHEL 10
#============================================#

# Mesma versão OpenSSL que RHEL 9.8
openssl version
# OpenSSL 3.5.5 27 Jan 2026

# Mesmo sistema crypto-policies
update-crypto-policies --show

# Mesmo certmonger
getcert list

# Mesma estrutura diretório
ls -la /etc/pki/tls/

Conclusão: Se você conhece RHEL 9, você conhece certificados RHEL 10!

12.4 Recursos Segurança Aprimorados

Padrões Mais Rigorosos

#============================================#
# APRIMORAMENTOS SEGURANÇA RHEL 10
#============================================#

# 1. Política DEFAULT é mais rigorosa
# - Preferências cipher mais fortes
# - Algoritmos fracos adicionais removidos
# - Validação aprimorada

# 2. Política LEGACY mais restrita
# - Menos algoritmos legados permitidos
# - Mínimos mais fortes mesmo em LEGACY

# 3. Gerenciamento certificado container melhorado
# - Melhor integração com Podman
# - Montagem cert simplificada
# - Gerenciamento secret aprimorado

Preparação Criptografia Pós-Quântica

Fundação para Futuro:

# RHEL 10 prepara para algoritmos pós-quânticos
# (Ainda não padrão, mas infraestrutura pronta)

# Capacidade futura (quando padrões finalizarem):
# - ML-KEM (Module-Lattice Key Encapsulation)
# - ML-DSA (Module-Lattice Digital Signatures)
# - Criptografia híbrida clássica/quântica

# Status atual: Monitorando padrões NIST
# Esperado: Lançamentos menores RHEL 10.x adicionarão suporte PQC

Nota: Criptografia pós-quântica ainda está evoluindo. RHEL 10 fornece fundação, implementação real virá quando padrões forem finalizados.

12.5 Recursos Específicos RHEL 10

Recurso 1: Módulos Crypto-Policy Aprimorados

#============================================#
# MELHORIAS CRYPTO-POLICY RHEL 10
#============================================#

# Controle mais granular
sudo update-crypto-policies --set DEFAULT:NO-SHA1

# Melhor validação
update-crypto-policies --check

# Mensagens erro melhoradas quando políticas conflitam

Recurso 2: Suporte Certificado Container Melhorado

#============================================#
# CONTAINERS COM CERTIFICADOS (RHEL 10)
#============================================#

# Montagem certificado mais fácil no 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

# Gerenciamento secret aprimorado
podman secret create web-cert /etc/pki/tls/certs/web.crt
podman secret create web-key /etc/pki/tls/private/web.key

# Usar secrets em container
podman run -d --secret web-cert --secret web-key nginx

Recurso 3: Modo FIPS Aprimorado

#============================================#
# FIPS NO RHEL 10
#============================================#

# Modo FIPS com provider FIPS OpenSSL 3.x
sudo fips-mode-setup --enable
sudo reboot

# Verificar status FIPS
fips-mode-setup --check

# RHEL 10: Transição para FIPS 140-3
# Atual: Ainda módulos validados FIPS 140-2
# Futuro: Conformidade FIPS 140-3 quando certificação completar

12.6 Migração do RHEL 9

Deveria Atualizar?

Considerações Atualização:

Razões para Atualizar:

• ✅ Quer 10+ anos suporte (até 2035)
• ✅ Necessita últimos aprimoramentos segurança
• ✅ Preparação futura (preparação pós-quântica)
• ✅ Suporte container aprimorado
• ✅ Últimos recursos e melhorias

Razões para Aguardar:

• ⏸️ RHEL 9 suportado até 2032
• ⏸️ Sem recursos urgentes relacionados certificado
• ⏸️ Deixar outros testarem RHEL 10 em produção primeiro
• ⏸️ Quer aguardar RHEL 10.3 ou 10.4

Impacto Certificado: BAIXO

• Mesma base OpenSSL (3.5.5)
• Mesmas ferramentas e comandos
• Mudanças disruptivas mínimas
• Maioria transparente

Processo Migração

#============================================#
# MIGRAÇÃO CERTIFICADO RHEL 9 → RHEL 10
#============================================#

# 1. Pré-migração: Verificar certificados
for cert in /etc/pki/tls/certs/*.crt; do
  openssl x509 -in "$cert" -noout -text | grep "Signature Algorithm"
done
# Todos deveriam mostrar SHA-256+ (sem SHA-1 e MD5)

# 2. Backup
tar czf rhel9-certs-backup-$(date +%Y%m%d).tar.gz \
  /etc/pki/tls/ \
  /etc/pki/ca-trust/source/anchors/

# 3. Executar atualização RHEL
sudo leapp upgrade

# 4. Verificar crypto-policy
update-crypto-policies --show

# 5. Reiniciar serviços
sudo systemctl restart httpd nginx postfix

# 6. Testar certificados
curl -v https://localhost/
openssl s_client -connect localhost:443

# 7. Verificar certmonger
sudo getcert list

12.7 Melhores Práticas para RHEL 10

Configuração Recomendado

#============================================#
# CONFIGURAÇÃO RECOMENDADA RHEL 10
#============================================#

# 1. Usar crypto-policy DEFAULT (já ótima)
sudo update-crypto-policies --set DEFAULT

# 2. Preferir TLS 1.3
# (Automaticamente preferido pela política DEFAULT)

# 3. Usar chaves EC para novos certificados
openssl genpkey -algorithm EC -out ec.key \
  -pkeyopt ec_paramgen_curve:P-256

# 4. Automatizar com a ferramenta certa
# Certificado público do Let's Encrypt: usar certbot
sudo certbot certonly --apache -d web.example.com

# Certificado interno do 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. Monitorar certificados
# Usar monitoramento integrado ou ferramentas externas

# 6. Planejar para PQC futuro
# Acompanhar lançamentos menores RHEL 10.x

12.8 Olhando Para Frente: Prontidão Pós-Quântica

O Que é Criptografia Pós-Quântica?

Problema: Computadores quânticos futuros poderiam quebrar criptografia atual (RSA, ECC) Solução: Novos algoritmos resistentes quânticos

Padrões NIST (Finalizados 2024):

• ML-KEM-768 (Key Encapsulation)
• ML-DSA-65 (Digital Signatures)
• SLH-DSA (Stateless signatures)

Papel RHEL 10:

• Fornece fundação para PQC
• Arquitetura OpenSSL 3.x suporta novos algoritmos
• Lançamentos futuros RHEL 10.x adicionarão suporte PQC

Criptografia Híbrida (Futuro)

# Capacidade futura no RHEL 10.x:
# Usar crypto clássica E resistente quântica

# Exemplo (conceitual - ainda não no RHEL 10.2):
openssl genpkey -algorithm hybrid-rsa-mlkem768 -out hybrid.key

# Fornece:
# - Segurança contra ataques clássicos (RSA)
# - Segurança contra ataques quânticos (ML-KEM)

Nota: Suporte PQC vem em versões menores futuras RHEL 10.x quando padrões forem finalizados e testados.

12.9 O Que Permanece Igual

Sem Mudanças Disruptivas Principais

#============================================#
# COMANDOS FAMILIARES AINDA FUNCIONAM
#============================================#

# Gerar chave (mesmo que RHEL 9)
openssl genpkey -algorithm RSA -out server.key \
  -pkeyopt rsa_keygen_bits:2048

# Gerar CSR (mesmo 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 (mesmo)
openssl x509 -in cert.crt -noout -text

# Testar conexão (mesmo)
openssl s_client -connect server:443

# Gerenciamento trust (mesmo)
sudo cp ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# certmonger (mesmo)
sudo getcert list

# crypto-policies (mesmo)
update-crypto-policies --show

Se você conhece RHEL 9, está pronto para RHEL 10!

12.10 Quando Adotar RHEL 10

Recomendações Timeline Adoção

Adotantes Iniciais (2025-2026):

• Ambientes teste
• Cargas trabalho não-críticas
• Querem recursos mais recentes
• Pesquisa segurança

Adoção generalizada (2026-2027):

• Novas implantações
• Infraestrutura renovada
• Após lançamento RHEL 10.3/10.4
• Quando apps principais certificados

Conservador (2027-2028):

• Sistemas produção críticos
• Cargas trabalho estáveis
• Após teste comunidade extensivo
• Quando migração do RHEL 9 necessária

Recomendação Atual (Final 2025):

• ✅ Novos projetos: Considere RHEL 10
• ⏸️ RHEL 9 existente: Sem urgência atualizar
• ✅ RHEL 8 ou anterior: Avaliar RHEL 9 ou 10
• ❌ RHEL 7: Atualização requerida (suporte terminou)

12.11 Monitorando Evolução RHEL 10

Manter-se Atualizado

# Verificar versão menor RHEL 10
cat /etc/redhat-release
# Red Hat Enterprise Linux release 10.2 (Coughlan)

# Verificar por atualizações
sudo dnf check-update

# Monitorar anúncios Red Hat
# - https://access.redhat.com/articles/3078
# - Notas lançamento RHEL 10
# - Avisos segurança Red Hat

# Subscrever newsletters Red Hat
# Seguir notas lançamento para 10.3, 10.4, etc.

Recursos a Observar

Esperado em lançamentos menores RHEL 10.x:

• Suporte criptografia pós-quântica
• Aprimoramentos crypto-policy adicionais
• Integração container adicional
• Ferramentas automatização aprimoradas
• Módulos FIPS 140-3 adicionais

12.12 Configuração Prática de Certificado RHEL 10

Exemplo Completo: Configuração HTTPS Moderna

#!/bin/bash
# Configuração HTTPS moderna completa no RHEL 10

echo "=== Configuração HTTPS moderna RHEL 10 ==="

# 1. Instalar pacotes
sudo dnf install -y httpd mod_ssl epel-release certbot python3-certbot-apache

# 2. Habilitar serviços
sudo systemctl enable --now httpd

# 3. Solicitar certificado Let's Encrypt com certbot
sudo certbot --apache -d $(hostname -f)

# 4. Verificar o certificado
sudo certbot certificates

# 5. Atualizar configuração Apache
# certbot normalmente atualiza o Apache automaticamente; ajuste manualmente apenas se necessário
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 já ótima (DEFAULT)
update-crypto-policies --show

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

# 8. Recarregar Apache
sudo systemctl reload httpd

# 9. Testar
curl -v https://$(hostname -f)/

echo "✅ Configuração HTTPS moderna RHEL 10 concluída!"
echo "   - TLS 1.3 suportado"
echo "   - Certificado Let's Encrypt"
echo "   - Renovação automática habilitada"
echo "   - Segurança ótima (política DEFAULT)"

12.13 Estratégias Preparação Futura

Preparando para Evolução RHEL 10.x

#============================================#
# GERENCIAMENTO CERTIFICADO PREPARADO FUTURO
#============================================#

# 1. Usar algoritmos modernos (pronto para transição PQC)
# Preferir EC sobre RSA
openssl genpkey -algorithm EC -out ec.key -pkeyopt ec_paramgen_curve:P-256

# 2. Manter certificados vida-curta (90 dias ou menos)
# Mais fácil rotacionar quando algoritmos mudam

# 3. Automatizar tudo
# Usar certbot para ACME público e certmonger para fluxos IPA/internos

# 4. Monitorar anúncios Red Hat
# Subscrever notificações segurança e lançamento

# 5. Testar PQC quando disponível
# Ser testador inicial novos recursos no RHEL 10.x

# 6. Documentar seu setup
# Torna transições futuras mais fáceis

12.14 Problemas Conhecidos e Workarounds

Problema 1: Mesmo que RHEL 9 (OpenSSL 3.x)

Maioria problemas RHEL 9 aplicam ao RHEL 10:

• Algoritmos legados necessitam -provider legacy
• SHA-1 bloqueado
• Apps customizadas podem necessitar atualizações OpenSSL 3.x

Referência: Ver Capítulo 11 para problemas OpenSSL 3.x

Problema 2: Validação Ainda Mais Rigorosa

RHEL 10 pode capturar problemas que RHEL 9 permitiu:

# Exemplo: Certificado marginal que funcionou no RHEL 9
# pode falhar no RHEL 10

# Solução: Sempre usar melhores práticas
# - Assinaturas SHA-256+
# - Chaves 2048+ bits (4096 recomendado)
# - SANs apropriados
# - Cadeias trust válidas

12.15 Quando Escolher RHEL 10

Matriz Decisão

12.16 Conclusões Chave

1. RHEL 10 = RHEL 9 + melhorias incrementais
2. Mesma base OpenSSL 3.5.5 - Sem mudanças API principais
3. Padrões segurança mais rigorosos - Bom para segurança
4. Preparação pós-quântica - Infraestrutura pronta futuro
5. Sem mudanças certificado urgentes - Transição é suave
6. Conhecimento RHEL 9 transfere - Mesmas ferramentas e comandos
7. Observar por lançamentos menores - 10.3, 10.4 podem adicionar recursos

12.17 Solução de Problemas RHEL 10

Abordagem Diagnóstico

#============================================#
# SOLUÇÃO DE PROBLEMAS CERTIFICADO RHEL 10
#============================================#

# Usar a metodologia de solução de problemas (Capítulo 27) e os padrões do RHEL 9 (Capítulo 11)

# 1. Verificar versão 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. Testar certificado
openssl x509 -in cert.crt -noout -text

# 5. Testar conexão
openssl s_client -connect server:443 -tls1_3

# 6. Verificar providers (se problemas)
openssl list -providers

# 7. Verificar logs
sudo journalctl -xe | grep -i cert

Sem novas técnicas de solução de problemas necessárias - mesmo que RHEL 9!

12.18 Caminho Migração Recomendado

Do RHEL 9 para RHEL 10

#============================================#
# MIGRAÇÃO RHEL 9→10 SEGURA CERTIFICADO
#============================================#

# Fase 1: Preparação
# - Backup todos certificados
# - Documentar configuração atual
# - Testar em ambiente lab

# Fase 2: Migração
# - Usar processo atualização RHEL padrão
# - Certificados deveriam transferir sem problemas

# Fase 3: Verificação
# - Verificar crypto-policy inalterada
# - Testar todas operações certificado
# - Confirmar rastreamento certmonger mantido
# - Testar serviços usando certificados

# Fase 4: Otimização
# - Considerar chaves EC para novos certificados
# - Revisar e atualizar crypto-policy se necessário
# - Monitorar por aprimoramentos RHEL 10.x

12.19 Documentação e Recursos

Recursos Oficiais

## Recursos Certificado RHEL 10

### Documentação Oficial
- Notas Lançamento RHEL 10 (verificar para sua versão 10.x específica)
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/10

### Atualizações Segurança
- https://access.redhat.com/security/
- Subscrever anúncios segurança RHEL

### Crypto-Policies
- https://access.redhat.com/articles/3642912
- Verificar por atualizações específicas RHEL 10

### Suporte
- Portal Cliente Red Hat
- Casos Suporte Red Hat
- Fóruns comunidade RHEL

12.20 Referência Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA CERTIFICADO RHEL 10                        │
├──────────────────────────────────────────────────────────────┤
│ OpenSSL:       3.5.5-2 (mesmo que RHEL 9.8)                  │
│ TLS:           1.3 preferido, 1.2 suportado                  │
│ Lançado:       20 de maio de 2025 (RHEL 10.0 GA)             │
│ Status:        Pronto produção                               │
│                                                              │
│ Mudança Chave: Melhorias segurança incrementais              │
│ Migração:      Baixo impacto do RHEL 9                       │
│ Comandos:      Mesmos que RHEL 9                             │
│ Ferramentas:   Mesmas que RHEL 9                             │
│                                                              │
│ Futuro:        Preparação crypto pós-quântica                │
│                Observar por recursos em 10.3, 10.4+          │
│                                                              │
│ Verificar:     cat /etc/redhat-release                       │
│                openssl version                               │
│                update-crypto-policies --show                 │
└──────────────────────────────────────────────────────────────┘

✅ Se você conhece certificados RHEL 9, você conhece RHEL 10!
⚠️ Sempre verificar docs oficiais para sua versão menor 10.x específica

Navegação do Capítulo

Capítulo 13: Compatibilidade Entre Versões

Desafio Mundo Real: Seu ambiente provavelmente tem sistemas RHEL 7, 8 e 9 todos conversando entre si. Como você faz certificados funcionarem em todas versões?

13.1 A Realidade do Ambiente Misto

Maioria empresas não atualizam tudo de uma vez. Você encontrará:

Ambiente Produção (Típico):
├── Servidor App Legado (RHEL 7)
├── Servidor Banco Dados (RHEL 8)
├── Camada Web (RHEL 9)
├── Nó Gerenciamento (RHEL 10)
└── Clientes: Windows, Mac, Linux, Mobile

Desafio: Estes sistemas têm diferentes:

• Suporte versão TLS
• Suites cifra
• Regras validação certificado
• Versões OpenSSL
• Crypto-policies (ou falta delas)

13.2 Problemas Comuns de Compatibilidade

Problema 1: Desajustes Versão TLS

Cenário: Servidor RHEL 9 (apenas TLS 1.2+) ← Cliente RHEL 7 (TLS 1.0/1.1 padrão)

# Cliente RHEL 7 tentando conectar servidor RHEL 9
curl https://rhel9-server.example.com/
# Erro: SSL routines:ssl3_get_record:wrong version number

# Por quê: RHEL 7 tenta TLS 1.0 primeiro, RHEL 9 rejeita

Solução:

# Opção 1: Atualizar cliente RHEL 7 para usar TLS 1.2
# Editar /etc/httpd/conf.d/ssl.conf (se cliente Apache)
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

# Opção 2: Política LEGACY temporária no RHEL 9 (NÃO recomendado)
# sudo update-crypto-policies --set LEGACY  # No servidor RHEL 9

# Opção 3: Melhor - Atualizar sistemas RHEL 7!

Problema 2: Desajustes Suite Cifra

Cenário: Servidor moderno não suporta cifras cliente antigo

# Cliente RHEL 7 → Servidor RHEL 9
openssl s_client -connect rhel9-server:443 -cipher '3DES'
# Erro: no shared cipher

Por quê: 3DES é bloqueado em política DEFAULT RHEL 8+

Solução:

# Verificar quais cifras estão disponíveis
openssl ciphers -v 'HIGH:!aNULL:!MD5' | head

# Testar cipher específico no cliente
openssl s_client -connect server:443 -cipher 'AES256-GCM-SHA384'

# No servidor RHEL 9, se você DEVE suportar clientes antigos:
sudo update-crypto-policies --set LEGACY  # Temporário!

Problema 3: Diferenças Validação Certificado

Cenário: Certificado assinado SHA-1

Certificado com assinatura SHA-1:
├── ✅ Funciona no RHEL 7
├── ❌ Rejeitado por RHEL 8 DEFAULT
├── ❌ Rejeitado por RHEL 9
└── ❌ Rejeitado por RHEL 10

Solução:

# Reemitir certificado com SHA-256 ou melhor
openssl req -new -key server.key -out server.csr -sha256

# Verificar algoritmo assinatura
openssl x509 -in cert.crt -noout -text | grep "Signature Algorithm"
# Deveria mostrar: sha256WithRSAEncryption (ou melhor)

13.3 Matriz Compatibilidade

Compatibilidade Cliente → Servidor

Legenda:

• ✅ Funciona sem mudanças
• ⚠️ Funciona com mudanças configuração
• ❌ Incompatível sem atualizações principais

13.4 Requisitos de Certificado para Máxima Compatibilidade

O Perfil Certificado “Universal”

Para funcionar em todas versões RHEL (7-10) e clientes externos:

# Requisitos Certificado:
✅ Chave RSA: 2048 bits mínimo (4096 para preparação futura)
✅ Assinatura: SHA-256 ou melhor (não SHA-1!)
✅ Subject Alternative Names (SANs) requeridos
✅ Validade: ≤ 365 dias (requisito navegador)
✅ Key Usage: Extensões apropriadas definidas

❌ Evitar: Assinaturas SHA-1
❌ Evitar: RSA < 2048 bits
❌ Evitar: SANs faltando
❌ Evitar: Certificados apenas-CN

Gerar Certificado Compatível

#============================================#
# PASSO 1: Gerar Chave (funciona em todas versões RHEL)
#============================================#

# RSA 2048 (mínimo, compatível)
openssl genpkey -algorithm RSA -out universal.key -pkeyopt rsa_keygen_bits:2048

# Ou RSA 4096 (melhor, ainda compatível)
openssl genpkey -algorithm RSA -out universal.key -pkeyopt rsa_keygen_bits:4096


#============================================#
# PASSO 2: Criar CSR com 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"


#============================================#
# PASSO 3: Verificar CSR
#============================================#

openssl req -in universal.csr -noout -text | grep -A2 "Subject Alternative Name"
# Deveria mostrar seus SANs

openssl req -in universal.csr -noout -text | grep "Public-Key"
# Deveria mostrar: Public-Key: (2048 bit) ou maior

13.5 Testando Compatibilidade Entre Versões

Script Suite Teste

#!/bin/bash
# test-cert-compatibility.sh
# Testa se certificado funciona de várias versões RHEL

SERVER_HOST="server.example.com"
SERVER_PORT="443"
CERT_FILE="/etc/pki/tls/certs/server.crt"

echo "=== Suite Teste Compatibilidade Certificado ==="
echo ""

#============================================#
# TESTE 1: Propriedades Certificado
#============================================#

echo "1. Propriedades Certificado:"
echo "   Algoritmo Assinatura:"
openssl x509 -in "$CERT_FILE" -noout -text | grep "Signature Algorithm" | head -1

echo "   Tamanho Chave:"
openssl x509 -in "$CERT_FILE" -noout -text | grep "Public-Key"

echo "   SANs:"
openssl x509 -in "$CERT_FILE" -noout -ext subjectAltName 2>/dev/null || echo "   Nenhum SAN encontrado!"

echo ""


#============================================#
# TESTE 2: Suporte Versão TLS
#============================================#

echo "2. Suporte Versão 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//_/.}: ✅ Suportado"
  else
    echo "   ${version//_/.}: ❌ Não suportado"
  fi
done

echo ""


#============================================#
# TESTE 3: Compatibilidade Suite Cifra
#============================================#

echo "3. Testes Cipher Comuns:"

# Cipher 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 "   Cipher moderno (ECDHE-RSA-AES256-GCM-SHA384): ✅"
else
  echo "   Cipher moderno: ❌"
fi

# Cipher legado (RHEL 7)
if openssl s_client -connect "$SERVER_HOST:$SERVER_PORT" -cipher 'AES256-SHA' </dev/null 2>&1 | grep -q "Cipher"; then
  echo "   Cipher legado (AES256-SHA): ✅ (pode indicar política LEGACY)"
else
  echo "   Cipher legado: ❌ (bom para segurança)"
fi


#============================================#
# TESTE 4: Validação Certificado
#============================================#

echo ""
echo "4. Validação Certificado:"

if openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt "$CERT_FILE" | grep -q "OK"; then
  echo "   Cadeia trust: ✅ Válida"
else
  echo "   Cadeia trust: ❌ Inválida"
fi

echo ""
echo "=== Teste Completo ==="

Uso:

chmod +x test-cert-compatibility.sh
sudo ./test-cert-compatibility.sh

13.6 Lidando com Cenários Compatibilidade Específicos

Cenário 1: Cliente RHEL 7 → Servidor RHEL 9

Problema: Conexão falha com erro versão TLS

Correção Lado Cliente (RHEL 7):

# Para curl
curl --tlsv1.2 https://rhel9-server/

# Para wget
wget --secure-protocol=TLSv1_2 https://rhel9-server/

# Para aplicações usando OpenSSL, definir variável ambiente
export OPENSSL_CONF=/etc/pki/tls/openssl-tls12.cnf

# Criar config customizada
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

Correção Lado Servidor (RHEL 9) - NÃO RECOMENDADO:

# Apenas se absolutamente necessário e temporariamente!
sudo update-crypto-policies --set LEGACY
sudo systemctl restart httpd  # Ou seu serviço

Cenário 2: Trust CA Mista

Problema: CA corporativa confiável em alguns sistemas mas não outros

Solução: Repositório de confiança consistente em todas versões

#============================================#
# SCRIPT IMPLANTAÇÃO (executar em todas versões 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"

# Baixar certificado CA
curl -o "$CA_CERT_FILE" "$CA_CERT_URL"

# Atualizar repositório de confiança (funciona em todas versões RHEL)
update-ca-trust extract

# Verificar
if trust list | grep -q "Corporate Root CA"; then
  echo "✅ CA Corporativa instalada com sucesso"
else
  echo "❌ Instalação CA Corporativa falhou"
  exit 1
fi

Cenário 3: Aplicação Usando Biblioteca TLS Antiga

Problema: Aplicação Java 7 não consegue conectar a servidores modernos

Verificar Suporte TLS Java:

# Verificar versão Java
java -version

# Testar suporte TLS
java -Djavax.net.debug=ssl:handshake -jar app.jar 2>&1 | grep "TLS"

Opções:

# Opção 1: Atualizar Java (melhor)
sudo dnf install java-11-openjdk

# Opção 2: Habilitar TLS 1.2 no Java 7 (se atualização impossível)
# Adicionar ao startup Java:
-Dhttps.protocols=TLSv1.2

# Opção 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 Compatibilidade Crypto-Policy

Entendendo Impacto Política Entre Versões

#============================================#
# RHEL 7 (Sem crypto-policies)
#============================================#

# Configuração manual em 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)
#============================================#

# Controle system-wide
update-crypto-policies --set DEFAULT

# Para suportar clientes RHEL 7, pode necessitar:
update-crypto-policies --set LEGACY  # Temporariamente!

Equivalentes Política para Ambientes Mistos

Se você necessita manter compatibilidade:

Opção A: Usar LEGACY em sistemas modernos (não recomendado longo prazo)

# Em servidores RHEL 8/9/10
sudo update-crypto-policies --set LEGACY

Opção B: Configurar RHEL 7 para coincidir DEFAULT (recomendado)

# No RHEL 7, configurar manualmente para coincidir DEFAULT RHEL 8+
# Exemplo Apache:
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!CAMELLIA
SSLHonorCipherOrder on

13.8 Caminho Migração: Atualização Gradual

Fase 1: Preparar RHEL 7 (Pré-Migração)

# 1. Reemitir todos certificados com SHA-256+
# 2. Testar compatibilidade TLS 1.2
# 3. Atualizar configurações cipher
# 4. Documentar inventário certificado atual

Fase 2: Implantar RHEL 8 (Transição)

# 1. Começar com política LEGACY
sudo update-crypto-policies --set LEGACY

# 2. Implantar serviços
# 3. Testar completamente
# 4. Gradualmente mudar para DEFAULT
sudo update-crypto-policies --set DEFAULT

Fase 3: Atualizar para RHEL 9 (Modernização)

# 1. Todos clientes deveriam ser RHEL 8+ ou TLS 1.2 capazes
# 2. Usar política DEFAULT
# 3. Monitorar por problemas compatibilidade
# 4. Considerar política FUTURE após estabilização

13.9 Solução de Problemas Entre Versões

Comandos Diagnóstico

#============================================#
# NO CLIENTE
#============================================#

# Testar versão TLS específica
openssl s_client -connect server:443 -tls1_2

# Testar com saída verbose
curl -v --tlsv1.2 https://server/

# Verificar OpenSSL cliente
openssl version
openssl ciphers -v


#============================================#
# NO SERVIDOR
#============================================#

# Verificar crypto-policy (RHEL 8+)
update-crypto-policies --show

# Verificar config OpenSSL
openssl version
cat /etc/crypto-policies/back-ends/opensslcnf.config

# Testar certificado servidor
openssl s_client -connect localhost:443 -servername $(hostname)

# Verificar logs serviço
sudo journalctl -xe | grep -i tls
sudo tail -f /var/log/httpd/ssl_error_log

Mensagens Erro Comuns

13.10 Melhores Práticas para Ambientes Mistos

1. Padronizar Emissão Certificado

# Padrão Certificado (exemplo)
Algorithm: RSA
Key Size: 2048 bits mínimo (4096 preferido)
Signature: SHA-256 ou melhor
Validity: 365 dias máximo
SANs: Sempre incluir
Extensions: Key usage apropriado definido

2. Manter Repositórios de Confiança Consistentes

# Script implantação para todos 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. Testar Antes de Implantar

# Matriz teste
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 Seu Ambiente

## Matriz Compatibilidade Certificado

### Servidores:
- App Server 1: RHEL 7.9, TLS 1.0-1.2, RSA 2048
- Banco Dados: RHEL 8.10, política DEFAULT, RSA 2048
- Camada Web: RHEL 9.8, política DEFAULT, RSA 4096

### Limitações Conhecidas:
- Sistemas RHEL 7 requerem TLS 1.0/1.1 para app legado X
- Banco dados requer cipher específico: AES256-GCM-SHA384

### Plano Atualização:
- T1 2025: Migrar App Server 1 para RHEL 8
- T2 2025: Atualizar todos certificados para RSA 4096

13.11 Conclusões Chave

1. Ambientes mistos são normais - Planejar para compatibilidade
2. TLS 1.2+ é o mínimo para sistemas modernos
3. Assinaturas SHA-256+ requeridas para RHEL 8+
4. Crypto-policies mudaram tudo (RHEL 8+)
5. Testar em todas versões antes de implantar
6. Documentar tudo - especialmente exceções
7. Caminho atualização é gradual - não apressar, testar completamente

Referência Rápida

┌──────────────────────────────────────────────────────────────┐
│ CHECKLIST COMPATIBILIDADE ENTRE VERSÕES                      │
├──────────────────────────────────────────────────────────────┤
│ ✅ RSA 2048+ bits                                            │
│ ✅ Assinatura SHA-256+                                       │
│ ✅ SANs incluídos                                            │
│ ✅ Suporte TLS 1.2+                                          │
│ ✅ Cifras modernas                                           │
│ ✅ Trust CA consistente                                      │
│ ✅ Testado em todas versões                                  │
└──────────────────────────────────────────────────────────────┘

Comando teste:
openssl s_client -connect server:443 -tls1_2 -servername server

Verificar política (RHEL 8+):
update-crypto-policies --show

Navegação do Capítulo

Capítulo 14: Apache httpd no RHEL

Mais Comum: Apache (httpd) é o servidor web mais amplamente implantado no RHEL. Domine a configuração HTTPS do Apache em todas as versões RHEL.

14.1 Visão Geral Apache no RHEL

Nome do Pacote: httpd Módulo SSL/TLS: mod_ssl Localização Config: /etc/httpd/conf.d/ssl.conf Caminho Certificados: /etc/pki/tls/certs/ Caminho Chaves: /etc/pki/tls/private/

Comparação de Versões

14.2 Instalação

RHEL 7

#============================================#
# INSTALAR APACHE COM 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 COM 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 se escutando na 443

14.3 Configuração Básica SSL

Configuração SSL Padrão

# Arquivo principal de configuração SSL
/etc/httpd/conf.d/ssl.conf

# Diretivas chave:
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

Exemplo Completo de Virtual Host

#============================================#
# /etc/httpd/conf.d/ssl.conf
# Ou /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

    # Arquivos 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 cifra (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 Configuração Específica por Versão

RHEL 7: Configuração SSL Manual

#============================================#
# APACHE SSL - MELHORES PRÁTICAS 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: Desabilitar versões TLS antigas manualmente
    SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

    # REQUERIDO: Apenas cifras fortes
    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

    # Headers segurança
    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: Crypto-Policies Integradas

#============================================#
# APACHE SSL - RHEL 8/9/10 COM 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

    # NÃO PRECISA definir SSLProtocol ou SSLCipherSuite!
    # Crypto-policies lida com isso automaticamente
    # (a menos que você tenha requisitos específicos)

    # Headers segurança (ainda manual)
    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>

Diferença Chave: No RHEL 8+, crypto-policies configuram automaticamente versões TLS e cifras!

Verificando Integração Crypto-Policy

#============================================#
# VERIFICAR CRYPTO-POLICY (RHEL 8/9/10)
#============================================#

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

# Ver política específica Apache
cat /etc/crypto-policies/back-ends/httpd.config

# Apache automaticamente inclui isto
grep -r "crypto-policies" /etc/httpd/

14.5 Geração de Certificado para Apache

Fluxo de Trabalho Completo

#============================================#
# GERAR CERTIFICADO PARA APACHE (TODAS VERSÕES)
#============================================#

# Passo 1: Gerar chave privada
sudo openssl genpkey -algorithm RSA \
  -out /etc/pki/tls/private/www.example.com.key \
  -pkeyopt rsa_keygen_bits:2048

# Passo 2: Definir permissões
sudo chmod 600 /etc/pki/tls/private/www.example.com.key
sudo chown root:root /etc/pki/tls/private/www.example.com.key

# Passo 3: Gerar CSR com 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"

# Passo 4: Submeter CSR para CA, receber certificado

# Passo 5: Instalar certificado
sudo cp www.example.com.crt /etc/pki/tls/certs/
sudo chmod 644 /etc/pki/tls/certs/www.example.com.crt

# Passo 6: Se usando certificados intermediários, instalar cadeia
sudo cp chain.crt /etc/pki/tls/certs/www.example.com-chain.crt

# Passo 7: Atualizar config Apache (ver seção 13.3)

# Passo 8: Testar configuração
sudo apachectl configtest

# Passo 9: Recarregar Apache
sudo systemctl reload httpd

# Passo 10: Testar HTTPS
curl -v https://www.example.com/
openssl s_client -connect www.example.com:443 -servername www.example.com

14.6 Integração certmonger (Automatização!)

Usando certmonger com Apache

#============================================#
# AUTOMATIZAR CERTIFICADOS APACHE COM CERTMONGER
#============================================#

# Instalar certmonger
sudo dnf install certmonger
sudo systemctl enable --now certmonger

# Opção 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-recarregar Apache após renovação!

# Opção 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 status
sudo getcert list

# Aguardar status MONITORING
# Certificado automaticamente renova ~30 dias antes expiração!

Benefícios:

• ✅ Renovação automática
• ✅ Sem downtime (reload, não restart)
• ✅ Rastreia expiração
• ✅ Alertas email em falha

14.7 Let’s Encrypt com certbot

⚠️ IMPORTANTE: EPEL Requerido

certbot NÃO está disponível nos repositórios oficiais RHEL. Requer EPEL (Extra Packages for Enterprise Linux), um repositório mantido pela comunidade.

Para ambientes RHEL produção, considere:

• FreeIPA com certmonger (recomendado para RHEL)
• Gerenciamento certificado manual
• CA comercial com certmonger

#============================================#
# CONFIGURAÇÃO CERTBOT (REQUER EPEL!)
#============================================#

# Passo 1: Habilitar EPEL (TODAS versões RHEL)
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-$(rpm -E %rhel).noarch.rpm

# Ou no RHEL 8/9/10:
sudo dnf install epel-release

# Passo 2: Instalar certbot
sudo dnf install certbot python3-certbot-apache

# Passo 3: Obter certificado (automatizado!)
sudo certbot --apache -d www.example.com -d example.com

# Passo 4: Certbot automaticamente:
#  - Gera certificado
#  - Configura Apache
#  - Configura timer renovação
#  - Habilita redirect HTTPS

# Passo 5: Testar renovação automática
sudo certbot renew --dry-run

# Verificar timer renovação
systemctl list-timers | grep certbot

Prós:

• ✅ Totalmente automatizado
• ✅ Certificados gratuitos
• ✅ Config Apache lidada automaticamente

Contras:

• ❌ Requer EPEL (não oficialmente suportado por Red Hat)
• ❌ Dependência externa (Let’s Encrypt)
• ⚠️ Domínio deve ser publicamente acessível

14.8 Solução de Problemas Apache HTTPS

Lista de Verificação Problemas Comuns

#============================================#
# CHECKLIST SOLUÇÃO DE PROBLEMAS SSL APACHE
#============================================#

# 1. Verificar se mod_ssl está carregado
sudo httpd -M | grep ssl_module
# Deveria mostrar: ssl_module (shared)

# 2. Verificar sintaxe configuração
sudo apachectl configtest
# Deveria mostrar: Syntax OK

# 3. Verificar se arquivos certificado existem
ls -l /etc/pki/tls/certs/www.crt
ls -l /etc/pki/tls/private/www.key

# 4. Verificar permissões
ls -l /etc/pki/tls/private/www.key
# Deveria ser: -rw------- (600)

# 5. Verificar contexto SELinux
ls -Z /etc/pki/tls/certs/www.crt
ls -Z /etc/pki/tls/private/www.key
# Deveria mostrar: cert_t

# 6. Testar coincidência par certificado/chave
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 "❌ Não coincide!"

# 7. Verificar se porta 443 está escutando
ss -tlnp | grep :443

# 8. Verificar firewall
sudo firewall-cmd --list-services | grep https

# 9. Testar localmente
curl -vk https://localhost/

# 10. Verificar logs
sudo tail -f /var/log/httpd/ssl_error_log

Erros Comuns e Soluções

14.9 Solução de Problemas Específico por Versão

Específico RHEL 7

#============================================#
# PROBLEMAS APACHE RHEL 7
#============================================#

# Problema: Navegadores modernos rejeitam TLS 1.0/1.1
# Solução: Desabilitar TLS antigo em ssl.conf
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

# Problema: Cifras fracas marcadas por scan
# Solução: Usar cifras fortes
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5
SSLHonorCipherOrder on

# Problema: Sem SANs no certificado
# Solução: Reemitir com SANs (ver 13.5)

# Testar
openssl s_client -connect localhost:443 -tls1_2

Específico RHEL 8/9/10

#============================================#
# PROBLEMAS APACHE RHEL 8/9/10
#============================================#

# Problema: Serviço falha após mudança crypto-policy
# Diagnóstico:
update-crypto-policies --show
sudo journalctl -xe -u httpd | grep -i tls

# Solução 1: Verificar se política está correta
sudo update-crypto-policies --set DEFAULT

# Solução 2: Verificar se você manualmente sobrescreve política
grep -E "SSLProtocol|SSLCipherSuite" /etc/httpd/conf.d/*.conf
# Se encontrado, remover (deixar crypto-policy lidar com isso)

# Problema: Erro "no shared cipher"
# Diagnóstico: Cliente muito antigo ou política muito restritiva
# Solução temporária:
sudo update-crypto-policies --set LEGACY
sudo systemctl restart httpd

# Solução apropriada: Atualizar cliente ou criar módulo política customizado

14.10 Melhores Práticas de Segurança

Configuração SSL Apache Fortalecida

#============================================#
# CONFIG SSL FORTALECIDA (TODAS VERSÕES)
#============================================#

<VirtualHost *:443>
    ServerName secure.example.com

    SSLEngine on
    SSLCertificateFile      /etc/pki/tls/certs/secure.crt
    SSLCertificateKeyFile   /etc/pki/tls/private/secure.key

    # RHEL 7: Config 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 lidam com acima automaticamente

    # HSTS (forçar HTTPS por 1 ano)
    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"

    # Desabilitar assinatura servidor
    ServerSignature Off
    ServerTokens Prod

    # OCSP Stapling (RHEL 8/9/10)
    SSLUseStapling on
    SSLStaplingCache "shmcb:/var/run/ocsp(128000)"

    # Auth certificado cliente (opcional)
    # SSLVerifyClient require
    # SSLVerifyDepth 3
    # SSLCACertificateFile /etc/pki/tls/certs/client-ca.crt
</VirtualHost>

# Fora VirtualHost (configurações SSL globais)
SSLStaplingCache "shmcb:/var/run/ocsp(128000)"

14.11 Redirect HTTP para HTTPS

Forçar HTTPS

#============================================#
# REDIRECT 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
    # ... config 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 Testando Apache HTTPS

Teste Abrangente

#============================================#
# SUITE TESTE APACHE HTTPS
#============================================#

# Teste 1: Sintaxe configuração
sudo apachectl configtest

# Teste 2: Módulo SSL carregado
sudo httpd -M | grep ssl

# Teste 3: Porta escutando
ss -tlnp | grep :443

# Teste 4: Conexão local
curl -vk https://localhost/

# Teste 5: Hostname real
curl -v https://www.example.com/

# Teste 6: Validação certificado
openssl s_client -connect www.example.com:443 -servername www.example.com

# Teste 7: TLS 1.2
openssl s_client -connect www.example.com:443 -tls1_2

# Teste 8: TLS 1.3 (RHEL 8+)
openssl s_client -connect www.example.com:443 -tls1_3

# Teste 9: Verificar detalhes certificado do servidor
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>&1 | \
  openssl x509 -noout -text | head -30

# Teste 10: Teste online (externo)
# Usar: https://www.ssllabs.com/ssltest/

14.13 Otimização de Desempenho

Ajuste Desempenho SSL/TLS

#============================================#
# AJUSTE DESEMPENHO
#============================================#

<VirtualHost *:443>
    # ... config básica ...

    # Cache de sessão (melhora desempenho)
    SSLSessionCache         "shmcb:/var/cache/httpd/ssl_scache(512000)"
    SSLSessionCacheTimeout  300

    # OCSP Stapling (reduz lookup lado cliente)
    SSLUseStapling on
    SSLStaplingCache "shmcb:/var/run/ocsp(128000)"

    # Keep-Alive (reusar conexões)
    KeepAlive On
    MaxKeepAliveRequests 100
    KeepAliveTimeout 5

    # HTTP/2 (RHEL 8/9/10)
    Protocols h2 h2c http/1.1
</VirtualHost>

14.14 Monitorando Apache HTTPS

O Que Monitorar

#============================================#
# MONITORAMENTO APACHE HTTPS
#============================================#

# Expiração certificado
openssl s_client -connect localhost:443 -servername $(hostname -f) 2>/dev/null | \
  openssl x509 -noout -dates

# Status serviço
systemctl status httpd

# Contagem conexões
ss -tn | grep :443 | wc -l

# Monitoramento log erro
sudo tail -f /var/log/httpd/ssl_error_log

# Status certmonger (se usado)
sudo getcert list -f /etc/pki/tls/certs/www.crt

# Análise log acesso
sudo tail -f /var/log/httpd/ssl_access_log | grep -E "HTTP/[12]"

14.15 Guia Rápido de Solução de Problemas

Apache HTTPS Não Funcionando?

├─ Apache não inicia?
│  ├─ Verificar: apachectl configtest
│  ├─ Verificar: journalctl -xe -u httpd
│  └─ Corrigir: Erros configuração
│
├─ Não consegue conectar à porta 443?
│  ├─ Verificar: ss -tlnp | grep :443
│  ├─ Verificar: firewall-cmd --list-services
│  └─ Corrigir: Abrir firewall, iniciar httpd
│
├─ Avisos certificado no navegador?
│  ├─ Verificar: Expiração certificado
│  ├─ Verificar: Coincidência hostname (CN/SANs)
│  ├─ Verificar: Cadeia confiança
│  └─ Corrigir: Renovar cert, corrigir SANs, instalar CA
│
├─ Erro "No shared cipher"?
│  ├─ Verificar: update-crypto-policies --show
│  ├─ Verificar: Versão TLS cliente
│  └─ Corrigir: Atualizar política ou cliente
│
└─ Erros permissão?
   ├─ Verificar: ls -lZ /etc/pki/tls/private/*.key
   ├─ Verificar: Negações SELinux
   └─ Corrigir: chmod 600, restorecon

14.16 Conclusões Chave

1. Apache + mod_ssl é o servidor web padrão RHEL
2. RHEL 7: Configuração TLS manual requerida
3. RHEL 8/9/10: Crypto-policies simplificam configuração
4. Integração certmonger habilita automatização
5. certbot requer EPEL (não oficialmente suportado)
6. Sempre usar SANs em certificados
7. Testar completamente antes de implantação em produção

Cartão de Referência Rápida

┌─────────────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA APACHE HTTPD HTTPS                                │
├─────────────────────────────────────────────────────────────────────┤
│ Instalar:       dnf install httpd mod_ssl                           │
│ Config:         /etc/httpd/conf.d/ssl.conf                          │
│ Certs:          /etc/pki/tls/certs/                                 │
│ Chaves:         /etc/pki/tls/private/ (modo 600!)                   │
│                                                                     │
│ Testar config:  apachectl configtest                                │
│ Recarregar:     systemctl reload httpd                              │
│ Logs:           /var/log/httpd/ssl_error_log                        │
│                                                                     │
│ certmonger:     ipa-getcert request ... -C "systemctl reload httpd" │
│ certbot:        certbot --apache (requer EPEL!)                     │
│                                                                     │
│ Testar:         curl -v https://localhost/                          │
│                 openssl s_client -connect host:443                  │
└─────────────────────────────────────────────────────────────────────┘

⚠️ RHEL 8/9/10: Deixar crypto-policies lidar com config TLS/cifra
⚠️ certbot requer EPEL (não oficialmente suportado)

🧪 Laboratório Prático

Lab 06: Configuração HTTPS do Apache

Configure Apache com SSL/TLS em diferentes versões RHEL

• 📁 Localização: labs/pt_BR/06-apache-https/
• ⏱️ Tempo: 30-40 minutos
• 🎯 Nível: Intermediário

Navegação do Capítulo

Capítulo 15: NGINX no RHEL

Alto Desempenho: NGINX é um servidor web e proxy reverso de alto desempenho popular. Aprenda como configurar NGINX com certificados TLS no RHEL.

15.1 Visão Geral NGINX no RHEL

Nome do Pacote: nginx Localização Config: /etc/nginx/nginx.conf Caminho Certificados: /etc/pki/tls/certs/ ou /etc/nginx/certs/ Caminho Chaves: /etc/pki/tls/private/ ou /etc/nginx/certs/

Fontes de Instalação por Versão RHEL

Nota: RHEL 7 requer EPEL para NGINX. RHEL 8+ inclui NGINX em repos oficiais.

15.2 Instalação

RHEL 7

#============================================#
# INSTALAR NGINX (RHEL 7 - REQUER EPEL)
#============================================#

# Passo 1: Habilitar EPEL
sudo yum install epel-release -y

# Passo 2: Instalar NGINX
sudo yum install nginx -y

# Passo 3: Habilitar e iniciar
sudo systemctl enable nginx
sudo systemctl start nginx

# Passo 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 - DO APPSTREAM)
#============================================#

# Listar módulos NGINX disponíveis
dnf module list nginx

# Instalar versão específica
sudo dnf module install nginx:1.20 -y

# Ou instalar padrão
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 Configuração Básica HTTPS

Configuração TLS Mínimo

#============================================#
# /etc/nginx/nginx.conf ou /etc/nginx/conf.d/default.conf
#============================================#

server {
    listen 80;
    server_name www.example.com;

    # Redirecionar HTTP para HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name www.example.com;

    # Arquivos 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;

    # Cifras
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    # Diretório raiz
    root /usr/share/nginx/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Configuração Produção Fortalecida

#============================================#
# CONFIG HTTPS NGINX NÍVEL PRODUÇÃO
#============================================#

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;

    # Versões TLS
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cifras fortes
    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;

    # Otimização sessão 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;

    # Headers segurança
    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 Configuração de Certificado

Gerar Certificados para NGINX

#============================================#
# GERAÇÃO CERTIFICADO PARA NGINX
#============================================#

# Passo 1: Criar diretório certs (opcional)
sudo mkdir -p /etc/nginx/certs
sudo chmod 755 /etc/nginx/certs

# Passo 2: Gerar chave privada
sudo openssl genpkey -algorithm RSA \
  -out /etc/pki/tls/private/api.example.com.key \
  -pkeyopt rsa_keygen_bits:2048

# Passo 3: Definir permissões
sudo chmod 600 /etc/pki/tls/private/api.example.com.key
sudo chown root:nginx /etc/pki/tls/private/api.example.com.key

# Passo 4: Gerar 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"

# Passo 5: Submeter para CA, receber certificado

# Passo 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 Integração certmonger

Renovação Automatizada com certmonger

#============================================#
# CERTMONGER + NGINX
#============================================#

# Instalar certmonger
sudo dnf install certmonger
sudo systemctl enable --now certmonger

# Solicitar certificado do 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-recarregar na renovação!

# Ou do 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"

# Monitorar status
sudo getcert list

15.6 Let’s Encrypt com certbot

⚠️ IMPORTANTE: EPEL Requerido

certbot NÃO está disponível nos repositórios oficiais RHEL. Requer EPEL, um repositório mantido pela comunidade.

Instalação: Todas as versões RHEL requerem EPEL, mas o comando de habilitação varia conforme a versão. Consulte o Capítulo 24 para o fluxo completo do certbot.

RHEL 7

# Passo 1: Habilitar EPEL
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y

# Passo 2: Instalar certbot com plugin NGINX
sudo yum install certbot python2-certbot-nginx -y

RHEL 8

# Passo 1: Habilitar EPEL
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y
# Ou, com assinatura ativa:
# sudo dnf install epel-release -y

# Passo 2: Instalar certbot com plugin NGINX
sudo dnf install certbot python3-certbot-nginx -y

RHEL 9/10

# Passo 1: Habilitar EPEL
sudo dnf install epel-release -y

# Passo 2: Instalar certbot com plugin NGINX
sudo dnf install certbot python3-certbot-nginx -y

Obter e configurar o certificado (todas as versões)

# Passo 3: Obter e instalar certificado (automatizado!)
sudo certbot --nginx -d www.example.com -d example.com

# Certbot vai:
#  ✅ Gerar certificado do Let's Encrypt
#  ✅ Atualizar configuração NGINX automaticamente
#  ✅ Configurar redirect HTTP para HTTPS
#  ✅ Configurar auto-renovação

# Passo 4: Verificar timer auto-renovação
systemctl list-timers | grep certbot

# Passo 5: Testar renovação (dry run)
sudo certbot renew --dry-run

# Certificado renova automaticamente a cada 60 dias!

Lembrar: EPEL é suportado pela comunidade, não Red Hat. Para produção empresarial, considere FreeIPA + certmonger.

15.7 Proxy Reverso com TLS

NGINX como Proxy Terminação TLS

#============================================#
# NGINX PROXY REVERSO COM 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;

    # Terminação TLS aqui
    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 para 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 Solução de Problemas NGINX HTTPS

Comandos de Diagnóstico

#============================================#
# SOLUÇÃO DE PROBLEMAS NGINX HTTPS
#============================================#

# Testar sintaxe configuração
sudo nginx -t

# Mostrar configuração completa (com includes)
sudo nginx -T

# Verificar caminhos certificado SSL
sudo nginx -T | grep ssl_certificate

# Verificar arquivo certificado
sudo openssl x509 -in /etc/pki/tls/certs/nginx.crt -noout -text

# Verificar arquivo chave
sudo openssl rsa -in /etc/pki/tls/private/nginx.key -check

# Verificar coincidência par cert/chave
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 se NGINX está escutando na 443
ss -tlnp | grep :443

# Verificar contexto SELinux
ls -Z /etc/pki/tls/certs/nginx.crt
ls -Z /etc/pki/tls/private/nginx.key

# Testar HTTPS localmente
curl -vk https://localhost/

# Verificar logs
sudo tail -f /var/log/nginx/error.log

Erros HTTPS Comuns do NGINX

15.9 Configuração Específica por Versão

RHEL 7: Configuração TLS Manual

#============================================#
# NGINX RHEL 7 - CONFIG 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: Desabilitar manualmente TLS fraco
    ssl_protocols TLSv1.2;  # Sem TLS 1.0/1.1!

    # REQUERIDO: Definir manualmente cifras fortes
    ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5';
    ssl_prefer_server_ciphers on;

    # Headers segurança
    add_header Strict-Transport-Security "max-age=31536000" always;

    root /usr/share/nginx/html;
}

RHEL 8/9/10: Consciente de Crypto-Policies

#============================================#
# NGINX RHEL 8/9/10 - COM 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;

    # Config TLS mínima - crypto-policies lidam com resto!
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    # Ou confiar completamente em crypto-policies:
    # (remover ssl_protocols e ssl_ciphers)
    # NGINX usará crypto-policy do sistema

    # Otimização sessão
    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 Otimização de Desempenho

Ajuste Desempenho SSL/TLS

#============================================#
# OTIMIZAÇÃO DESEMPENHO SSL NGINX
#============================================#

http {
    # Cache sessão SSL (reduz overhead handshake)
    ssl_session_cache shared:SSL:50m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # Tamanhos buffer
    ssl_buffer_size 4k;  # Menor = menor latência, maior = melhor 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 multiplexing
        # (já habilitado na diretiva listen)

        # Habilitar OCSP Stapling (reduz tempo lookup 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últiplos Certificados (SNI)

Server Name Indication (SNI)

#============================================#
# MÚLTIPLOS DOMÍNIOS COM CERTIFICADOS DIFERENTES
#============================================#

# Site 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;
}

# Site 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;
}

# Site 3 (wildcard)
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 Autenticação Certificado Cliente

Mutual TLS (mTLS) com NGINX

#============================================#
# NGINX COM AUTH CERTIFICADO CLIENTE
#============================================#

server {
    listen 443 ssl http2;
    server_name secure.example.com;

    # Certificados servidor
    ssl_certificate     /etc/pki/tls/certs/secure.crt;
    ssl_certificate_key /etc/pki/tls/private/secure.key;

    # Verificação certificado cliente
    ssl_client_certificate /etc/pki/tls/certs/client-ca.crt;
    ssl_verify_client on;  # ou 'optional'
    ssl_verify_depth 3;

    # Passar info cert cliente para 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 Testando NGINX HTTPS

Suite de Teste Abrangente

#============================================#
# TESTE NGINX HTTPS
#============================================#

# Teste 1: Sintaxe configuração
sudo nginx -t
# nginx: configuration file /etc/nginx/nginx.conf test is successful

# Teste 2: Mostrar configuração efetiva
sudo nginx -T | grep -A10 "server_name www.example.com"

# Teste 3: Porta escutando
ss -tlnp | grep nginx

# Teste 4: HTTPS local
curl -vk https://localhost/

# Teste 5: Baseado em hostname
curl -v https://www.example.com/

# Teste 6: Verificar certificado do servidor
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>&1 | \
  openssl x509 -noout -subject -dates

# Teste 7: TLS 1.2
openssl s_client -connect www.example.com:443 -tls1_2

# Teste 8: TLS 1.3 (RHEL 8+)
openssl s_client -connect www.example.com:443 -tls1_3

# Teste 9: Suporte HTTP/2
curl -I --http2 https://www.example.com/

# Teste 10: Headers segurança
curl -I https://www.example.com/ | grep -i "strict-transport"

15.14 Problemas e Soluções Comuns

Problema 1: “Permission denied” na Chave Privada

# Sintoma
sudo nginx -t
# nginx: [emerg] SSL_CTX_use_PrivateKey_file() failed (SSL: error:0200100D:system library:fopen:Permission denied)

# Verificar permissões
ls -l /etc/pki/tls/private/nginx.key

# Corrigir
sudo chmod 600 /etc/pki/tls/private/nginx.key
sudo chown root:nginx /etc/pki/tls/private/nginx.key

# Se problema SELinux:
sudo restorecon -v /etc/pki/tls/private/nginx.key

Problema 2: Cadeia Certificado Não Enviada

# Testar do cliente
openssl s_client -connect www.example.com:443 -showcerts

# Se mostra apenas cert servidor (não intermediários):
# Criar bundle certificado
cat server.crt intermediate.crt > /etc/pki/tls/certs/bundle.crt

# Atualizar config NGINX
ssl_certificate /etc/pki/tls/certs/bundle.crt;

# Recarregar
sudo systemctl reload nginx

Problema 3: OCSP Stapling Não Funcionando

# Testar OCSP stapling
openssl s_client -connect www.example.com:443 -status -tlsextdebug 2>&1 | grep -A17 "OCSP"

# Causas comuns:
# 1. Sem resolver configurado
# Corrigir: Adicionar a nginx.conf:
resolver 8.8.8.8 8.8.4.4 valid=300s;

# 2. Cadeia certificado confiável faltando
# Corrigir:
ssl_trusted_certificate /etc/pki/tls/certs/chain.crt;

# 3. Firewall bloqueia requisições OCSP
# Corrigir: Permitir HTTPS saída

15.15 Melhores Práticas de Segurança

Lista de Verificação

✅ Usar apenas TLS 1.2+ (desabilitar 1.0/1.1)
✅ Cifras fortes com forward secrecy (ECDHE)
✅ Habilitar HSTS com max-age longo
✅ Habilitar OCSP Stapling
✅ Usar HTTP/2
✅ Permissões arquivo apropriadas (600 para chaves)
✅ Contextos SELinux corretos
✅ Validade certificado ≤ 90 dias com auto-renovação
✅ Incluir SANs abrangentes
✅ Headers segurança habilitados

15.16 Conclusões Chave

1. NGINX disponível no AppStream (RHEL 8+) ou EPEL (RHEL 7)
2. Crypto-policies simplificam config no RHEL 8/9/10
3. certmonger integra bem com reload automático
4. certbot requer EPEL em todas versões RHEL
5. SNI habilita múltiplos certs no mesmo IP
6. mTLS possível para autenticação cliente
7. Testar completamente - sintaxe, conectividade, segurança

Cartão de Referência Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERÊNCIA 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;          │
│                                                              │
│ Testar:       nginx -t                                       │
│ Recarregar:   systemctl reload nginx                         │
│ Logs:         /var/log/nginx/error.log                       │
│                                                              │
│ certbot:      certbot --nginx (requer EPEL!)                 │
│ certmonger:   ipa-getcert ... -C "systemctl reload nginx"    │
└──────────────────────────────────────────────────────────────┘

⚠️ certbot requer EPEL em todas versões RHEL
✅ Usar certmonger para ambientes empresariais

🧪 Laboratório Prático

Lab 07: Configuração HTTPS do NGINX

Configure NGINX com SSL/TLS e melhores práticas de segurança

• 📁 Localização: labs/pt_BR/07-nginx-https/
• ⏱️ Tempo: 30-35 minutos
• 🎯 Nível: Intermediário

Navegação do Capítulo

Capítulo 16: TLS no Servidor de E-mail Postfix

Segurança de Email: Aprenda como configurar criptografia TLS para servidores de email Postfix no RHEL, protegendo comunicações de email com certificados.

16.1 Visão Geral Postfix no RHEL

Nome do Pacote: postfix Localização Config: /etc/postfix/main.cf Caminho Certificados: /etc/pki/tls/certs/ Caminho Chaves: /etc/pki/tls/private/ Portas: 25 (SMTP), 465 (SMTPS), 587 (Submission com STARTTLS)

Por Que TLS para Email?

• ✅ Criptografar email em trânsito (prevenir escuta clandestina)
• ✅ Autenticar servidores de email (prevenir personificação)
• ✅ Cumprir requisitos de conformidade (HIPAA, PCI-DSS)
• ✅ Prevenir spam/phishing (SPF, DKIM, DMARC funcionam melhor com TLS)

16.2 Instalação

Todas Versões RHEL

#============================================#
# INSTALAR POSTFIX
#============================================#

# Instalar Postfix
sudo dnf install postfix -y

# Parar e desabilitar Sendmail (se 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 Configuração TLS Lado Servidor

Receber Email com TLS (SMTPD)

#============================================#
# /etc/postfix/main.cf - TLS SERVIDOR (RECEBENDO)
#============================================#

# Arquivos 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

# Nível de segurança TLS
smtpd_tls_security_level = may  # ou 'encrypt' para requerer TLS

# Logging
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes

# Cache de sessão (desempenho)
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

# Autenticação - apenas 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 lidam com protocolos automaticamente
# (não precisa especificar smtpd_tls_protocols)

Níveis de Segurança Explicados:

16.4 Configuração TLS Lado Cliente

Enviar Email com TLS (SMTP)

#============================================#
# /etc/postfix/main.cf - TLS CLIENTE (ENVIANDO)
#============================================#

# Arquivos 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

# Nível segurança TLS para saída
smtp_tls_security_level = may  # ou 'encrypt' para requerer

# Logging
smtp_tls_loglevel = 1

# Cache sessão
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 lidam com isso

16.5 Configuração Postfix TLS Completo

Exemplo Configuração Completa

#============================================#
# CONFIGURAÇÃO POSTFIX TLS COMPLETA
#============================================#

# 1. Gerar certificado e chave
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. Gerar 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. Obter certificado da CA, instalá-lo
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

# Adicionar configuração TLS (ver seções 16.3 e 16.4)

# 5. Testar configuração
sudo postfix check

# 6. Recarregar Postfix
sudo systemctl reload postfix

# 7. Testar SMTP TLS
openssl s_client -starttls smtp -connect mail.example.com:25

16.6 Configuração SMTPS (Porta 465)

Habilitar Serviço SMTPS

#============================================#
# /etc/postfix/master.cf - HABILITAR SMTPS
#============================================#

# Descomentar ou adicionar serviço SMTPS (porta 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

# Recarregar
sudo systemctl reload postfix

# Verificar
ss -tlnp | grep :465

Testar SMTPS

# Conectar a SMTPS (TLS imediato, sem STARTTLS)
openssl s_client -connect mail.example.com:465

# Deveria mostrar handshake TLS imediatamente

16.7 Porta Submission (587) com STARTTLS

Habilitar Serviço Submission

#============================================#
# /etc/postfix/master.cf - HABILITAR SUBMISSION
#============================================#

# Descomentar ou adicionar serviço submission (porta 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

# Recarregar
sudo systemctl reload postfix

# Verificar
ss -tlnp | grep :587

Testar Porta Submission

# Testar STARTTLS na porta 587
openssl s_client -starttls smtp -connect mail.example.com:587

# Deveria mostrar:
# STARTTLS
# 220 2.0.0 Ready to start TLS

16.8 Integração certmonger

Gerenciamento Automatizado Certificados para Postfix

#============================================#
# CERTMONGER + POSTFIX
#============================================#

# Instalar certmonger
sudo dnf install certmonger
sudo systemctl enable --now certmonger

# Solicitar certificado do 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-recarregar Postfix após renovação

# Verificar status
sudo getcert list

# Postfix automaticamente usa certificado renovado!

16.9 Autenticação Certificado Cliente

Requerer Certificados Cliente (mTLS para SMTP)

#============================================#
# /etc/postfix/main.cf - AUTH CERT CLIENTE
#============================================#

# Certificados servidor (como antes)
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtpd_tls_key_file = /etc/pki/tls/private/mail.key

# Verificação certificado cliente
smtpd_tls_CAfile = /etc/pki/tls/certs/client-ca.crt
smtpd_tls_ask_ccert = yes
smtpd_tls_req_ccert = yes  # Requerer cert cliente

# Mapear certificado para usuário
smtpd_recipient_restrictions =
  permit_tls_clientcerts,
  reject

# Recarregar
sudo postfix reload

Testar com certificado cliente:

openssl s_client -starttls smtp \
  -connect mail.example.com:25 \
  -cert client.crt \
  -key client.key \
  -CAfile ca.crt

16.10 Solução de Problemas Postfix TLS

Comandos de Diagnóstico

#============================================#
# SOLUÇÃO DE PROBLEMAS TLS POSTFIX
#============================================#

# Verificar configuração Postfix
sudo postconf | grep -i tls

# Testar sintaxe configuração
sudo postfix check

# Ver configurações TLS específicas
sudo postconf smtpd_tls_cert_file smtpd_tls_key_file

# Verificar se arquivos certificado existem
ls -l /etc/pki/tls/certs/mail.crt
ls -l /etc/pki/tls/private/mail.key

# Verificar coincidência par cert/chave
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!"

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

# Testar SMTPS (porta 465)
openssl s_client -connect mail.example.com:465

# Verificar logs
sudo tail -f /var/log/maillog | grep -i tls

# Verificar fila Postfix
mailq

# Logging verbose (para solução de problemas)
sudo postconf smtpd_tls_loglevel=2
sudo postfix reload
# Verificar /var/log/maillog para info TLS detalhada

Problemas TLS Comuns do Postfix

16.11 Considerações Específicas por Versão

RHEL 7

#============================================#
# POSTFIX TLS - ESPECÍFICO RHEL 7
#============================================#

# /etc/postfix/main.cf

# DEVE 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

# DEVE especificar manualmente cifras
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high

smtp_tls_mandatory_ciphers = high
smtp_tls_ciphers = high

# Excluir cifras fracas
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 COM CRYPTO-POLICIES
#============================================#

# /etc/postfix/main.cf

# Arquivos 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

# Configurações TLS (crypto-policies lidam com protocolos/cifras!)
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_loglevel = 1

# TLS 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

# Isso é tudo! Muito mais simples que RHEL 7
# crypto-policies configuram automaticamente versões TLS e cifras

Diferença Chave: RHEL 8+ confia em crypto-policies, tornando configuração muito mais simples!

16.12 Testando Postfix TLS

Suite de Teste Abrangente

#============================================#
# TESTE POSTFIX TLS
#============================================#

# Teste 1: STARTTLS na porta 25
openssl s_client -starttls smtp -connect mail.example.com:25

# Procurar por:
# - "250-STARTTLS" nas capacidades servidor
# - Handshake TLS bem-sucedido
# - Detalhes certificado

# Teste 2: SMTPS na porta 465 (TLS direto)
openssl s_client -connect mail.example.com:465

# Teste 3: Porta submission 587 com STARTTLS
openssl s_client -starttls smtp -connect mail.example.com:587

# Teste 4: Verificar certificado do servidor
echo "QUIT" | openssl s_client -starttls smtp -connect mail.example.com:25 2>&1 | \
  openssl x509 -noout -subject -dates

# Teste 5: Enviar email teste
echo "Test email" | mail -s "TLS Test" test@example.com

# Teste 6: Verificar TLS em logs
sudo tail -f /var/log/maillog | grep TLS

# Teste 7: Verificar se TLS está sendo usado
sudo postconf | grep -i tls | grep -i level

16.13 Melhores Práticas de Segurança

Configuração Postfix TLS Fortalecida

#============================================#
# CONFIG POSTFIX TLS FORTALECIDA
#============================================#

# /etc/postfix/main.cf

# TLS Servidor (receber email)
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

# REQUERER TLS para autenticação
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes

# TLS Cliente (enviar email)
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: Desabilitar manualmente protocolos fracos
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# Obrigatório para conexões autenticadas
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# Configurações cifra (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

# Caching sessão
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# Logging aprimorado (temporário para solução de problemas)
smtpd_tls_loglevel = 1
smtp_tls_loglevel = 1

# Desempenho
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

16.14 Dovecot IMAP/POP3 com TLS

Configuração Dovecot

Enquanto este capítulo foca em Postfix (SMTP), Dovecot frequentemente roda junto para IMAP/POP3:

#============================================#
# DOVECOT TLS (/etc/dovecot/conf.d/10-ssl.conf)
#============================================#

# Habilitar SSL
ssl = required

# Arquivos certificado
ssl_cert = </etc/pki/tls/certs/mail.example.com.crt
ssl_key = </etc/pki/tls/private/mail.example.com.key

# CA para verificação cert cliente (opcional)
#ssl_ca = </etc/pki/tls/certs/ca-bundle.crt

# RHEL 8/9/10: crypto-policies lidam com isso

# Protocolos TLS (RHEL 7)
#ssl_min_protocol = TLSv1.2

# Preferências suite cifra
#ssl_cipher_list = HIGH:!aNULL:!MD5

# Recarregar
sudo systemctl reload dovecot

Testar IMAPS:

openssl s_client -connect mail.example.com:993

# Testar POP3S
openssl s_client -connect mail.example.com:995

16.15 Cenários Comuns

Cenário 1: TLS Oportunista (Padrão)

Objetivo: Aceitar conexões criptografadas e não-criptografadas

# /etc/postfix/main.cf
smtpd_tls_security_level = may  # TLS opcional
smtp_tls_security_level = may   # TLS opcional

# Por quê: Compatibilidade máxima
# Desvantagem: Algumas conexões podem não ser criptografadas

Cenário 2: TLS Obrigatório (Alta Segurança)

Objetivo: Rejeitar conexões não-criptografadas

# /etc/postfix/main.cf
smtpd_tls_security_level = encrypt  # REQUERER TLS
smtp_tls_security_level = encrypt   # REQUERER TLS

# Por quê: Segurança máxima
# Desvantagem: Sistemas antigos podem falhar ao conectar

Cenário 3: Certificado Cliente para Relay

Objetivo: Permitir relay apenas com certificado 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

# Apenas clientes com cert válido de client-ca.crt podem fazer relay

16.16 Monitorando Postfix TLS

O Que Monitorar

#============================================#
# MONITORAMENTO POSTFIX TLS
#============================================#

# Verificar uso TLS em logs
sudo grep "TLS connection established" /var/log/maillog | tail -20

# Contar conexões TLS vs não-TLS
sudo grep "connect from" /var/log/maillog | grep -c "TLS"

# Verificar por erros TLS
sudo grep "TLS" /var/log/maillog | grep -i error

# Monitorar expiração certificado
openssl x509 -in /etc/pki/tls/certs/mail.crt -noout -checkend $((86400*30))

# Status certmonger (se usado)
sudo getcert list -f /etc/pki/tls/certs/mail.crt

# Verificar fila por falhas TLS
mailq

Script de Monitoramento

#!/bin/bash
# monitor-postfix-tls.sh

echo "=== Monitoramento Postfix TLS ==="

# Expiração certificado
echo "1. Expiração Certificado:"
openssl x509 -in /etc/pki/tls/certs/mail.crt -noout -enddate

# Conexões TLS hoje
echo ""
echo "2. Conexões TLS Hoje:"
sudo grep "$(date '+%b %e')" /var/log/maillog | grep "TLS connection" | wc -l

# Erros TLS hoje
echo ""
echo "3. Erros TLS Hoje:"
sudo grep "$(date '+%b %e')" /var/log/maillog | grep -i "tls.*error" | tail -5

# Status serviço
echo ""
echo "4. Status Postfix:"
systemctl is-active postfix

# Portas escutando
echo ""
echo "5. Escutando em:"
ss -tlnp | grep master | grep -E ':(25|465|587)'

16.17 Problemas e Soluções Comuns

Problema 1: Certificado Não Confiável por Clientes

Sintoma: Clientes recebem avisos “untrusted certificate”

Diagnóstico:

# Testar cadeia certificado
openssl s_client -starttls smtp -connect mail.example.com:25 -showcerts

# Verificar se certificados intermediários incluídos
sudo postconf smtpd_tls_cert_file
# Deveria incluir cadeia completa ou usar smtpd_tls_chain_files

Solução:

# Opção 1: Incluir cadeia no arquivo certificado
cat server.crt intermediate.crt > /etc/pki/tls/certs/mail-chain.crt

# Atualizar config
sudo postconf -e 'smtpd_tls_cert_file = /etc/pki/tls/certs/mail-chain.crt'
sudo postfix reload

# Opção 2: Usar arquivo cadeia separado (Postfix 3.4+)
sudo postconf -e 'smtpd_tls_chain_files = /etc/pki/tls/certs/chain.crt'

Problema 2: “Permission denied” na Chave Privada

Sintoma: Postfix não inicia, logs mostram erro permissão

Corrigir:

# Definir permissões corretas
sudo chmod 600 /etc/pki/tls/private/mail.key
sudo chown root:postfix /etc/pki/tls/private/mail.key

# Corrigir contexto SELinux
sudo restorecon -v /etc/pki/tls/private/mail.key

# Reiniciar Postfix
sudo systemctl restart postfix

Problema 3: TLS Não Oferecido aos Clientes

Sintoma: STARTTLS não mostrado em resposta EHLO

Diagnóstico:

# Telnet para servidor
telnet mail.example.com 25
# Digitar: EHLO test
# Deveria mostrar: 250-STARTTLS

# Se não mostrado, verificar config
sudo postconf smtpd_tls_security_level
# Deveria ser 'may' ou 'encrypt', não 'none'

Solução:

sudo postconf -e 'smtpd_tls_security_level = may'
sudo postfix reload

16.18 Tabela Comparação Versões

16.19 Script Configuração Rápido

#!/bin/bash
# setup-postfix-tls.sh - Setup Postfix TLS completo

DOMAIN="example.com"
HOSTNAME="mail.$DOMAIN"

echo "=== Setup Postfix TLS para $HOSTNAME ==="

# 1. Instalar Postfix
sudo dnf install -y postfix

# 2. Gerar certificado (ou 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. Gerar autoassinado para teste (substituir com cert apropriado!)
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. Testar
echo "Testando SMTP STARTTLS..."
echo "QUIT" | openssl s_client -starttls smtp -connect localhost:25 2>&1 | grep -E "(CONNECTED|subject=)"

echo "✅ Setup Postfix TLS completo!"
echo "⚠️ Substituir cert autoassinado com certificado apropriado da CA"

16.20 Conclusões Chave

1. Postfix suporta TLS nas portas 25 (STARTTLS), 465 (SMTPS), 587 (Submission)
2. RHEL 7 requer config TLS manual (protocolos, cifras)
3. RHEL 8+ usa crypto-policies (muito mais simples!)
4. Níveis de segurança: none, may, encrypt, dane
5. certmonger funciona ótimo com Postfix
6. Sempre testar com openssl s_client -starttls smtp
7. Monitorar logs para erros TLS

Cartão de Referência Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA POSTFIX TLS                                │
├──────────────────────────────────────────────────────────────┤
│ Config:       /etc/postfix/main.cf                           │
│ Certs:        smtpd_tls_cert_file = /path/to/cert.crt        │
│ Chaves:       smtpd_tls_key_file = /path/to/key.key          │
│ Segurança:    smtpd_tls_security_level = may|encrypt         │
│                                                              │
│ Testar:       openssl s_client -starttls smtp -connect :25   │
│ Recarregar:   postfix reload                                 │
│ Verificar:    postfix check                                  │
│ Logs:         tail -f /var/log/maillog | grep TLS            │
│                                                              │
│ Portas:       25 (SMTP+STARTTLS)                             │
│               465 (SMTPS - TLS direto)                       │
│               587 (Submission com STARTTLS)                  │
│                                                              │
│ certmonger:   ipa-getcert ... -C "postfix reload"            │
└──────────────────────────────────────────────────────────────┘

⚠️ RHEL 7: Config manual protocolo/cifra necessária
✅ RHEL 8/9/10: Crypto-policies lidam com ajustes TLS

🧪 Laboratório Prático

Lab 08: TLS do Postfix

Configure TLS para servidor de email Postfix

• 📁 Localização: labs/pt_BR/08-postfix-tls/
• ⏱️ Tempo: 30 minutos
• 🎯 Nível: Intermediário

Navegação do Capítulo

Capítulo 17: OpenLDAP e Serviços de Diretório

Diretório Empresarial: Aprenda como proteger serviços de diretório OpenLDAP com TLS/SSL no RHEL, protegendo autenticação de usuário e consultas de diretório.

17.1 LDAP vs LDAPS vs STARTTLS

Três Formas de Proteger LDAP

Recomendação: Usar LDAPS (porta 636) para simplicidade e segurança.

17.2 Instalação OpenLDAP

Todas Versões RHEL

#============================================#
# INSTALAR SERVIDOR OPENLDAP
#============================================#

# Instalar servidor OpenLDAP
sudo dnf install openldap-servers openldap-clients -y

# Iniciar e 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 Gerando Certificados para LDAP

Requisitos Certificado

Certificados LDAP devem incluir:

• ✅ CN coincidindo com hostname servidor LDAP
• ✅ SANs com FQDN servidor LDAP
• ✅ Server Authentication key usage
• ✅ Cadeia confiança válida

#============================================#
# GERAR CERTIFICADO SERVIDOR LDAP
#============================================#

# Passo 1: Gerar chave privada
sudo openssl genpkey -algorithm RSA \
  -out /etc/openldap/certs/ldap.key \
  -pkeyopt rsa_keygen_bits:2048

# Passo 2: Definir permissões (importante!)
sudo chmod 600 /etc/openldap/certs/ldap.key
sudo chown ldap:ldap /etc/openldap/certs/ldap.key

# Passo 3: Gerar 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"

# Passo 4: Obter certificado da CA

# Passo 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

# Passo 6: Instalar certificado CA
sudo cp ca.crt /etc/openldap/certs/
sudo chmod 644 /etc/openldap/certs/ca.crt

17.4 Configuração TLS OpenLDAP

Método 1: cn=config (Configuração Dinâmica)

#============================================#
# CONFIGURAR TLS COM cn=config (PREFERIDO)
#============================================#

# Criar arquivo 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 configuração
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 (Legado)

#============================================#
# CONFIGURAR TLS COM slapd.conf (LEGADO)
#============================================#

# 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 versão TLS
TLSProtocolMin          1.2

# Reiniciar
sudo systemctl restart slapd

17.5 Configuração Cliente

Configurar Cliente LDAP para TLS

#============================================#
# /etc/openldap/ldap.conf - CONFIG CLIENTE
#============================================#

# URI servidor (usar ldaps:// para porta 636)
URI ldaps://ldap.example.com

# Certificado CA para validação
TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt

# Verificação certificado
TLS_REQCERT demand  # requerer certificado válido

# RHEL 7: Especificar versão TLS mínima
# TLS_PROTOCOL_MIN 1.2

Testar Conexão Cliente LDAP

#============================================#
# TESTAR CONEXÃO CLIENTE LDAPS
#============================================#

# Testar LDAPS (porta 636)
ldapsearch -H ldaps://ldap.example.com:636 \
  -D "cn=admin,dc=example,dc=com" \
  -W \
  -b "dc=example,dc=com" \
  "(objectClass=*)"

# Testar LDAP com STARTTLS (porta 389)
ldapsearch -H ldap://ldap.example.com:389 -ZZ \
  -D "cn=admin,dc=example,dc=com" \
  -W \
  -b "dc=example,dc=com"

# -ZZ força STARTTLS (falha se indisponível)
# -Z tenta STARTTLS (continua sem se indisponível)

17.6 Integração FreeIPA

Nota: FreeIPA é coberto em detalhes no Capítulo 19. Esta é uma visão geral rápida.

FreeIPA Lida Automaticamente com LDAPS

#============================================#
# LDAPS FREEIPA (AUTOMÁTICO!)
#============================================#

# FreeIPA configura automaticamente LDAPS
# Sem config certificado manual necessária!

# Testar LDAPS 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 FreeIPA gerenciados por certmonger automaticamente
sudo getcert list | grep -A10 "Directory Server"

17.7 Testando OpenLDAP TLS

Teste Abrangente

#============================================#
# TESTE OPENLDAP TLS
#============================================#

# Teste 1: Verificar se slapd está escutando
ss -tlnp | grep slapd
# Deveria mostrar portas 389 e/ou 636

# Teste 2: Testar conexão LDAPS com OpenSSL
openssl s_client -connect ldap.example.com:636

# Procurar por:
# - Handshake TLS bem-sucedido
# - Detalhes certificado
# - Verify return code: 0 (ok)

# Teste 3: Testar com ldapsearch (anônimo)
ldapsearch -H ldaps://ldap.example.com:636 \
  -x -b "" -s base "(objectClass=*)" namingContexts

# Teste 4: Testar consulta autenticada
ldapsearch -H ldaps://ldap.example.com:636 \
  -D "cn=admin,dc=example,dc=com" \
  -W \
  -b "dc=example,dc=com" \
  "(uid=*)"

# Teste 5: Testar STARTTLS
ldapsearch -H ldap://ldap.example.com:389 -ZZ \
  -x -b "" -s base

# Teste 6: Verificar certificado do servidor
echo | openssl s_client -connect ldap.example.com:636 2>&1 | \
  openssl x509 -noout -subject -issuer -dates

17.8 Solução de Problemas OpenLDAP TLS

Comandos de Diagnóstico

#============================================#
# DIAGNÓSTICO OPENLDAP TLS
#============================================#

# Verificar configuração slapd
sudo slapcat -b "cn=config" | grep -i tls

# Verificar arquivos certificado
sudo ls -lZ /etc/openldap/certs/

# Verificar permissões
# Chave deve ser legível pelo usuário 'ldap'
sudo -u ldap cat /etc/openldap/certs/ldap.key >/dev/null && \
  echo "✅ Chave legível" || echo "❌ Permissão negada"

# Verificar contexto SELinux
ls -Z /etc/openldap/certs/*.{crt,key}

# Verificar logs slapd
sudo journalctl -u slapd -f

# Testar com OpenSSL verbose
openssl s_client -connect ldap.example.com:636 -showcerts -debug

# Testar STARTTLS
ldapsearch -H ldap://ldap.example.com:389 -ZZ -d 1

Problemas TLS Comuns do OpenLDAP

17.9 Autenticação Certificado Cliente

Requerer Certificados Cliente

#============================================#
# OPENLDAP COM AUTH CERT CLIENTE
#============================================#

# Configuração 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

Conexão cliente com certificado:

# Cliente deve fornecer certificado
ldapsearch -H ldaps://ldap.example.com:636 \
  -x -b "dc=example,dc=com" \
  -ZZ

# Configurar cert cliente em /etc/openldap/ldap.conf:
TLS_CERT /etc/openldap/certs/client.crt
TLS_KEY /etc/openldap/certs/client.key

17.10 Considerações Específicas por Versão

RHEL 7

#============================================#
# OPENLDAP TLS - RHEL 7
#============================================#

# Especificação protocolo TLS manual
# Em slapd.conf ou cn=config:
TLSProtocolMin 1.2

# Ou com cn=config:
olcTLSProtocolMin: 3.2  # 3.1=TLS1.0, 3.2=TLS1.1, 3.3=TLS1.2

# Configuração cipher manual
TLSCipherSuite HIGH:!aNULL:!MD5:!3DES

# Testar
openssl s_client -connect ldap.example.com:636 -tls1_2

RHEL 8/9/10

#============================================#
# OPENLDAP TLS - RHEL 8/9/10
#============================================#

# Crypto-policies configuram automaticamente TLS
# Sem necessidade especificar TLSProtocolMin ou cifras!

# Apenas configurar certificados:
olcTLSCertificateFile: /etc/openldap/certs/ldap.crt
olcTLSCertificateKeyFile: /etc/openldap/certs/ldap.key
olcTLSCACertificateFile: /etc/openldap/certs/ca.crt

# Crypto-policy lida com resto
update-crypto-policies --show

17.11 certmonger com OpenLDAP

Gerenciamento Certificado Automatizado

#============================================#
# CERTMONGER + OPENLDAP
#============================================#

# Instalar certmonger
sudo dnf install certmonger
sudo systemctl enable --now certmonger

# Solicitar certificado do 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 após renovação

# Definir propriedade apropriada
sudo chown ldap:ldap /etc/openldap/certs/ldap.{crt,key}
sudo chmod 600 /etc/openldap/certs/ldap.key

# Monitorar
sudo getcert list

17.12 Solução de Problemas LDAPS

Passos de Diagnóstico

#============================================#
# SOLUÇÃO DE PROBLEMAS LDAPS
#============================================#

# Passo 1: Verificar se slapd está escutando na 636
ss -tlnp | grep 636

# Passo 2: Verificar configuração certificado
sudo slapcat -b "cn=config" | grep olcTLS

# Passo 3: Testar arquivo certificado
sudo openssl x509 -in /etc/openldap/certs/ldap.crt -noout -text

# Passo 4: Testar arquivo chave
sudo openssl rsa -in /etc/openldap/certs/ldap.key -check

# Passo 5: Verificar coincidência cert/chave
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!"

# Passo 6: Verificar permissões
ls -l /etc/openldap/certs/
# Chave deve ser de propriedade ldap:ldap com modo 600

# Passo 7: Testar conexão
openssl s_client -connect ldap.example.com:636

# Passo 8: Verificar logs
sudo journalctl -u slapd | grep -i tls

# Passo 9: Testar do cliente
ldapsearch -H ldaps://ldap.example.com:636 -x -b "" -s base

# Passo 10: Verificar SELinux
sudo ausearch -m avc -ts recent | grep ldap

17.13 Problemas e Soluções Comuns

Problema 1: Erro “TLS: can’t accept”

Sintoma: Conexão LDAPS recusada

Diagnóstico:

sudo journalctl -u slapd | grep "TLS: can't accept"

Causas e Soluções:

# Causa 1: Chave não legível pelo usuário ldap
sudo chown ldap:ldap /etc/openldap/certs/ldap.key
sudo chmod 600 /etc/openldap/certs/ldap.key

# Causa 2: SELinux bloqueando
sudo restorecon -Rv /etc/openldap/certs/
# Ou verificar negações:
sudo ausearch -m avc -ts recent | grep ldap

# Causa 3: Desajuste certificado/chave
# Regenerar CSR com chave correta

Problema 2: “TLS: hostname does not match”

Sintoma: Cliente recebe erro hostname mismatch

Diagnóstico:

# Verificar CN e SANs certificado
openssl x509 -in /etc/openldap/certs/ldap.crt -noout -subject -ext subjectAltName

Solução:

# Reemitir certificado com hostname correto nos 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"

# Ou no lado cliente: permitir verificação mais frouxa (NÃO recomendado para produção)
# Em /etc/openldap/ldap.conf:
TLS_REQCERT allow  # em vez de 'demand'

Problema 3: Certificado Não Confiável

Sintoma: “Certificate verification failed”

Solução:

# Adicionar CA ao repositório de confiança sistema
sudo cp ldap-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# Ou especificar CA na config cliente
# /etc/openldap/ldap.conf:
TLS_CACERT /etc/openldap/certs/ca.crt

17.14 Melhores Práticas de Segurança

Configuração TLS OpenLDAP Fortalecida

#============================================#
# CONFIG TLS LDAP 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 Integração com Serviços Sistema

SSSD com LDAPS (Autenticação 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

# Testar
id ldapuser@example.com

17.16 Monitorando LDAP TLS

Comandos de Monitoramento

#============================================#
# MONITORAR LDAP TLS
#============================================#

# Verificar expiração certificado
openssl s_client -connect ldap.example.com:636 2>/dev/null | \
  openssl x509 -noout -dates

# Verificar conexões TLS
sudo journalctl -u slapd | grep "TLS established"

# Contar conexões LDAPS vs LDAP
sudo journalctl -u slapd --since today | grep -c "conn=.*LDAPS"
sudo journalctl -u slapd --since today | grep -c "conn=.*LDAP"

# Verificar por erros TLS
sudo journalctl -u slapd | grep -i "tls.*error"

# Status certmonger (se usado)
sudo getcert list -d /etc/openldap/certs

17.17 Conclusões Chave

1. LDAPS (porta 636) é mais simples que STARTTLS
2. Propriedade certificado crítica - Deve ser legível pelo usuário ldap
3. cn=config preferido sobre slapd.conf (RHEL moderno)
4. FreeIPA lida com LDAPS automaticamente - Muito mais fácil!
5. Configuração cliente importa - Definir TLS_CACERT corretamente
6. Testar completamente - Usar openssl s_client e ldapsearch -ZZ
7. certmonger automatiza renovação certificado

Cartão de Referência Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA OPENLDAP TLS                               │
├──────────────────────────────────────────────────────────────┤
│ Config:        cn=config (dinâmica) ou slapd.conf (legado)   │
│ Certs:         /etc/openldap/certs/                          │
│ Propriedade:   chown ldap:ldap *.{crt,key}                   │
│ Permissões:    chmod 600 ldap.key                            │
│                                                              │
│ LDAPS:         Porta 636 (TLS desde início)                  │
│ STARTTLS:      Porta 389 (atualizar para TLS)                │
│                                                              │
│ Testar LDAPS:  openssl s_client -connect host:636            │
│ Testar 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                │
└──────────────────────────────────────────────────────────────┘

⚠️ Chave deve ser de propriedade do usuário 'ldap'!
✅ Usar FreeIPA para gerenciamento LDAP+TLS mais fácil

🧪 Laboratório Prático

Lab 09: LDAPS do OpenLDAP

Configure LDAPS para serviços de diretório seguros

• 📁 Localização: labs/pt_BR/09-openldap-ldaps/
• ⏱️ Tempo: 35-40 minutos
• 🎯 Nível: Intermediário

Navegação do Capítulo

Capítulo 18: TLS em Bancos de Dados (PostgreSQL, MySQL)

Dados em Trânsito: Proteja conexões banco dados com criptografia TLS. Aprenda como configurar PostgreSQL e MySQL/MariaDB com certificados no RHEL.

18.1 Por Que TLS de Banco de Dados?

Proteger Dados Sensíveis:

• ✅ Criptografar consultas e resultados banco dados
• ✅ Prevenir escuta clandestina em credenciais
• ✅ Autenticar servidores banco dados
• ✅ Habilitar autenticação certificado cliente
• ✅ Cumprir requisitos conformidade (PCI-DSS, HIPAA)

Modelo Ameaça:

• Sem TLS: Senhas e dados viajam em cleartext
• Com TLS: Toda comunicação criptografada

18.2 PostgreSQL com SSL/TLS

Instalação

#============================================#
# INSTALAR POSTGRESQL
#============================================#

# RHEL 7/8/9/10
sudo dnf install postgresql-server -y

# Inicializar banco dados
sudo postgresql-setup --initdb

# Habilitar e iniciar
sudo systemctl enable postgresql
sudo systemctl start postgresql

# Verificar
systemctl status postgresql
ss -tlnp | grep 5432

Gerar Certificados PostgreSQL

#============================================#
# GERAR CERTIFICADOS POSTGRESQL
#============================================#

# Passo 1: Gerar chave servidor
sudo -u postgres openssl genpkey -algorithm RSA \
  -out /var/lib/pgsql/data/server.key \
  -pkeyopt rsa_keygen_bits:2048

# Passo 2: Definir permissões (crítico!)
sudo chmod 600 /var/lib/pgsql/data/server.key
sudo chown postgres:postgres /var/lib/pgsql/data/server.key

# Passo 3: Gerar 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"

# Passo 4: Obter certificado da CA

# Passo 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

# Passo 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

# Arquivos certificado (relativos ao diretório data)
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
ssl_ca_file = 'root.crt'

# RHEL 7: Especificar versão TLS mínima
# ssl_min_protocol_version = 'TLSv1.2'

# RHEL 8/9/10: Usa crypto-policy sistema
# (sem necessidade especificar ssl_min_protocol_version)

# Opcional: Preferir cifras servidor
ssl_prefer_server_ciphers = on

# Reiniciar PostgreSQL
sudo systemctl restart postgresql

Configurar Autenticação Cliente

#============================================#
# /var/lib/pgsql/data/pg_hba.conf
#============================================#

# Requerer SSL para todas conexões
hostssl all all 0.0.0.0/0 md5

# Requerer certificado cliente
hostssl all alice 0.0.0.0/0 cert clientcert=verify-full

# Recarregar configuração
sudo systemctl reload postgresql

Tipos HBA:

• host: Permitir não-SSL
• hostssl: Requerer SSL
• hostnossl: Explicitamente proibir SSL

Opções Cert Cliente:

• md5: SSL requerido, auth senha
• cert: SSL + certificado cliente requerido
• clientcert=verify-full: Verificar cert cliente contra CA

Testar PostgreSQL SSL

#============================================#
# TESTAR POSTGRESQL SSL
#============================================#

# Teste 1: Conectar com SSL requerido
psql "host=db.example.com port=5432 user=testuser dbname=testdb sslmode=require"

# Teste 2: Conectar com verificação completa
psql "host=db.example.com port=5432 user=testuser dbname=testdb sslmode=verify-full sslrootcert=/etc/pki/tls/certs/ca-bundle.crt"

# Teste 3: Com certificado 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"

# Teste 4: Verificar SSL de dentro PostgreSQL
psql -h db.example.com -U testuser -d testdb -c "SELECT ssl, version FROM pg_stat_ssl WHERE pid = pg_backend_pid();"

# Teste 5: Teste OpenSSL
openssl s_client -connect db.example.com:5432 -starttls postgres

Modos SSL:

• disable: Sem SSL
• allow: Tentar SSL, fallback para não-SSL
• prefer: Preferir SSL, fallback permitido
• require: Requerer SSL (não verificar cert)
• verify-ca: Requerer SSL, verificar CA
• verify-full: Requerer SSL, verificar hostname + CA

18.3 MySQL/MariaDB com SSL/TLS

Instalação

#============================================#
# INSTALAR MARIADB (SUBSTITUIÇÃO MYSQL NO RHEL 8+)
#============================================#

# RHEL 8/9/10
sudo dnf install mariadb-server -y

# Iniciar e habilitar
sudo systemctl enable mariadb
sudo systemctl start mariadb

# Instalação segura
sudo mysql_secure_installation

# Verificar
systemctl status mariadb
ss -tlnp | grep 3306

Gerar Certificados MySQL/MariaDB

#============================================#
# GERAR CERTIFICADOS MYSQL/MARIADB
#============================================#

# Criar diretório certificado
sudo mkdir -p /etc/mysql/certs
sudo chmod 755 /etc/mysql/certs

# Passo 1: Gerar chave 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

# Passo 2: Gerar 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"

# Passo 3: Obter certificado da CA

# Passo 4: Instalar certificado e 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 (ou /etc/my.cnf)
sudo vi /etc/my.cnf.d/server.cnf

[mysqld]
# Configuração SSL/TLS
ssl-ca=/etc/mysql/certs/ca.crt
ssl-cert=/etc/mysql/certs/server.crt
ssl-key=/etc/mysql/certs/server.key

# Requerer transporte seguro (opcional, força TLS para todos)
require_secure_transport=ON

# RHEL 7: Especificar versão TLS
# tls_version=TLSv1.2,TLSv1.3

# Reiniciar MySQL/MariaDB
sudo systemctl restart mariadb

Verificar SSL Está Habilitado

#============================================#
# VERIFICAR MYSQL SSL
#============================================#

# Conectar e verificar status SSL
mysql -u root -p -e "SHOW VARIABLES LIKE '%ssl%';"

# Deveria 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 conexões ativas
mysql -u root -p -e "SHOW STATUS LIKE 'Ssl_cipher';"

Testar Conexão MySQL SSL

#============================================#
# TESTAR CONEXÃO MYSQL SSL
#============================================#

# Conectar com SSL
mysql --ssl-ca=/etc/mysql/certs/ca.crt \
  --ssl-mode=REQUIRED \
  -h db.example.com \
  -u testuser \
  -p

# Verificar SSL em uso
mysql> \s
# Procurar por: "SSL: Cipher in use is ..."

# Ou verificar de linha comando
mysql -h db.example.com -u testuser -p -e "STATUS" | grep SSL

18.4 Autenticação Certificado Cliente

PostgreSQL com Certificados Cliente

#============================================#
# AUTH CERT CLIENTE POSTGRESQL
#============================================#

# Lado servidor: pg_hba.conf
hostssl all alice 0.0.0.0/0 cert clientcert=verify-full

# Gerar certificado 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"
# Obter assinado por CA

# Conexão cliente
psql "host=db.example.com user=alice dbname=mydb sslmode=verify-full sslcert=alice.crt sslkey=alice.key sslrootcert=ca.crt"

MySQL/MariaDB com Certificados Cliente

#============================================#
# AUTH CERT CLIENTE MYSQL/MARIADB
#============================================#

# Criar usuário requerendo X.509
mysql -u root -p << EOF
CREATE USER 'alice'@'%' REQUIRE X509;
GRANT ALL ON mydb.* TO 'alice'@'%';
FLUSH PRIVILEGES;
EOF

# Conexão cliente
mysql --ssl-ca=ca.crt \
  --ssl-cert=alice.crt \
  --ssl-key=alice.key \
  -h db.example.com \
  -u alice \
  -p mydb

18.5 Solução de Problemas TLS Banco Dados

Solução de Problemas PostgreSQL

#============================================#
# SOLUÇÃO DE PROBLEMAS SSL POSTGRESQL
#============================================#

# Verificar SSL está habilitado
sudo -u postgres psql -c "SHOW ssl;"
# Deveria mostrar: on

# Ver configurações SSL
sudo -u postgres psql -c "SHOW ssl_cert_file; SHOW ssl_key_file; SHOW ssl_ca_file;"

# Verificar arquivos certificado
ls -l /var/lib/pgsql/data/server.{crt,key}

# Verificar propriedade
# Deveria ser: postgres:postgres

# Verificar permissões
# server.key deveria ser 600

# Testar conexão com debugging SSL
psql "host=db.example.com sslmode=require" -d postgres -U testuser --set=sslcompression=on

# Verificar logs PostgreSQL
sudo tail -f /var/lib/pgsql/data/log/postgresql-*.log | grep -i ssl

Solução de Problemas MySQL/MariaDB

#============================================#
# SOLUÇÃO DE PROBLEMAS SSL MYSQL/MARIADB
#============================================#

# Verificar variáveis SSL
mysql -u root -p -e "SHOW VARIABLES LIKE '%ssl%';"

# Se have_ssl = NO, verificar:
# 1. Arquivos certificado existem
ls -l /etc/mysql/certs/

# 2. Permissões
# Deveriam ser legíveis por usuário mysql

# 3. Reiniciar banco dados
sudo systemctl restart mariadb

# Verificar log erro
sudo tail -f /var/log/mariadb/mariadb.log | grep -i ssl

# Testar conexão
mysql --ssl-ca=/etc/mysql/certs/ca.crt \
  --ssl-mode=REQUIRED \
  -h localhost \
  -u root \
  -p \
  -e "STATUS" | grep SSL

18.6 Problemas e Soluções Comuns

Problema 1: PostgreSQL “Permission denied” em server.key

Sintoma: PostgreSQL não inicia, logs mostram erro permissão

Correção:

# Definir permissões corretas
sudo chmod 600 /var/lib/pgsql/data/server.key
sudo chown postgres:postgres /var/lib/pgsql/data/server.key

# Corrigir contexto SELinux
sudo restorecon -Rv /var/lib/pgsql/data/

# Reiniciar
sudo systemctl restart postgresql

Problema 2: MySQL “SSL connection error”

Diagnóstico:

# Verificar se SSL está disponível
mysql -u root -p -e "SHOW VARIABLES LIKE 'have_ssl';"
# Deveria mostrar: YES

# Se mostra: DISABLED
# Verificar caminhos certificado em my.cnf

Correção:

# Verificar caminhos em /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 Cliente Rejeitado

Sintoma: Conexão falha com cert cliente

Correção PostgreSQL:

# Verificar pg_hba.conf
cat /var/lib/pgsql/data/pg_hba.conf | grep hostssl

# Garantir que CA cliente está instalada
sudo cp client-ca.crt /var/lib/pgsql/data/root.crt

# Recarregar
sudo systemctl reload postgresql

Correção MySQL:

# Verificar usuário requer X.509
mysql -u root -p -e "SELECT user, host, ssl_type FROM mysql.user WHERE user='alice';"
# Deveria mostrar: X509

# Verificar arquivo CA configurado
mysql -u root -p -e "SHOW VARIABLES LIKE 'ssl_ca';"

18.7 Considerações Específicas por Versão

Versões PostgreSQL no RHEL

Versões MySQL/MariaDB no RHEL

18.8 Considerações Desempenho

Desempenho SSL PostgreSQL

#============================================#
# AJUSTE DESEMPENHO SSL POSTGRESQL
#============================================#

# /var/lib/pgsql/data/postgresql.conf

# SSL habilitado
ssl = on

# Compressão SSL (desabilitada para segurança, ataque CRIME)
ssl_compression = off

# Cifras SSL (RHEL 7 - manual)
# ssl_ciphers = 'HIGH:!aNULL:!MD5'

# RHEL 8/9/10: crypto-policy lida com cifras

# Connection pooling ajuda (usar pgBouncer)
# Terminação SSL em proxy pode melhorar desempenho

Desempenho SSL MySQL

#============================================#
# DESEMPENHO SSL MYSQL
#============================================#

# [mysqld] em /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

# Desabilitar cifras fracas (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 lida com isso

# Connection pooling (usar ProxySQL ou similar)

18.9 Monitorando TLS Banco Dados

Monitoramento PostgreSQL

#============================================#
# MONITORAR SSL POSTGRESQL
#============================================#

# Verificar conexões 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 não-SSL
sudo -u postgres psql -c "SELECT ssl, COUNT(*) FROM pg_stat_ssl GROUP BY ssl;"

# Verificar expiração certificado
openssl x509 -in /var/lib/pgsql/data/server.crt -noout -checkend $((86400*30))

# Monitorar conexões
sudo -u postgres psql -c "SELECT COUNT(*) FROM pg_stat_activity WHERE ssl = true;"

Monitoramento MySQL

#============================================#
# MONITORAR SSL MYSQL
#============================================#

# Verificar status SSL
mysql -u root -p -e "SHOW STATUS LIKE 'Ssl%';"

# Contar conexões SSL
mysql -u root -p -e "SHOW STATUS LIKE 'Ssl_accepts';"

# Conexões SSL atuais
mysql -u root -p -e "SELECT user, host, connection_type FROM information_schema.processlist WHERE connection_type = 'SSL/TLS';"

# Expiração certificado
openssl x509 -in /etc/mysql/certs/server.crt -noout -checkend $((86400*30))

18.10 Scripts Configuração Completo

Script Configuração SSL PostgreSQL

#!/bin/bash
# setup-postgresql-ssl.sh

echo "=== Setup SSL PostgreSQL ==="

# Gerar cert autoassinado (substituir com cert CA apropriado!)
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)"

# Definir permissões
sudo chmod 600 /var/lib/pgsql/data/server.{crt,key}
sudo chown postgres:postgres /var/lib/pgsql/data/server.{crt,key}

# Habilitar SSL em postgresql.conf
sudo -u postgres psql -c "ALTER SYSTEM SET ssl = on;"

# Reiniciar
sudo systemctl restart postgresql

# Testar
sudo -u postgres psql -c "SHOW ssl;"

echo "✅ PostgreSQL SSL habilitado"
echo "⚠️ Substituir cert autoassinado com certificado apropriado da CA"

18.11 Conclusões Chave

1. Ambos PostgreSQL e MySQL suportam SSL/TLS
2. Propriedade arquivo crítica - postgres:postgres ou mysql:mysql
3. Permissões: 600 para chaves, 644 para certs
4. pg_hba.conf controla acesso PostgreSQL (hostssl)
5. sslmode importante para clientes PostgreSQL
6. Certificados cliente habilitam autenticação forte
7. Testar completamente antes forçar TLS
8. Monitorar uso SSL - Garantir clientes realmente usam

Cartão de Referência Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA TLS BANCO DADOS                            │
├──────────────────────────────────────────────────────────────┤
│ === POSTGRESQL ===                                           │
│ Config:        /var/lib/pgsql/data/postgresql.conf           │
│ Acesso:        /var/lib/pgsql/data/pg_hba.conf               │
│ Certs:         /var/lib/pgsql/data/server.{crt,key}          │
│ Proprietário:  postgres:postgres                             │
│ Habilitar:     ssl = on                                      │
│ Testar:        psql "sslmode=require"                        │
│                                                              │
│ === MYSQL/MARIADB ===                                        │
│ Config:        /etc/my.cnf.d/server.cnf                      │
│ Certs:         /etc/mysql/certs/server.{crt,key}             │
│ Proprietário:  mysql:mysql                                   │
│ Habilitar:     ssl-ca, ssl-cert, ssl-key em [mysqld]         │
│ Testar:        mysql --ssl-mode=REQUIRED                     │
│                                                              │
│ Permissões:    chmod 600 *.key                               │
│                chmod 644 *.crt                               │
└──────────────────────────────────────────────────────────────┘

⚠️ Propriedade e permissões arquivo são críticas!
✅ Usar hostssl em pg_hba.conf para requerer SSL

🧪 Laboratório Prático

Lab 10: TLS do PostgreSQL

Configure TLS para conexões de banco de dados PostgreSQL

• 📁 Localização: labs/pt_BR/10-postgresql-tls/
• ⏱️ Tempo: 25-30 minutos
• 🎯 Nível: Intermediário

Navegação do Capítulo

Capítulo 19: Serviços de Certificados do FreeIPA

CA Empresarial: FreeIPA é a solução integrada de gerenciamento de identidade e certificados da Red Hat. É a forma recomendada de executar uma CA interna no RHEL.

19.1 O Que é FreeIPA?

FreeIPA (Identity, Policy, Audit) é uma solução integrada de gerenciamento de informações de segurança que combina:

• 🔐 Gerenciamento de Identidade (diretório LDAP)
• 🎫 Autenticação (Kerberos)
• 🔏 Autoridade Certificadora (CA) (Dogtag PKI)
• 📋 Gerenciamento de Política (sudo, HBAC)
• 🔍 DNS (integração BIND)

Por Que FreeIPA para Certificados?

Em vez de:

• ❌ Gerenciar manualmente certificados por servidor
• ❌ Custos CA externa
• ❌ Infraestrutura PKI complexa

FreeIPA Fornece:

• ✅ CA interna (gratuita!)
• ✅ Registro automático de certificados
• ✅ Auto-renovação via certmonger
• ✅ Perfis de certificados
• ✅ Interface Web e gerenciamento CLI
• ✅ Integração com serviços RHEL

19.2 Instalação FreeIPA (Servidor)

Pré-requisitos

#============================================#
# PRÉ-REQUISITOS PARA SERVIDOR FREEIPA
#============================================#

# Requisitos:
# - RHEL 7/8/9/10
# - Mínimo 2 GB RAM (4 GB recomendado)
# - Hostname fully qualified
# - Resolução DNS apropriada
# - Endereço IP estático

# Verificar hostname
hostnamectl
# Deve mostrar FQDN: ipa.example.com

# Verificar DNS
nslookup $(hostname -f)

# Definir hostname se necessário
sudo hostnamectl set-hostname ipa.example.com

Instalar Servidor FreeIPA

#============================================#
# INSTALAR SERVIDOR FREEIPA
#============================================#

# Instalar pacotes
sudo dnf install ipa-server ipa-server-dns -y

# Executar wizard instalação
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

# Instalação leva 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

# Deveria mostrar múltiplos serviços rodando:
# - Directory Service (389-ds)
# - Certificate Authority (pki-tomcatd)
# - Kerberos KDC
# - Apache Web Server
# - DNS (named)

Acessar Interface Web FreeIPA

# Obter ticket Kerberos
kinit admin
# Senha: AdminPassword123!

# Acessar Interface Web
# https://ipa.example.com/
# Username: admin
# Senha: AdminPassword123!

19.3 Registrando Clientes

Instalação Cliente

#============================================#
# REGISTRAR CLIENTE NO FREEIPA
#============================================#

# No sistema cliente (web01.example.com)

# Instalar cliente IPA
sudo dnf install ipa-client -y

# Registrar
sudo ipa-client-install \
  --domain example.com \
  --realm EXAMPLE.COM \
  --server ipa.example.com \
  --principal admin \
  --password 'AdminPassword123!' \
  --mkhomedir \
  --unattended

# Verificar registro
ipa ping
# Pong!

# Verificar rastreamento certificado
sudo getcert list
# Mostra certmonger rastreando certificado host

19.4 Solicitando Certificados do FreeIPA

Método 1: Interface Web

1. Navegar para https://ipa.example.com/
2. Identity → Hosts → Selecionar host → Actions → New Certificate
3. Ou: Identity → Services → Add service → Request certificate

Método 2: CLI (Recomendado)

#============================================#
# SOLICITAR CERTIFICADO DO FREEIPA
#============================================#

# Para serviço HTTP em 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 serviço customizado
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 status
sudo getcert list

# Aguardar status MONITORING (cert emitido)

Método 3: ipa cert-request (Avançado)

#============================================#
# AVANÇADO: IPA CERT-REQUEST
#============================================#

# Gerar CSR
openssl req -new -key server.key -out server.csr \
  -subj "/CN=server.example.com"

# Solicitar certificado via IPA
ipa cert-request server.csr \
  --principal HTTP/server.example.com@EXAMPLE.COM

# Obter ID certificado da saída
# Certificate: MIIDXTCCAkWgAwIBAgI...
# Request ID: 12345

# Recuperar certificado
ipa cert-show 12345 --out server.crt

19.5 Perfis de Certificado

Perfis Disponíveis

#============================================#
# PERFIS CERTIFICADO FREEIPA
#============================================#

# Listar perfis disponíveis
ipa certprofile-find

# Perfis comuns:
# - caIPAserviceCert: Certificados serviço (HTTP, LDAP, etc.)
# - IECUserRoles: Certificados usuário
# - smimeUserCert: Certificados email S/MIME
# - caSelfSignedCert: CA autoassinada

# Ver detalhes perfil
ipa certprofile-show caIPAserviceCert

# Criar perfil customizado
ipa certprofile-import MyCustomProfile \
  --file custom-profile.cfg \
  --store TRUE

Usando Perfil Específico

# Solicitar com 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 Renovação Automática

Como Funciona

FreeIPA + certmonger = Ciclo de Vida Certificado Automático!

#============================================#
# RENOVAÇÃO AUTOMÁTICA COM FREEIPA
#============================================#

# certmonger automaticamente:
# 1. Rastreia expiração certificado
# 2. Submete requisição renovação para IPA
# 3. Obtém certificado renovado
# 4. Salva em arquivo
# 5. Executa comando post-save (ex: reload httpd)

# Verificar status renovação
sudo getcert list

# Exemplo saída:
# 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

# Renovação acontece automaticamente ~28 dias antes expiração!

Renovação Manual (Se Necessário)

# Forçar renovação agora
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/web.crt

# Ou por ID requisição
sudo ipa-getcert resubmit -i 20240101000000

# Verificar se bem-sucedida
sudo getcert list -f /etc/pki/tls/certs/web.crt

19.7 FreeIPA como CA Empresarial

Gerenciamento Certificado CA

#============================================#
# GERENCIAMENTO CA FREEIPA
#============================================#

# Ver certificado CA
ipa ca-show ipa

# Exportar certificado CA
ipa ca-show ipa --certificate --out /tmp/ipa-ca.crt

# Instalar em clientes (automático durante ipa-client-install)
# Manual: Copiar para repositório de confiança
sudo cp /tmp/ipa-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# Renovar certificado CA (quando necessário)
sudo ipa-cacert-manage renew

# Verificar expiração CA
sudo getcert list -d /var/lib/ipa | grep "CA:"

Sub-CAs (Avançado)

#============================================#
# SUB-CA FREEIPA (RHEL 8+)
#============================================#

# Criar sub-CA
ipa ca-add subca \
  --subject "CN=SubCA,O=EXAMPLE.COM" \
  --desc "Department Sub-CA"

# Emitir certificado da 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 Exemplos Integração Serviço

Apache com Certificados FreeIPA

#============================================#
# APACHE + FREEIPA SETUP COMPLETO
#============================================#

# 1. Registrar sistema no IPA (se ainda não)
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. Aguardar certificado
until sudo getcert list -f /etc/pki/tls/certs/$(hostname -f).crt | grep -q "MONITORING"; do
  sleep 5
  echo "Aguardando certificado..."
done

# 4. Configurar Apache para usá-lo
# /etc/httpd/conf.d/ssl.conf:
# SSLCertificateFile /etc/pki/tls/certs/$(hostname -f).crt
# SSLCertificateKeyFile /etc/pki/tls/private/$(hostname -f).key

# 5. Recarregar Apache
sudo systemctl reload httpd

# Certificado auto-renova!

LDAP com Certificados FreeIPA

# Próprio serviço LDAP do FreeIPA automaticamente usa certificados IPA
# Nenhuma configuração manual necessária!

# Testar
ldapsearch -H ldaps://ipa.example.com:636 -x -b "dc=example,dc=com"

19.9 Solução de Problemas Certificados FreeIPA

Problemas Comuns

Problema 1: CA_UNREACHABLE

# Sintoma
sudo getcert list
# status: CA_UNREACHABLE

# Diagnóstico
# 1. Verificar conectividade servidor IPA
ipa ping

# 2. Verificar ticket Kerberos
klist

# 3. Renovar ticket se expirado
kinit -k host/$(hostname -f)@EXAMPLE.COM

# 4. Verificar serviços IPA
ssh ipa.example.com "sudo ipactl status"

# 5. Retentar
sudo ipa-getcert resubmit -i <request-id>

Problema 2: Requisição Certificado Negada

# Verificar status requisição
sudo getcert list -v

# Causas comuns:
# 1. Principal serviço não existe
ipa service-find HTTP/$(hostname -f)

# Se não encontrado, adicionar:
ipa service-add HTTP/$(hostname -f)

# 2. Host não registrado
ipa host-show $(hostname -f)

# 3. Permissões insuficientes
# Deve solicitar como principal host registrado

Problema 3: Certificado Não Renovado

# Verificar logs certmonger
sudo journalctl -u certmonger | tail -50

# Verificar status CA IPA
sudo ipactl status | grep "CA"

# Forçar renovação
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/web.crt

# Verificar expiração certificado CA
sudo openssl x509 -in /etc/ipa/ca.crt -noout -dates

19.10 Recursos Avançados

Suporte ACME (RHEL 9+)

FreeIPA pode atuar como servidor ACME!

#============================================#
# HABILITAR ACME NO FREEIPA (RHEL 9+)
#============================================#

# No servidor IPA (RHEL 9+)
sudo ipa-acme-manage enable

# Verificar que ACME está disponível
curl https://ipa.example.com/acme/directory

# No cliente: Usar certbot ou certmonger com 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

Hold/Revogação Certificado

#============================================#
# REVOGAR CERTIFICADOS
#============================================#

# Colocar certificado em hold (temporário)
ipa cert-revoke 12345 --revocation-reason 6

# Revogar permanentemente
ipa cert-revoke 12345 --revocation-reason 1

# Razões:
# 0: não especificado
# 1: keyCompromise
# 2: cACompromise
# 4: superseded
# 6: certificateHold (pode ser removido)

# Remover de hold
ipa cert-remove-hold 12345

# Verificar status revogação
ipa cert-show 12345

19.11 Monitorando PKI FreeIPA

Verificações Saúde

#============================================#
# MONITORAMENTO SAÚDE PKI FREEIPA
#============================================#

# Verificar status geral IPA
sudo ipactl status

# Verificar subsistema CA
sudo systemctl status pki-tomcatd@pki-tomcat

# Verificar expirações certificado
ipa-healthcheck --source ipahealthcheck.ipa.certs

# Verificar rastreamento certificado
sudo getcert list | grep -E "(Request|status|expires)"

# Monitorar certificado CA
openssl x509 -in /etc/ipa/ca.crt -noout -dates

# Verificar por certificados expirando
ipa cert-find --validnotafter-from=$(date -d '+60 days' +%Y-%m-%d)

19.12 Backup e Recuperação

Backup Servidor IPA

#============================================#
# BACKUP FREEIPA (INCLUINDO CA)
#============================================#

# Backup completo
sudo ipa-backup --data --online

# Localização backup
ls -lh /var/lib/ipa/backup/

# Incluir chaves CA (apenas backup offline!)
sudo ipactl stop
sudo ipa-backup --data --gpg
# Entrar passphrase GPG
sudo ipactl start

Restaurar Servidor IPA

# Restaurar do backup
sudo ipactl stop
sudo ipa-restore /var/lib/ipa/backup/ipa-full-YYYY-MM-DD-HH-MM-SS/
sudo ipactl start

19.13 Melhores Práticas

Melhores Práticas Certificado FreeIPA

✅ Usar FreeIPA para todos certificados internos
✅ Deixar certmonger lidar com renovação (não renovar manualmente)
✅ Usar principals serviço (HTTP/host, ldap/host, etc.)
✅ Adicionar SANs ao solicitar certificados
✅ Definir comandos post-save (flag -C) para reload serviço
✅ Monitorar saúde servidor IPA regularmente
✅ Backup servidor IPA semanalmente (incluindo chaves CA)
✅ Ter pelo menos 2 réplicas IPA (HA)
✅ Monitorar expiração certificado CA
✅ Testar renovação certificado antes expiração
✅ Usar perfis certificado para padronização

19.14 Exemplos Integração

Configuração Serviço Completo com FreeIPA

#!/bin/bash
# setup-service-with-ipa.sh
# Workflow completo para certificado serviço do FreeIPA

SERVICE_NAME="HTTP"  # Ou 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 do FreeIPA ==="

# 1. Garantir que principal serviço existe
if ! ipa service-show "${SERVICE_NAME}/${HOST}" &>/dev/null; then
  echo "Criando principal serviço..."
  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. Aguardar certificado
echo "Aguardando emissão 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. Certificado vai auto-renovar!
echo "✅ Rastreamento certificado habilitado - auto-renovação ativa"

19.15 Conclusões Chave

1. FreeIPA é a CA interna recomendada pela Red Hat
2. Combina identidade + certificados + autenticação
3. Integração certmonger é automática
4. Certificados auto-renovam (sem trabalho manual!)
5. Usar principals serviço (HTTP/host, ldap/host)
6. Suporte ACME no RHEL 9+ (pode substituir Let’s Encrypt para interno)
7. Interface Web e CLI ambas disponíveis
8. Escala para empresarial - Suporta réplicas, sub-CAs

Cartão de Referência Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA SERVIÇOS CERTIFICADO FREEIPA               │
├──────────────────────────────────────────────────────────────┤
│ Instalar:       dnf install ipa-server                       │
│ Setup:          ipa-server-install                           │
│ Status:         ipactl status                                │
│ Interface Web:  https://ipa.example.com/                     │
│                                                              │
│ Registrar:      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            │
│                                                              │
│ Auto-renov:     Automática via certmonger                    │
│ ACME:           ipa-acme-manage enable (RHEL 9+)             │
└──────────────────────────────────────────────────────────────┘

✅ Melhor para gerenciamento certificado empresarial interno
✅ Totalmente integrado com RHEL
✅ Sem renovação manual necessária!

Navegação do Capítulo

Capítulo 20: Outros Serviços RHEL com Certificados

Além do Básico: Muitos outros serviços RHEL usam certificados. Este capítulo cobre Cockpit, serviços VPN, registros container, e mais.

20.1 Serviços Cobertos

Este capítulo fornece guias de início rápido para:

• 🖥️ Cockpit (Console admin baseado em web)
• 🔒 OpenVPN (Serviço VPN)
• 🛡️ strongSwan (VPN IPsec)
• 📦 Container Registry (Registro Podman/Docker)
• 📡 HAProxy (Load balancer)
• 🔌 Redis com TLS (usando stunnel)
• ⚙️ Ansible Tower/AWX (Plataforma automatização)

20.2 Console Web Cockpit

O Que é Cockpit?

Cockpit é a interface de administração baseada em web integrada do RHEL.

Padrão: Usa certificado autoassinado Objetivo: Substituir com certificado apropriado

Configurar Cockpit com Certificados

#============================================#
# COCKPIT COM CERTIFICADO APROPRIADO
#============================================#

# 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

# Localização certificado Cockpit
ls -l /etc/cockpit/ws-certs.d/

# Método 1: Colocar certificado com nome específico
# Cockpit usa certificados em /etc/cockpit/ws-certs.d/
# Formato filename: NN-name.cert (onde NN = prioridade, menor = maior prioridade)

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+chave combinados

# Acessar Cockpit
# https://server.example.com:9090/

Nota: Cockpit espera cert+chave combinados em arquivo único!

20.3 OpenVPN

Configuração Servidor com Certificados

#============================================#
# SERVIDOR OPENVPN COM CERTIFICADOS
#============================================#

# Instalar OpenVPN (de EPEL no RHEL 7, repos no RHEL 8+)
sudo dnf install openvpn -y

# Gerar ou obter certificados:
# - Certificado CA
# - Certificado servidor + chave
# - Certificados 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

Testar OpenVPN

# Verificar se rodando
systemctl status openvpn-server@server

# Testar do cliente
openvpn --config client.ovpn --verb 3

20.4 strongSwan IPsec VPN

Configurar com Certificados

#============================================#
# STRONGSWAN COM CERTIFICADOS
#============================================#

# Instalar
sudo dnf install strongswan -y

# Localizações certificado
# CA: /etc/strongswan/ipsec.d/cacerts/
# Certs Servidor/Cliente: /etc/strongswan/ipsec.d/certs/
# Chaves 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 status
sudo swanctl --list-sas

20.5 Registro Container com TLS

Registro Podman/Docker

#============================================#
# REGISTRO CONTAINER COM TLS
#============================================#

# Instalar registry
sudo dnf install -y podman
sudo podman pull docker.io/library/registry:2

# Criar 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"

# Executar registry com 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

# Testar
curl https://registry.example.com:5000/v2/_catalog

Configuração Cliente

# Adicionar CA registry ao trust sistema
sudo cp /etc/registry/certs/registry.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# Testar pull
podman pull registry.example.com:5000/myimage:latest

20.6 Terminação TLS HAProxy

Load Balancer com TLS

#============================================#
# TERMINAÇÃO TLS HAPROXY
#============================================#

# Instalar HAProxy
sudo dnf install haproxy -y

# HAProxy requer cert+chave+cadeia combinados em UM arquivo
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

    # Forçar HTTPS
    http-request redirect scheme https unless { ssl_fc }

    # Headers segurança
    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

# Testar
curl -v https://loadbalancer.example.com/

20.7 Redis com TLS (via stunnel)

Proxy TLS Redis

#============================================#
# REDIS COM TLS USANDO STUNNEL
#============================================#

# Instalar Redis e stunnel
sudo dnf install redis stunnel -y

# Configurar Redis (escutar apenas em 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: Requerer certificados cliente
verify = 2
CApath = /etc/pki/tls/certs/

# Iniciar stunnel
sudo systemctl enable --now stunnel@redis

# Testar
openssl s_client -connect localhost:6380
# Então digitar: PING
# Deveria responder: +PONG

20.8 Ansible Tower/AWX

Tower/AWX com Certificado Customizado

#============================================#
# ANSIBLE TOWER/AWX CERTIFICADO CUSTOMIZADO
#============================================#

# Localização certificado Tower
# /etc/tower/tower.cert
# /etc/tower/tower.key

# Substituir com certificado apropriado
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 serviços Tower
sudo ansible-tower-service restart

# Ou para AWX (containerizado)
# Atualizar docker-compose.yml ou secrets k8s

# Testar
curl -v https://tower.example.com/

20.9 SSH com Certificados (Avançado)

Autenticação Certificado SSH

Nota: Diferente de chaves SSH! Isto usa certificados X.509.

#============================================#
# SSH COM CERTIFICADOS X.509 (AVANÇADO)
#============================================#

# Requer: openssh-server com patch X.509 ou ssh-keysign

# Gerar certificado para usuário 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"
# Obter assinado por CA

# Configurar sshd (experimental, não padrão RHEL)
# /etc/ssh/sshd_config
# X509KeyAlgorithm x509v3-rsa2048-sha256
# X509TrustAnchor /etc/ssh/ca.crt

# Abordagem padrão: Usar chaves SSH, não X.509
# Suporte X.509 SSH é limitado no RHEL

Recomendação: Usar autenticação SSH baseada em chave padrão para SSH, usar X.509 para outros serviços.

20.10 Monitorando Múltiplos Serviços

Verificação Certificado Multi-Serviço

#!/bin/bash
# check-all-services.sh
# Verificar certificados para todos serviços

echo "=== Verificação Certificado Multi-Serviço ==="

# Apache
echo "1. Apache (porta 443):"
timeout 3 openssl s_client -connect localhost:443 </dev/null 2>&1 | grep -E "(subject=|issuer=)" | head -2

# NGINX (se instalado)
echo "2. NGINX (porta 8443 ou customizada):"
timeout 3 openssl s_client -connect localhost:8443 </dev/null 2>&1 | grep -E "(subject=|issuer=)" | head -2

# Postfix
echo "3. Postfix SMTPS (porta 465):"
timeout 3 openssl s_client -connect localhost:465 </dev/null 2>&1 | grep -E "(subject=|issuer=)" | head -2

# LDAPS
echo "4. LDAP (porta 636):"
timeout 3 openssl s_client -connect localhost:636 </dev/null 2>&1 | grep -E "(subject=|issuer=)" | head -2

# PostgreSQL
echo "5. PostgreSQL (porta 5432):"
sudo -u postgres psql -c "SHOW ssl;" 2>/dev/null

# Cockpit
echo "6. Cockpit (porta 9090):"
timeout 3 openssl s_client -connect localhost:9090 </dev/null 2>&1 | grep -E "(subject=|issuer=)" | head -2

# Rastreamento certmonger
echo ""
echo "7. Certificados rastreados certmonger:"
sudo getcert list | grep -c "Request ID"
echo "total certificados rastreados"

echo ""
echo "=== Verificação Completa ==="

20.11 Referências Rápidas Específicas por Serviço

Cockpit

# Instalar: dnf install cockpit
# Localização cert: /etc/cockpit/ws-certs.d/
# Formato: Cert+chave combinados
# Recarregar: systemctl restart cockpit.socket
# Testar: https://server:9090/

OpenVPN

# Instalar: dnf install openvpn (EPEL)
# Localização cert: /etc/openvpn/server/
# Arquivos: ca.crt, server.crt, server.key
# Iniciar: systemctl start openvpn-server@server
# Testar: openvpn --config client.ovpn

strongSwan

# Instalar: dnf install strongswan
# Localização cert: /etc/strongswan/ipsec.d/
# Subdirs: cacerts/, certs/, private/
# Iniciar: systemctl start strongswan
# Testar: swanctl --list-sas

HAProxy

# Instalar: dnf install haproxy
# Formato cert: PEM Combinado (cert+chave+cadeia)
# Localização: /etc/haproxy/certs/
# Config: bind *:443 ssl crt /path/to/bundle.pem
# Testar: curl -v https://loadbalancer/

Registro Container

# Executar: podman run -d -p 5000:5000 registry:2
# Certs: Montar como volumes (-v)
# Env vars: REGISTRY_HTTP_TLS_CERTIFICATE
#           REGISTRY_HTTP_TLS_KEY
# Testar: curl https://registry:5000/v2/_catalog

20.12 Certificados Wildcard para Múltiplos Serviços

Quando Usar Wildcards

Cenário: Múltiplos subdomínios no mesmo servidor

web.example.com    → Apache
api.example.com    → NGINX
admin.example.com  → Cockpit
mail.example.com   → Postfix

Solução: Usar certificado wildcard *.example.com

Gerar Certificado Wildcard

#============================================#
# CERTIFICADO WILDCARD
#============================================#

# Gerar chave
openssl genpkey -algorithm RSA -out wildcard.key -pkeyopt rsa_keygen_bits:2048

# Gerar CSR
openssl req -new -key wildcard.key -out wildcard.csr \
  -subj "/CN=*.example.com" \
  -addext "subjectAltName=DNS:*.example.com,DNS:example.com"

# Submeter para CA, receber wildcard.crt

# Usar para múltiplos serviços
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 serviço para usá-lo
# 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

Prós:

• ✅ Um certificado para múltiplos subdomínios
• ✅ Gerenciamento mais fácil
• ✅ Cost-effective (se comprando)

Contras:

• ⚠️ Se comprometido, afeta todos subdomínios
• ⚠️ Não funciona para multi-nível (..example.com)
• ⚠️ Algumas políticas segurança proíbem wildcards

20.13 Matriz Certificados Serviço

Requisitos Certificado por Serviço

20.14 Guia Rápido Solução de Problemas

Solução de Problemas TLS Serviço Genérico

#============================================#
# SOLUÇÃO DE PROBLEMAS TLS UNIVERSAL
#============================================#

# 1. Identificar serviço e porta
ss -tlnp | grep <serviço>

# 2. Verificar se TLS está habilitado
# (comando específico serviço)

# 3. Testar conexão TLS
openssl s_client -connect localhost:<porta>
# Ou com STARTTLS:
openssl s_client -connect localhost:<porta> -starttls <protocolo>

# 4. Verificar arquivos certificado
ls -lZ /path/to/certs/

# 5. Verificar propriedade/permissões
# - Certificado: 644, propriedade usuário serviço
# - Chave: 600, propriedade usuário serviço

# 6. Verificar configuração
# (arquivo config específico serviço)

# 7. Verificar logs
sudo journalctl -u <serviço> | grep -i tls
sudo tail -f /var/log/<serviço>/ | grep -i tls

# 8. Testar de cliente remoto
openssl s_client -connect server.example.com:<porta>

20.15 Gerenciamento Certificado Centralizado

Usando certmonger para Todos Serviços

#============================================#
# ESTRATÉGIA GERENCIAMENTO CERTIFICADO CENTRAL
#============================================#

# Rastrear todos certificados serviço com 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"

# Monitorar todos
sudo getcert list

Benefícios:

• ✅ Ferramenta única para todos serviços
• ✅ Renovação automática
• ✅ Monitoramento centralizado
• ✅ Abordagem consistente

20.16 Conclusões Chave

1. Muitos serviços usam certificados além de apenas servidores web
2. Cada serviço tem requisitos únicos - Verificar propriedade, permissões
3. certmonger funciona com maioria serviços para automatização
4. Certificados wildcard podem simplificar setups multi-serviço
5. Testar cada serviço independentemente
6. Rastreamento centralizado com certmonger recomendado
7. Documentar configurações específicas serviço

Cartão de Referência Rápida

┌───────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA CERTIFICADOS OUTROS SERVIÇOS                │
├───────────────────────────────────────────────────────────────┤
│ Cockpit:     /etc/cockpit/ws-certs.d/NN-name.cert             │
│              (cert+chave combinados)                          │
│                                                               │
│ OpenVPN:     /etc/openvpn/server/{ca,server}.{crt,key}        │
│              PKI complexa com certs cliente                   │
│                                                               │
│ strongSwan:  /etc/strongswan/ipsec.d/{cacerts,certs,private}/ │
│              Configuração IPsec-específica                    │
│                                                               │
│ HAProxy:     PEM Combinado (cert+chave+cadeia em um arquivo)  │
│              /etc/haproxy/certs/bundle.pem                    │
│                                                               │
│ Registry:    Variáveis ambiente para container                │
│              REGISTRY_HTTP_TLS_CERTIFICATE/KEY                │
│                                                               │
│ Genérico:    Verificar propriedade, permissões, SELinux       │
│              Testar com: openssl s_client -connect :porta     │
└───────────────────────────────────────────────────────────────┘

✅ Usar certmonger para automatização onde possível
✅ Cada serviço tem requisitos únicos formato/localização arquivo

Navegação do Capítulo

Capítulo 21: Melhores Práticas de Certificados de Serviço

Crítico para Operações: Aprenda as melhores práticas que previnem 90% dos problemas de certificado antes que aconteçam.

21.1 O Custo de Gerenciamento Pobre de Certificados

Impactos mundo real:

• ❌ Certificado expirado → Website fora do ar (perda receita)
• ❌ Permissões erradas → Serviço falha ao iniciar (downtime)
• ❌ Sem backup → Falha CA significa reemissão manual (horas/dias)
• ❌ Nomenclatura ruim → Confusão durante incidente (resposta atrasada)
• ❌ Sem monitoramento → Expiração surpresa (resposta emergência)

Este capítulo previne estes problemas.

21.2 Melhores práticas de organização de arquivos

Estrutura Diretório Padrão

/etc/pki/tls/
├── certs/                      # Arquivos certificado (públicos)
│   ├── service-name.crt        # Certificados reais
│   ├── service-name-chain.crt  # Com cadeia intermediária
│   └── ca-bundle.crt           # Bundle CA
│
├── private/                    # Chaves privadas (protegidas!)
│   └── service-name.key        # Chaves privadas (modo 600)
│
├── csr/                        # Requisições certificado (opcional)
│   └── service-name.csr        # CSRs para rastreamento
│
└── backup/                     # Backups (opcional mas recomendado)
    └── YYYY-MM-DD/
        ├── service-name.crt
        └── service-name.key

Convenções de Nomenclatura

Boa nomenclatura previne confusão:

# ✅ BOM - Claro, descritivo
/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

# ❌ RUIM - Não claro, genérico
/etc/pki/tls/certs/cert1.crt
/etc/pki/tls/certs/new.crt
/etc/pki/tls/certs/temp.crt

Padrão nomenclatura:

[serviço]-[hostname/função]-[domínio].crt
[serviço]-[hostname/função]-[domínio].key

Exemplos:
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

Padrões Permissão Arquivo

#============================================#
# CRÍTICO: Permissões Apropriadas
#============================================#

# Certificados (públicos) - legíveis por todos
/etc/pki/tls/certs/*.crt           → 644 (rw-r--r--)
/etc/pki/tls/certs/                → 755 (rwxr-xr-x)

# Chaves privadas (secretas!) - apenas legíveis pelo proprietário
/etc/pki/tls/private/*.key         → 600 (rw-------)
/etc/pki/tls/private/              → 711 (rwx--x--x)

# Chaves específicas serviço - propriedade usuário serviço
/etc/pki/tls/private/apache.key    → 600, owner: root ou apache
/etc/pki/tls/private/postgres.key  → 600, owner: postgres

Script definir permissões:

#!/bin/bash
# set-cert-permissions.sh
# Define permissões apropriadas em arquivos certificado

CERT_DIR="/etc/pki/tls/certs"
KEY_DIR="/etc/pki/tls/private"

# Diretório certificados
chmod 755 "$CERT_DIR"
chmod 644 "$CERT_DIR"/*.crt 2>/dev/null

# Diretório chaves privadas
chmod 711 "$KEY_DIR"
chmod 600 "$KEY_DIR"/*.key 2>/dev/null

# Verificar
echo "Permissões certificados:"
ls -ld "$CERT_DIR" "$CERT_DIR"/*.crt 2>/dev/null

echo ""
echo "Permissões chaves privadas:"
ls -ld "$KEY_DIR" "$KEY_DIR"/*.key 2>/dev/null

# Verificar por chaves excessivamente permissivas
echo ""
echo "Verificando por problemas segurança:"
find "$KEY_DIR" -type f -not -perm 600 -ls 2>/dev/null && \
  echo "⚠️ AVISO: Algumas chaves têm permissões incorretas!" || \
  echo "✅ Todas chaves apropriadamente protegidas"

21.3 Gerenciamento do ciclo de vida de certificados

Timeline Renovação

Ciclo de Vida Certificado (validade 365 dias):

Dia   0: Certificado emitido
Dia  30: Primeiro lembrete renovação (335 dias restantes)
Dia  60: Segundo lembrete (305 dias restantes)
Dia 300: Janela renovação crítica inicia (65 dias restantes)
Dia 330: URGENTE - Renovação necessária (35 dias restantes)
Dia 350: CRÍTICO - Renovação atrasada (15 dias restantes)
Dia 365: EXPIRADO - Interrupção serviço!

Ações Recomendadas:
- Dias 300-330: Planejar e executar renovação
- Dias 330-350: Renovação emergência se perdida
- Dias 350+: Resposta incidente, cert temporário

Estratégias Renovação

Estratégia 1: Automatizada (Recomendada)

# Usando certmonger (RHEL)
sudo 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"  # Auto-recarregar serviço

# Auto-renovação acontece em 2/3 do tempo vida cert
# cert 365 dias → renova no dia 243 (122 dias restantes)

Estratégia 2: Renovação Manual Agendada

# Job cron para verificação renovação manual
# /etc/cron.weekly/check-certificates

#!/bin/bash
# Verificar certificados expirando em 60 dias
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 dias!"
    # Enviar alerta
    mail -s "Certificado Expirando Em Breve: $cert" admin@example.com
  fi
done

Estratégia 3: Lembretes Calendário

# Para ambientes sem automatização
# Criar entradas calendário:
# - 90 dias antes expiração: Iniciar renovação
# - 60 dias antes: Verificar renovação em progresso
# - 30 dias antes: Completar renovação
# - 7 dias antes: Emergência se não feito

21.4 Rastreamento de metadados de certificados

Inventário Certificados

Manter inventário certificados (planilha ou banco dados):

Service,Hostname,Certificate_Path,Key_Path,Issuer,Issue_Date,Expiry_Date,SANs,Owner,Notes
Apache,web01,/etc/pki/tls/certs/web01.crt,/etc/pki/tls/private/web01.key,Internal CA,2024-01-01,2025-01-01,"web01.example.com,www.example.com",John Doe,Production
NGINX,web02,/etc/pki/tls/certs/web02.crt,/etc/pki/tls/private/web02.key,Let's Encrypt,2024-06-15,2024-09-15,"web02.example.com",Jane Smith,Staging

Script gerar inventário:

#!/bin/bash
# generate-cert-inventory.sh
# Cria inventário certificados do sistema

echo "Service,Hostname,Certificate_Path,Issuer,Issue_Date,Expiry_Date,Days_Remaining"

# Escanear localizações certificado comuns
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 dias restantes
  expiry_epoch=$(date -d "$notafter" +%s 2>/dev/null)
  now_epoch=$(date +%s)
  days_remaining=$(( ($expiry_epoch - $now_epoch) / 86400 ))

  # Determinar serviço do caminho
  service="Unknown"
  [[ "$cert" =~ httpd ]] && service="Apache"
  [[ "$cert" =~ nginx ]] && service="NGINX"

  echo "$service,$(hostname),$cert,\"$issuer\",$notbefore,$notafter,$days_remaining"
done

21.5 Backup e Recuperação

O Que Fazer Backup

Arquivos críticos para backup:
✅ Chaves privadas (arquivos .key)
✅ Certificados (arquivos .crt)
✅ Certificados CA
✅ Cadeias certificado
✅ CSRs (para referência)
✅ Arquivos configuração (Apache ssl.conf, etc.)
⚠️ NÃO senhas ou passphrases (armazenar separadamente em vault)

Script Backup

#!/bin/bash
# backup-certificates.sh
# Faz backup de todos certificados e chaves

BACKUP_DIR="/var/backups/certificates"
DATE=$(date +%Y-%m-%d)
BACKUP_PATH="$BACKUP_DIR/$DATE"

# Criar diretório backup
mkdir -p "$BACKUP_PATH"

# Backup certificados
echo "Fazendo backup certificados..."
cp -a /etc/pki/tls/certs/*.crt "$BACKUP_PATH/" 2>/dev/null

# Backup chaves privadas (criptografadas!)
echo "Fazendo backup chaves 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

# Backup arquivos configuração
echo "Fazendo backup configs..."
cp -a /etc/httpd/conf.d/ssl.conf "$BACKUP_PATH/" 2>/dev/null
cp -a /etc/nginx/nginx.conf "$BACKUP_PATH/" 2>/dev/null

# Criar inventário
ls -lh "$BACKUP_PATH"

# Definir permissões
chmod 700 "$BACKUP_PATH"

echo "✅ Backup completo: $BACKUP_PATH"
echo "⚠️ Lembrar de mudar senha criptografia!"

Procedimento Recuperação

#============================================#
# PROCEDIMENTO RECUPERAÇÃO CERTIFICADO
#============================================#

# 1. Parar serviço afetado
sudo systemctl stop httpd

# 2. Restaurar certificado
sudo cp /var/backups/certificates/2024-11-15/web.crt /etc/pki/tls/certs/

# 3. Restaurar chave privada (descriptografar)
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. Definir permissões
sudo chmod 600 /etc/pki/tls/private/*.key
sudo chmod 644 /etc/pki/tls/certs/*.crt

# 5. Verificar arquivos
sudo openssl x509 -in /etc/pki/tls/certs/web.crt -noout -text
sudo openssl rsa -in /etc/pki/tls/private/web.key -check

# 6. Iniciar serviço
sudo systemctl start httpd

# 7. Testar
curl -v https://localhost/

21.6 Melhores práticas de segurança

Proteção Chave Privada

#============================================#
# CHECKLIST SEGURANÇA CHAVE PRIVADA
#============================================#

✅ Permissões: 600 (ou 400 para proteção extra)
✅ Propriedade: root ou apenas usuário serviço
✅ Localização: /etc/pki/tls/private/ (modo 711)
✅ SELinux: Contexto apropriado (cert_t)
✅ Backup: Criptografado em repouso
✅ Nunca: Email, colar em tickets, commit no git
✅ Nunca: Compartilhar entre sistemas (gerar novo)
✅ Auditoria: Logar acesso com auditd

# Verificar segurança
ls -lZ /etc/pki/tls/private/*.key
# -rw------- root root unconfined_u:object_r:cert_t:s0 server.key

Melhores Práticas Geração Chave

#============================================#
# GERAR CHAVES SEGURAS
#============================================#

# RSA 2048 (mínimo para RHEL 8+)
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

# RSA 4096 (recomendado para certs longevidade longa)
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:4096

# EC P-256 (moderno, menor, rápido)
openssl genpkey -algorithm EC -out server.key -pkeyopt ec_paramgen_curve:P-256

# Definir permissões imediatamente!
chmod 600 server.key

# ❌ NUNCA fazer isto:
# openssl genrsa -out server.key 1024   # Muito fraco!
# chmod 644 server.key                  # Muito permissivo!

Validação Certificado Antes de Implantação

#!/bin/bash
# validate-certificate.sh
# Valida certificado antes de implantação

CERT=$1
KEY=$2

echo "=== Validação Certificado Pré-Implantação ==="

# Verificação 1: Arquivo certificado existe e legível
if [ ! -f "$CERT" ]; then
  echo "❌ Arquivo certificado não encontrado: $CERT"
  exit 1
fi

# Verificação 2: Chave privada existe e legível
if [ ! -f "$KEY" ]; then
  echo "❌ Chave privada não encontrada: $KEY"
  exit 1
fi

# Verificação 3: Certificado é X.509 válido
if ! openssl x509 -in "$CERT" -noout 2>/dev/null; then
  echo "❌ Certificado X.509 inválido"
  exit 1
fi

# Verificação 4: Certificado não expirou
if ! openssl x509 -in "$CERT" -noout -checkend 0; then
  echo "❌ Certificado está expirado!"
  exit 1
fi

# Verificação 5: Par certificado/chave coincide
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 e chave não coincidem!"
  exit 1
fi

# Verificação 6: SANs presentes (requerido para navegadores modernos)
if ! openssl x509 -in "$CERT" -noout -ext subjectAltName 2>/dev/null | grep -q "DNS:"; then
  echo "⚠️ AVISO: Nenhum Subject Alternative Name encontrado"
fi

# Verificação 7: Algoritmo assinatura forte
SIG_ALG=$(openssl x509 -in "$CERT" -noout -text | grep "Signature Algorithm" | head -2)
if echo "$SIG_ALG" | grep -qi "sha1\|md5"; then
  echo "❌ Algoritmo assinatura fraco: $SIG_ALG"
  exit 1
fi

# Verificação 8: Tamanho chave adequado
KEY_SIZE=$(openssl x509 -in "$CERT" -noout -text | grep "Public-Key:" | grep -oP '\d+')
if [ "$KEY_SIZE" -lt 2048 ]; then
  echo "❌ Tamanho chave muito pequeno: $KEY_SIZE bits (mínimo 2048)"
  exit 1
fi

echo ""
echo "✅ Validação certificado passou!"
echo "   Subject: $(openssl x509 -in "$CERT" -noout -subject)"
echo "   Issuer: $(openssl x509 -in "$CERT" -noout -issuer)"
echo "   Expires: $(openssl x509 -in "$CERT" -noout -enddate | cut -d= -f2)"
echo "   Key Size: $KEY_SIZE bits"

21.7 Coordenação Multi-Serviço

Quando Múltiplos Serviços Compartilham Certificados

# Cenário: Load balancer + múltiplos servidores web

# Problema: Certificado no LB, serviços atrás necessitam mesmo CN/SANs

# Solução 1: Usar mesmo certificado em todos (se hostnames coincidem)
# web01, web02, web03 todos usam cert para: web.example.com

# Solução 2: Certificado wildcard
# *.example.com funciona para web01.example.com, web02.example.com, etc.

# Solução 3: SANs abrangentes
# Cert único com SANs: web.example.com, web01.example.com, web02.example.com

Fluxo Trabalho Implantação Certificado

#============================================#
# IMPLANTAÇÃO MULTI-SERVIDOR
#============================================#

# Passo 1: Gerar certificado no nó gerenciamento
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"

# Passo 2: Obter certificado da CA
# (submeter web.csr para CA, receber web.crt)

# Passo 3: Validar localmente
./validate-certificate.sh web.crt web.key

# Passo 4: Distribuir com segurança
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/web.crt"
  ssh root@$host "chmod 600 /etc/pki/tls/private/web.key"
done

# Passo 5: Recarregar serviços
for host in web01 web02 web03; do
  ssh root@$host "systemctl reload httpd"
done

# Passo 6: Testar cada servidor
for host in web01 web02 web03; do
  echo "Testando $host..."
  curl -vk https://$host/ 2>&1 | grep "subject:"
done

21.8 Padrões de documentação

Template Documentação Certificado

## Certificado: web.example.com

### Informação Básica
- **Serviço:** Apache (httpd)
- **Servidor:** web01.example.com
- **Caminho Certificado:** `/etc/pki/tls/certs/web-example-com.crt`
- **Caminho Chave:** `/etc/pki/tls/private/web-example-com.key`
- **Proprietário:** Web Team (webadmin@example.com)

### Detalhes Certificado
- **Common Name (CN):** web.example.com
- **SANs:** web.example.com, www.example.com
- **Emissor:** Internal CA (ca.example.com)
- **Data Emissão:** 2024-01-01
- **Data Expiração:** 2025-01-01
- **Tipo Chave:** RSA 2048

### Processo Renovação
- **Método:** certmonger automático
- **Janela Renovação:** 65 dias antes expiração
- **Pós-Renovação:** `systemctl reload httpd`
- **Contato:** webadmin@example.com

### Configuração Serviço
- **Arquivo Config:** `/etc/httpd/conf.d/ssl.conf`
- **Serviço:** `httpd.service`
- **Comando Restart:** `systemctl reload httpd`

### Solução de Problemas
- **Logs:** `/var/log/httpd/ssl_error_log`
- **Comando Teste:** `curl -v https://web.example.com/`
- **Problemas Comuns:** Nenhum relatado

### Histórico Mudanças
- 2024-01-01: Implantação inicial
- 2024-06-15: Adicionado SAN www.example.com

21.9 Monitoramento e Alertas

O Que Monitorar

✅ Expiração certificado (60, 30, 7 dias antes)
✅ Validade certificado (não expirado, ainda não válido)
✅ Coincidência par certificado/chave
✅ Cadeia confiança certificado
✅ Saúde serviço (está usando o cert?)
✅ Status rastreamento certmonger
✅ Sucesso/falha renovação

Script Monitoramento Simples

#!/bin/bash
# monitor-certificates.sh
# Monitoramento certificado simples

WARN_DAYS=30
CRIT_DAYS=7
EMAIL="admin@example.com"

check_cert() {
  local cert=$1
  local name=$(basename "$cert")

  # Verificar se expira dentro período aviso
  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 dias!"
      return 2
    else
      echo "⚠️ AVISO: $name expira dentro de $WARN_DAYS dias"
      return 1
    fi
  fi

  return 0
}

# Verificar todos 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 se problemas encontrados
if [ $CRITICALS -gt 0 ] || [ $WARNINGS -gt 0 ]; then
  echo "Problemas certificado encontrados: $CRITICALS críticos, $WARNINGS avisos" | \
    mail -s "Alerta Certificado: $(hostname)" "$EMAIL"
fi

21.10 Procedimentos de resposta a incidentes

Incidente Expiração Certificado

#============================================#
# EMERGÊNCIA CERTIFICADO EXPIRADO
#============================================#

# Passo 1: Avaliar impacto
systemctl status httpd
journalctl -xe | grep -i cert

# Passo 2: Correção rápida - Obter cert temporário
# Opção A: Autoassinado (apenas para interno!)
openssl req -x509 -nodes -days 30 -newkey rsa:2048 \
  -keyout /etc/pki/tls/private/temp.key \
  -out /etc/pki/tls/certs/temp.crt \
  -subj "/CN=$(hostname)"

# Opção B: Restaurar do backup
cp /var/backups/certificates/latest/*.crt /etc/pki/tls/certs/
cp /var/backups/certificates/latest/*.key /etc/pki/tls/private/

# Passo 3: Atualizar config serviço para usar cert temp
# Editar /etc/httpd/conf.d/ssl.conf
# SSLCertificateFile /etc/pki/tls/certs/temp.crt
# SSLCertificateKeyFile /etc/pki/tls/private/temp.key

# Passo 4: Reiniciar serviço
systemctl restart httpd

# Passo 5: Obter certificado apropriado ASAP
# Seguir processo requisição cert normal

# Passo 6: Documentar incidente
# O que aconteceu, por quê, como corrigido, prevenção

21.11 Lista de verificação de melhores práticas

## Lista de verificação de gerenciamento de certificados

### Organização de arquivos
- [ ] Estrutura diretório padrão usada
- [ ] Convenção nomenclatura consistente
- [ ] Permissões arquivo apropriadas (600 para chaves, 644 para certs)
- [ ] Contextos SELinux corretos

### Gerenciamento do ciclo de vida
- [ ] Processo renovação definido e documentado
- [ ] Lembretes renovação definidos (60, 30, 7 dias)
- [ ] Renovação automatizada se possível (certmonger)
- [ ] Ações pós-renovação definidas

### Segurança
- [ ] Chaves privadas protegidas (permissões 600)
- [ ] Chaves nunca compartilhadas/emailadas
- [ ] Algoritmo chave forte (RSA 2048+ ou EC P-256)
- [ ] Assinatura forte (SHA-256+)

### Backup
- [ ] Certificados com backup
- [ ] Chaves privadas com backup (criptografadas)
- [ ] Backup testado e validado
- [ ] Procedimento restauração documentado

### Documentação
- [ ] Inventário certificados mantido
- [ ] Cada certificado documentado
- [ ] Procedimentos escritos
- [ ] Contatos listados

### Monitoramento
- [ ] Monitoramento expiração habilitado
- [ ] Alertas configurados
- [ ] Verificações saúde em vigor
- [ ] Plano resposta incidente pronto

### Validação
- [ ] Validação pré-implantação
- [ ] Teste pós-implantação
- [ ] Auditorias regulares agendadas

21.12 Conclusões Chave

1. Organização previne confusão - Estrutura e nomenclatura consistentes
2. Permissões são críticas - 600 para chaves, 644 para certs
3. Automatizar renovação - Usar certmonger sempre que possível
4. Backup de tudo - Mas criptografar chaves privadas
5. Documentar completamente - Seu eu futuro agradecerá
6. Monitorar proativamente - Não esperar por expiração
7. Validar antes implantar - Capturar problemas cedo
8. Planejar para incidentes - Ter procedimentos recuperação prontos

Referência Rápida

┌──────────────────────────────────────────────────────────────┐
│ MELHORES PRÁTICAS CERTIFICADOS SERVIÇO                       │
├──────────────────────────────────────────────────────────────┤
│ Arquivos:   /etc/pki/tls/certs/*.crt (644)                   │
│             /etc/pki/tls/private/*.key (600)                 │
│ Nomencl:    [serviço]-[host]-[domínio].[crt|key]             │
│ Renovação:  Automatizar com certmonger                       │
│ Backup:     Diário, criptografado, testado                   │
│ Monitor:    60, 30, 7 dias antes expiração                   │
│ Validar:    Antes de cada implantação                        │
│ Document:   Tudo, todos                                      │
└──────────────────────────────────────────────────────────────┘

Navegação do Capítulo

Capítulo 22: Domínio do certmonger

Configure e Esqueça: certmonger é a ferramenta de automatização de certificados integrada do RHEL. Domine-a e você nunca renovará um certificado manualmente novamente.

22.1 O Que é certmonger?

certmonger é um daemon de rastreamento de certificados e renovação automática para RHEL.

Pense nisso como:

• 📋 Rastreador de certificados - Monitora datas de expiração
• 🔄 Renovador automático - Renova antes de expirar
• 🔗 Integrador de CA - Funciona com FreeIPA, CAs locais/internas e helpers de CA externa
• ⚙️ Integração de serviços - Executa comandos após renovação

Por Que certmonger?

Sem certmonger:

❌ Rastreamento manual de datas de expiração
❌ Lembretes de calendário para renovar
❌ Geração manual de CSR
❌ Reinício manual de serviço após renovação
❌ Risco de perder renovações → interrupções

Com certmonger:

✅ Rastreamento automático
✅ Renovação automática
✅ Recarga automática de serviço
✅ Monitoramento centralizado
✅ Sem intervenção manual!

22.2 Instalação e Configuração

Todas Versões 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  # Deveria mostrar lista vazia inicialmente

22.3 Uso Básico

Solicitando um Certificado

#============================================#
# REQUISIÇÃO CERTIFICADO BÁSICA
#============================================#

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

# Do 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 do Let's Encrypt, use certbot (Capítulo 24).
# certmonger é a escolha nativa para IPA, CA local e fluxos baseados em helpers.

Verificando Status

#============================================#
# VERIFICAR STATUS CERTIFICADO
#============================================#

# Listar todos certificados rastreados
sudo getcert list

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

# Verificar por ID requisição
sudo getcert list -i 20240101000000

# Saída verbose
sudo getcert list -v

Valores Status:

• MONITORING: ✅ Certificado emitido, rastreando expiração
• SUBMITTING: 🔄 Submetendo requisição para CA
• CA_UNREACHABLE: ❌ Não consegue alcançar servidor CA
• CA_REJECTED: ❌ CA rejeitou requisição
• NEED_KEY_GEN_PIN: ⏸️ Aguardando PIN (HSM/token)
• PRE_SAVE_COMMAND: 🔄 Executando script pre-save
• POST_SAVE_COMMAND: 🔄 Executando script post-save

22.4 Opções Avançadas

Requisição Completa com Todas Opções

#============================================#
# REQUISIÇÃO CERTMONGER COMPLETA
#============================================#

sudo ipa-getcert request \
  -f /etc/pki/tls/certs/web.example.com.crt \              # Arquivo certificado
  -k /etc/pki/tls/private/web.example.com.key \            # Arquivo chave privada
  -K HTTP/web.example.com@EXAMPLE.COM \                    # Principal Kerberos
  -D web.example.com \                                     # Nome DNS (SAN)
  -D www.example.com \                                     # SAN adicional
  -D api.example.com \                                     # Outro SAN
  -U id-kp-serverAuth \                                    # Extended key usage
  -N CN=web.example.com,O=Example,C=US \                   # Subject DN
  -g 2048 \                                                # Tamanho chave
  -G rsa \                                                 # Tipo chave
  -T caIPAserviceCert \                                    # Perfil IPA
  -C "systemctl reload httpd" \                            # Comando post-save
  -B "systemctl stop httpd" \                              # Comando pre-save
  -v \                                                     # Verbose
  -w                                                       # Aguardar conclusão

# Verificar status
sudo getcert list -f /etc/pki/tls/certs/web.example.com.crt

Opções Chave Explicadas:

22.5 Trabalhando com CAs Diferentes

FreeIPA (Recomendado para Interno)

#============================================#
# CERTMONGER + FREEIPA
#============================================#

# Pré-requisitos: Sistema registrado no 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 automaticamente:
# ✅ Submete requisição para CA IPA
# ✅ Obtém certificado
# ✅ Salva em arquivo
# ✅ Executa comando reload
# ✅ Rastreia expiração
# ✅ Renova ~28 dias antes expiração

ACME público requer certbot

#============================================#
# ACME PÚBLICO VS FLUXOS NATIVOS DO CERTMONGER
#============================================#

# Certificado público do Let's Encrypt:
# Use certbot, não um perfil de CA falso no certmonger.
sudo certbot certonly --apache -d public.example.com

# Certificado nativo do 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 (Submissão Manual)

#============================================#
# CERTMONGER COM CA EXTERNA
#============================================#

# Configurar helper 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

# Script helper deve:
# 1. Ler CSR de stdin
# 2. Submeter para CA externa
# 3. Retornar certificado em stdout

22.6 Gerenciando Certificados Rastreados

Modificar Rastreamento

#============================================#
# MODIFICAR RASTREAMENTO CERTIFICADO EXISTENTE
#============================================#

# Atualizar comando post-save sem 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"
# Re-adicione -c, -K, -D, etc. se a entrada original os usava

# Adicionar SAN adicional
sudo getcert resubmit -f /etc/pki/tls/certs/web.crt \
  -D additional.example.com

# Parar rastreamento (manter certificado)
sudo getcert stop-tracking -f /etc/pki/tls/certs/web.crt

# Remover completamente
sudo getcert stop-tracking -f /etc/pki/tls/certs/web.crt -r

# Iniciar rastreamento certificado existente
sudo getcert start-tracking \
  -f /etc/pki/tls/certs/existing.crt \
  -k /etc/pki/tls/private/existing.key

Forçar Renovação

#============================================#
# FORÇAR RENOVAÇÃO IMEDIATA
#============================================#

# Por caminho arquivo
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/web.crt

# Por ID requisição
sudo getcert resubmit -i 20240101000000

# Aguardar renovação
sudo getcert list -f /etc/pki/tls/certs/web.crt
# Aguardar status: MONITORING

22.7 Timing Renovação

Entendendo Janelas Renovação

Ciclo de Vida Certificado (365 dias):

Dia   0: Certificado emitido
      │
      │ [Operação normal]
      │
Dia 243: Janela renovação inicia (certmonger tenta renovação)
      │ (2/3 do tempo vida cert: 365 × 2/3 ≈ 243 dias)
      │
      │ [Tentativas renovação a cada 8 horas se CA disponível]
      │
Dia 335: Aviso se ainda não renovado (30 dias restantes)
      │
Dia 350: Crítico se ainda não renovado (15 dias restantes)
      │
Dia 365: Certificado expira → INTERRUPÇÃO SERVIÇO se não renovado!

Comportamento Padrão:

• Renovação inicia em 2/3 do tempo vida certificado
• cert 365 dias → Renova no dia 243 (122 dias restantes)
• cert 90 dias → Renova no dia 60 (30 dias restantes)

22.8 Comandos Post-Save

Reload vs Restart

#============================================#
# ESTRATÉGIAS COMANDO POST-SAVE
#============================================#

# PREFERIR: reload (sem downtime)
-C "systemctl reload httpd"
-C "systemctl reload nginx"
-C "postfix reload"

# ÀS VEZES NECESSÁRIO: restart
-C "systemctl restart slapd"  # OpenLDAP requer restart
-C "systemctl restart postgresql"  # PostgreSQL requer restart

# MÚLTIPLOS COMANDOS: Usar script
-C "/usr/local/bin/after-cert-renewal.sh"

# Exemplo script:
#!/bin/bash
# /usr/local/bin/after-cert-renewal.sh
systemctl reload httpd
systemctl reload nginx
systemctl reload postfix
logger "Certificados renovados via certmonger"

22.9 Solução de Problemas certmonger

Problemas Comuns

Problema 1: CA_UNREACHABLE

# Sintoma
sudo getcert list
# status: CA_UNREACHABLE

# Diagnóstico
# Para FreeIPA:
ipa ping  # Verificar conectividade IPA
klist  # Verificar ticket Kerberos

# Corrigir
kinit -k host/$(hostname -f)@REALM  # Renovar ticket 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

# Sintoma
sudo getcert list
# status: CA_REJECTED
# ca-error: Server at https://ipa.example.com/ipa/xml unwilling to issue certificate

# Causas comuns:
# 1. Principal serviço não existe
ipa service-show HTTP/$(hostname -f)
# Se não encontrado:
ipa service-add HTTP/$(hostname -f)

# 2. Host não registrado
ipa host-show $(hostname -f)

# 3. Problema permissão
# Verificar permissões IPA

# Retentar
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/web.crt

Problema 3: Renovação Não Acontecendo

# Verificar certmonger está rodando
systemctl status certmonger

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

# Verificar logs certmonger
sudo journalctl -u certmonger -f

# Forçar renovação
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/web.crt

# Verificar janela renovação
# Certificado renova em 2/3 do tempo vida
# Verificar data "expires" na saída getcert list

22.10 IdM ACME vs Let’s Encrypt público

Mantenha os fluxos separados

#============================================#
# ESCOLHA A FERRAMENTA CERTA PARA A CA CERTA
#============================================#

# Certificado público do Let's Encrypt:
# Use certbot (veja o Capítulo 24).
sudo certbot certonly --apache -d public.example.com -d www.public.example.com

# Certificado nativo do FreeIPA / IdM:
# Use 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"

# Se o IdM ACME estiver habilitado, o diretório ACME dele é o seu servidor IPA,
# não o Let's Encrypt:
sudo certbot certonly \
  --server https://ipa.example.com/acme/directory \
  -d host.example.com

Distinção importante:

• Let’s Encrypt = CA ACME pública da internet
• IdM/FreeIPA ACME = sua CA IPA interna expondo um endpoint ACME
• certmonger = rastreador/renovador nativo do RHEL para IPA e fluxos baseados em helpers

22.11 Monitorando certmonger

Monitoramento Status

#============================================#
# MONITORAR CERTMONGER
#============================================#

# Visão geral de todos certificados
sudo getcert list

# Contar certificados por status
sudo getcert list | grep "status:" | sort | uniq -c

# Encontrar certificados expirando em breve (30 dias)
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 em breve: $cert"
  fi
done

# Verificar logs certmonger
sudo journalctl -u certmonger --since today

# Observar por atividade renovação
sudo journalctl -u certmonger -f

# Verificar próximo tempo renovação
sudo getcert list | grep -A15 "Request ID" | grep "expires"

Script Verificação Saúde

#!/bin/bash
# certmonger-health-check.sh

echo "=== Verificação Saúde certmonger ==="

# certmonger rodando?
if systemctl is-active --quiet certmonger; then
  echo "✅ certmonger está rodando"
else
  echo "❌ certmonger NÃO está rodando!"
  exit 1
fi

# Contar certificados rastreados
TOTAL=$(sudo getcert list | grep -c "Request ID")
echo "📋 Rastreando $TOTAL certificados"

# Verificar breakdown status
echo ""
echo "Breakdown status:"
sudo getcert list | grep "status:" | sort | uniq -c

# Verificar por problemas
PROBLEMS=$(sudo getcert list | grep "status:" | grep -v "MONITORING" | wc -l)
if [ $PROBLEMS -gt 0 ]; then
  echo ""
  echo "⚠️ $PROBLEMS certificados necessitam atenção:"
  sudo getcert list | grep -B5 "status:" | grep -E "(Request ID|status:)" | grep -v "MONITORING"
fi

# Verificar avisos expiração
echo ""
echo "Certificados expirando em 30 dias:"
sudo getcert list | grep -A10 "Request ID" | grep "expires:" | \
  while read line; do
    # Analisar e verificar expiração
    # (simplificado - script produção analisaria datas apropriadamente)
    echo "$line"
  done

22.12 Configuração certmonger

Arquivo Configuração Principal

#============================================#
# CONFIGURAÇÃO CERTMONGER
#============================================#

# Localização config
/etc/certmonger/certmonger.conf

# Localização banco dados (certificados rastreados)
/var/lib/certmonger/

# Listar CAs configuradas
sudo getcert list-cas

# Adicionar CA customizada
sudo getcert add-ca -c my-ca \
  -e '/usr/local/bin/my-ca-submit.sh'

# Remover CA
sudo getcert remove-ca -c my-ca

22.13 Melhores Práticas

Melhores Práticas certmonger

✅ **Sempre usar comandos post-save** (flag -C) para recarregar serviços
✅ **Rastrear todos certificados produção** com certmonger
✅ **Monitorar status semanalmente** com `getcert list`
✅ **Testar renovação** antes expiração com `resubmit`
✅ **Usar modo verbose** (-v) ao fazer solução de problemas
✅ **Configurar monitoramento** para status CA_UNREACHABLE
✅ **Documentar IDs requisição** em seu inventário certificados
✅ **Usar IPA/certmonger para certificados internos** e certbot para Let's Encrypt público
✅ **Manter logs certmonger** para trilha auditoria
✅ **Testar comandos post-save** independentemente antes uso

O Que Rastrear com certmonger

# ✅ RASTREAR com certmonger:
- Certificados servidor web (Apache, NGINX)
- Certificados servidor email (Postfix, Dovecot)
- Certificados servidor LDAP (OpenLDAP)
- Certificados aplicação (APIs, microserviços)
- Certificados serviço (qualquer serviço TLS-habilitado)

# ❌ NÃO rastrear com certmonger:
- Certificados raiz CA (gerenciados separadamente)
- Certificados cliente para usuários (ciclo vida diferente)
- Certificados teste/temporários
- Certificados que você gerencia com outras ferramentas (certbot)

22.14 certmonger vs certbot

Quando Usar Qual?

Recomendação:

• Interno/Empresarial: Usar certmonger + FreeIPA
• Público/Simples: Usar certbot (mas saber que requer EPEL)
• Certificados públicos em qualquer versão do RHEL: use certbot para Let’s Encrypt

22.15 Cenários Avançados

Cenário 1: Renovação Certificado Alta Disponibilidade

# Múltiplos servidores com mesmo serviço

# 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: Mesma configuração
# Resultado: Cada servidor gerencia seu próprio cert independentemente
# Ou: Usar cert compartilhado (copiar arquivos, não recomendado)

Cenário 2: Certificado Wildcard

# Solicitar wildcard do 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"

Cenário 3: Chaves EC (Elliptic Curve)

# Solicitar com chave 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  # ou nistp384, nistp521

22.16 Conclusões Chave

1. certmonger é a automatização de certificados do RHEL
2. Configure e esqueça - Renovação automática
3. Funciona melhor com FreeIPA, CAs internas e renovações baseadas em helpers
4. Comandos pós-salvamento recarregam serviços automaticamente
5. Rastreia expiração e renova a 2/3 do tempo de vida
6. Status MONITORING significa que tudo está bem
7. getcert list é sua principal ferramenta de monitoramento

Cartão de Referência Rápida

┌──────────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA DO CERTMONGER                                  │
├──────────────────────────────────────────────────────────────────┤
│ Instalar:        dnf install certmonger                          │
│ Iniciar:         systemctl enable --now certmonger               │
│                                                                  │
│ Solicitar:       getcert request -f cert -k key -c <CA>          │
│ Solicitar (IPA): ipa-getcert request -f cert -k key -K principal │
│ Listar:          getcert list                                    │
│ Status:          getcert list -f /path/to/cert.crt               │
│ Reenviar:        getcert resubmit -f /path/to/cert.crt           │
│ Parar rastreio:  getcert stop-tracking -f /path/to/cert.crt      │
│                                                                  │
│ Status:          MONITORING = ✅ Bom                             │
│                  CA_UNREACHABLE = ❌ Verificar IPA/CA            │
│                  CA_REJECTED = ❌ Verificar principal/permissões │
│                                                                  │
│ Logs:            journalctl -u certmonger -f                     │
│ Renovação:       Automática a 2/3 do tempo de vida do cert       │
│ Pós-save:        -C "systemctl reload <serviço>"                 │
└──────────────────────────────────────────────────────────────────┘

✅ Ferramenta nativa RHEL (suportada Red Hat)
✅ Perfeita para integração FreeIPA
✅ Melhor encaixe para FreeIPA e fluxos de renovação com rastreamento

🧪 Laboratório Prático

Lab 11: Fundamentos do certmonger

Automatize renovação de certificados com certmonger

• 📁 Localização: labs/pt_BR/11-certmonger-basics/
• ⏱️ Tempo: 30-35 minutos
• 🎯 Nível: Intermediário

Navegação do Capítulo

Capítulo 23: Mergulho Profundo em Crypto-Policies

Recurso Revolucionário: Crypto-policies RHEL 8+ fornecem configuração criptográfica system-wide. Domine isto e você controlará segurança em todas aplicações com um comando.

23.1 O Problema que crypto-policies Resolvem

Antes das Crypto-Policies (RHEL 7)

Configurar segurança individualmente para CADA aplicação:

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

... e mais de 20 aplicações!

Resultado: Segurança inconsistente, pesadelo de configuração

Após Crypto-Policies (RHEL 8/9/10)

✅ Definir UMA política system-wide
✅ Todas aplicações automaticamente cumprem
✅ Segurança consistente em todo sistema
✅ Mudar política em segundos, não horas

Mudança radical para gerenciamento empresarial!

23.2 Como Crypto-Policies Funcionam

Arquitetura

┌──────────────────────────────────────────────────┐
│       update-crypto-policies --set DEFAULT       │
│              (Comando administrador)             │
└───────────────────────┬──────────────────────────┘
                        │
                        ▼
┌──────────────────────────────────────────────────┐
│  /etc/crypto-policies/back-ends/                 │
│  (Arquivos config gerados para cada biblioteca)  │
│  ├─ opensslcnf.config                            │
│  ├─ gnutls.config                                │
│  ├─ nss.config                                   │
│  ├─ bind.config                                  │
│  └─ ... mais ...                                 │
└───────────────────────┬──────────────────────────┘
                        │
            ┌───────────┼───────────┐
            ▼           ▼           ▼
         OpenSSL     GnuTLS        NSS
            ↓           ↓           ↓
         Apache      NGINX       Firefox
         Postfix     vsftpd      Thunderbird
         OpenSSH     wget        Java apps

Insight Chave: Aplicações leem de arquivos back-end, não diretamente da política!

23.3 As Quatro Políticas Principais

Comparação Políticas

Detalhes Política DEFAULT

# Segurança e compatibilidade balanceadas
Protocolos:
  - TLS 1.2
  - TLS 1.3

Tamanhos Chave Mínimos:
  - RSA: 2048 bits
  - DH: 2048 bits
  - ECC: secp256r1 (P-256)

Cifras Permitidas:
  - AES-128-GCM
  - AES-256-GCM
  - ChaCha20-Poly1305
  - AES-128-CBC
  - AES-256-CBC

Algoritmos Assinatura:
  - SHA-256
  - SHA-384
  - SHA-512

Bloqueados:
  - TLS 1.0, 1.1
  - MD5
  - Assinaturas SHA-1
  - 3DES, RC4, DES
  - RSA < 2048 bits
  - Cifras export

23.4 Visualizando e Mudando Políticas

Comandos Básicos

#============================================#
# OPERAÇÕES BÁSICAS CRYPTO-POLICY
#============================================#

# Ver política atual
update-crypto-policies --show
# Saída: DEFAULT

# Listar políticas disponíveis
ls /usr/share/crypto-policies/policies/
# DEFAULT.pol  FUTURE.pol  LEGACY.pol  FIPS.pol

# Definir política
sudo update-crypto-policies --set FUTURE

# Você DEVE reiniciar serviços para mudanças surtirem efeito!
sudo systemctl restart httpd nginx postfix slapd

# Ou reiniciar (garante que tudo pega as mudanças)
sudo reboot

O Que Acontece Quando Você Muda Política

#============================================#
# POR TRÁS DAS CENAS
#============================================#

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

# Mudar
sudo update-crypto-policies --set FUTURE

# Atualizações geradas:
ls -l /etc/crypto-policies/back-ends/
# -rw-r--r--. opensslcnf.config    ← Atualizado!
# -rw-r--r--. gnutls.config        ← Atualizado!
# -rw-r--r--. nss.config           ← Atualizado!
# -rw-r--r--. bind.config          ← Atualizado!
# ... todos back-ends atualizados ...

# Ver config OpenSSL
cat /etc/crypto-policies/back-ends/opensslcnf.config
# Mostra configuração OpenSSL real aplicada

23.5 Subpolíticas (RHEL 9+)

Modificadores Política

RHEL 9 introduziu subpolíticas - ajuste fino políticas existentes!

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

# Política base com modificador
sudo update-crypto-policies --set DEFAULT:NO-SHA1

# Múltiplos modificadores
sudo update-crypto-policies --set DEFAULT:NO-SHA1:GOST

# Módulos subpolítica disponíveis
ls /usr/share/crypto-policies/policies/modules/
# AD-SUPPORT.pmod
# GOST.pmod
# NO-CAMELLIA.pmod
# NO-SHA1.pmod
# NO-ENFORCE-EMS.pmod
# ...e mais

# Ver detalhes módulo
cat /usr/share/crypto-policies/policies/modules/NO-SHA1.pmod

Subpolíticas Comuns:

23.6 Criando Módulos Política Customizados

Exemplo Módulo Customizado

#============================================#
# CRIAR MÓDULO POLÍTICA CUSTOMIZADO
#============================================#

# Criar módulo customizado
sudo vi /etc/crypto-policies/policies/modules/CUSTOM-SECURITY.pmod

# Conteúdo exemplo:
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 serviços
sudo systemctl restart httpd nginx postfix

# Verificar
openssl ciphers -v | grep -E "RSA|DH"

23.7 Overrides Por Aplicação

Quando Sobrescrever

Às vezes UMA aplicação necessita configurações diferentes da política sistema:

Exemplo: Aplicação legada necessita TLS 1.1, mas sistema usa DEFAULT

Override Apache

#============================================#
# OVERRIDE CRYPTO-POLICY APACHE
#============================================#

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

# Opção 1: Incluir crypto-policy, então sobrescrever
Include /etc/crypto-policies/back-ends/httpd.config

# Então adicionar overrides:
SSLProtocol all -SSLv3  # Re-habilitar TLS 1.0/1.1

# Opção 2: Optar completamente por fora
# Não incluir arquivo crypto-policy
# Configurar manualmente tudo:
SSLProtocol TLSv1.1 TLSv1.2 TLSv1.3
SSLCipherSuite HIGH:!aNULL:!MD5

# ⚠️ Aviso: Você agora gerencia TLS Apache manualmente
# Mudanças crypto-policy sistema não afetarão Apache

Melhor Abordagem: Criar módulo política customizado em vez de overrides por app!

23.8 Testando Impacto Política

Antes de Mudar Política

#============================================#
# TESTAR IMPACTO MUDANÇA POLÍTICA
#============================================#

# 1. Documentar estado atual
update-crypto-policies --show > /tmp/current-policy.txt
systemctl list-units --type=service --state=running > /tmp/running-services.txt

# 2. Testar aplicações
curl https://localhost/
psql -h localhost  # etc.

# 3. Mudar política em sistema teste primeiro
sudo update-crypto-policies --set FUTURE

# 4. Reiniciar serviços
sudo systemctl restart httpd nginx postfix

# 5. Testar completamente
./test-all-services.sh

# 6. Se problemas: Reverter
sudo update-crypto-policies --set DEFAULT

# 7. Se bem-sucedido: Documentar e implantar em produção

23.9 Impacto Política em Certificados

O Que Políticas Controlam

Crypto-policies afetam:

• ✅ Versões protocolo TLS permitidas
• ✅ Suites cifra disponíveis
• ✅ Tamanhos chave mínimos aceitos
• ✅ Algoritmos assinatura permitidos
• ✅ Parâmetros Diffie-Hellman
• ✅ Rigor validação certificado

Crypto-policies NÃO afetam:

• ❌ Quais certificados usar (ainda configurado por serviço)
• ❌ Localizações arquivo certificado
• ❌ CA repositório de confiança (isso é update-ca-trust)
• ❌ Emissão certificado

Matriz Compatibilidade Certificado

23.10 Solução de Problemas Crypto-Policies

Problemas Comuns

Problema 1: Aplicação Falha Após Mudança Política

# Sintoma
sudo update-crypto-policies --set FUTURE
sudo systemctl restart httpd
# httpd falha ao iniciar

# Diagnóstico
sudo journalctl -xe -u httpd | grep -i cipher

# Causa comum: Aplicação tem cifras fracas codificadas

# Solução 1: Reverter política
sudo update-crypto-policies --set DEFAULT

# Solução 2: Atualizar config aplicação
# Remover especificações cipher codificadas

# Solução 3: Criar módulo política customizado

Problema 2: “No Shared Cipher”

# Sintoma: Clientes não conseguem conectar

# Testar
openssl s_client -connect server:443

# Se mostra "no shared cipher":

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

# Testar capacidades cliente
openssl s_client -connect server:443 -cipher 'ALL' -tls1_2

# Correção temporária (não recomendado longo prazo):
sudo update-crypto-policies --set LEGACY

# Correção apropriada: Atualizar cliente para suportar TLS 1.2+ e cifras modernas

Problema 3: Política Não Parece Aplicar

# Verificar se aplicação está sobrescrevendo política

# Apache
grep -r "SSLProtocol\|SSLCipherSuite" /etc/httpd/
# Se encontrado: App está sobrescrevendo política

# NGINX
grep -r "ssl_protocols\|ssl_ciphers" /etc/nginx/
# Se encontrado: App está sobrescrevendo política

# Solução: Remover overrides, deixar crypto-policy lidar com isso
# Ou: Documentar por que override é necessário

23.11 Melhores Práticas

Recomendações

✅ **Usar política DEFAULT** para maioria ambientes
✅ **Testar antes de implantar** novas políticas
✅ **Documentar escolhas política** e razões
✅ **Reiniciar serviços** após mudanças política
✅ **Evitar overrides por app** quando possível
✅ **Usar subpolíticas** (RHEL 9+) para ajuste fino
✅ **Monitorar por compatibilidade** problemas
✅ **Manter LEGACY temporária** se usada
✅ **Planejar migrações** ao mudar políticas
✅ **Atualizar clientes** em vez de enfraquecer política

Quando Usar Cada Política

DEFAULT:

• ✅ Maioria ambientes produção
• ✅ Segurança/compatibilidade balanceadas
• ✅ Ponto inicial recomendado
• ✅ Testada e mantida pela Red Hat

LEGACY:

• ⚠️ Temporária apenas durante migrações!
• ⚠️ Suportando clientes muito antigos
• ⚠️ Testando problemas compatibilidade
• ❌ Nunca longo prazo!

FUTURE:

• ✅ Ambientes alta segurança
• ✅ Todos clientes são modernos
• ✅ Quer configurações mais fortes
• ✅ Planejando para padrões futuros

FIPS:

• ✅ Conformidade federal requerida
• ✅ Contratos governo
• ✅ Indústrias regulamentadas
• ✅ Requisitos certificação

23.12 Mergulho Profundo Política FIPS

Habilitando Modo FIPS

#============================================#
# HABILITAR MODO FIPS
#============================================#

# Verificar status atual
fips-mode-setup --check
# FIPS mode is disabled.

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

# DEVE reiniciar
sudo reboot

# Verificar após reboot
fips-mode-setup --check
# FIPS mode is enabled.

# Crypto-policy automaticamente definida para FIPS
update-crypto-policies --show
# FIPS

Requisitos Modo FIPS:

• Deve ser habilitado na instalação OU com fips-mode-setup
• Requer reboot
• Afeta sistema inteiro
• Apenas algoritmos aprovados FIPS disponíveis
• Impacto desempenho (~10-20% mais lento)

Especificações Política FIPS

# O que política FIPS permite:
✅ TLS 1.2, 1.3
✅ RSA 2048+ bits
✅ AES-128, AES-256 (modo GCM)
✅ SHA-256, SHA-384, SHA-512
✅ Troca chave ECDHE

# O que FIPS bloqueia:
❌ TLS 1.0, 1.1
❌ RSA < 2048 bits
❌ 3DES, RC4, DES
❌ MD5, SHA-1
❌ Algoritmos não aprovados
❌ Cifras modo CBC (em alguns casos)

23.13 Monitoramento e Auditoria

Verificar Conformidade Política

#============================================#
# VERIFICAR CONFORMIDADE CRYPTO-POLICY
#============================================#

# Política atual
update-crypto-policies --show

# Quais aplicações usam crypto-policies?
ls -l /etc/crypto-policies/back-ends/

# Verificar OpenSSL segue política
openssl ciphers -v | head -20

# Verificar config aplicação específica
# Apache
cat /etc/crypto-policies/back-ends/httpd.config

# Testar conexão real
openssl s_client -connect localhost:443 -tls1_3

# Verificar sem overrides
grep -r "SSLProtocol\|SSLCipherSuite" /etc/httpd/ | grep -v crypto-policies
# Deveria estar vazio ou comentado

23.14 Fluxo Trabalho Solução de Problemas

Abordagem Sistemática

Aplicação falha após mudança política?
    │
    ├─ Passo 1: Identificar erro
    │   └─ Verificar logs: journalctl -xe
    │
    ├─ Passo 2: Verificar política ativa
    │   └─ update-crypto-policies --show
    │
    ├─ Passo 3: Testar com LEGACY
    │   └─ sudo update-crypto-policies --set LEGACY
    │   └─ Se funciona → problema cipher/protocolo
    │
    ├─ Passo 4: Identificar incompatibilidade
    │   └─ openssl s_client -cipher 'ALL' -tls1
    │   └─ Descobrir o que cliente/servidor necessita
    │
    ├─ Passo 5: Escolher solução
    │   ├─ A) Atualizar cliente (melhor)
    │   ├─ B) Criar módulo customizado (bom)
    │   └─ C) Override por app (último recurso)
    │
    └─ Passo 6: Documentar e implantar
        └─ Por que override necessário, plano para remover

23.15 Conclusões Chave

1. Crypto-policies são apenas RHEL 8+ (não no RHEL 7)
2. Política DEFAULT é recomendada para maioria casos
3. Mudanças requerem restarts serviço para surtir efeito
4. Afeta TODAS aplicações crypto system-wide
5. Subpolíticas fornecem ajuste fino (RHEL 9+)
6. Evitar overrides por app quando possível
7. Testar antes de implantar novas políticas
8. LEGACY é apenas temporária!

Cartão de Referência Rápida

┌──────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA CRYPTO-POLICIES                            │
├──────────────────────────────────────────────────────────────┤
│ Disponível:   Apenas RHEL 8, 9, 10 (não RHEL 7)              │
│                                                              │
│ Ver:          update-crypto-policies --show                  │
│ Definir:      sudo update-crypto-policies --set <POLÍTICA>   │
│ Políticas:    DEFAULT, LEGACY, FUTURE, FIPS                  │
│                                                              │
│ Subpolítica:  update-crypto-policies --set DEFAULT:NO-SHA1   │
│               (apenas RHEL 9+)                               │
│                                                              │
│ Back-ends:    /etc/crypto-policies/back-ends/                │
│ Módulos:      /usr/share/crypto-policies/policies/modules/   │
│                                                              │
│ Após mudança: systemctl restart <serviços>                   │
│               OU reboot                                      │
│                                                              │
│ DEFAULT:      TLS 1.2+, RSA 2048+, Sem SHA-1                 │
│ LEGACY:       TLS 1.0+, permite fracos (apenas temporário!)  │
│ FUTURE:       TLS 1.2+, RSA 3072+, mais restritiva           │
│ FIPS:         Conformidade federal (requer modo FIPS)        │
└──────────────────────────────────────────────────────────────┘

⚠️ RHEL 7 não tem crypto-policies (apenas config manual)
✅ DEFAULT funciona para 95% dos ambientes

🧪 Laboratório Prático

Lab 12: Crypto-Policies

Entenda e configure crypto-policies em todo o sistema

• 📁 Localização: labs/pt_BR/12-crypto-policies/
• ⏱️ Tempo: 25-30 minutos
• 🎯 Nível: Intermediário

Navegação do Capítulo

Capítulo 24: Let’s Encrypt e certbot

Certificados Públicos Gratuitos: Let’s Encrypt fornece certificados gratuitos e automatizados para websites públicos. Aprenda como usá-lo no RHEL com certbot.

24.1 O Que é Let’s Encrypt?

Let’s Encrypt é uma autoridade certificadora (CA) gratuita, automatizada e aberta.

Recursos Chave:

• ✅ Certificados gratuitos (sem custo)
• ✅ Emissão automatizada (via protocolo ACME)
• ✅ Auto-renovação (a cada 60-90 dias)
• ✅ Amplamente confiável (em todos navegadores principais)
• ✅ Validação domínio (certificados DV)

Limitações:

• ❌ Apenas domínios públicos (deve ser acessível pela internet para validação)
• ❌ Validade 90 dias (curta vida, requer automatização)
• ❌ Apenas Domain Validation (sem Organization ou Extended Validation)
• ❌ Sem wildcard com HTTP-01 (requer desafio DNS-01)

24.2 Let’s Encrypt no RHEL: ACME público e alternativas nativas

Método 1: certbot (Tradicional)

⚠️ CRÍTICO: EPEL Requerido

certbot NÃO está disponível nos repositórios oficiais RHEL.

Requer EPEL (Extra Packages for Enterprise Linux), um repositório mantido pela comunidade que NÃO é oficialmente suportado pela Red Hat.

Para Ambientes Produção Empresarial:

• Considere FreeIPA com certmonger (Capítulo 19)
• Ou CA comercial com certmonger (Capítulo 22)
• Ou gerenciamento certificado manual

EPEL é adequado para:

• Ambientes desenvolvimento/teste
• Implantações pequenas onde risco EPEL é aceitável
• Situações onde certificados gratuitos superam preocupações suporte

Ferramenta certbot:

• Automatização completa
• Plugins Apache/NGINX
• Configuração automática
• Timers renovação
• ⚠️ Requer EPEL

Método 2: certmonger para CAs internas/privadas

Solução RHEL Nativa:

• ✅ Sem necessidade EPEL
• ✅ Suportado Red Hat
• ✅ Melhor encaixe para fluxos de FreeIPA / IdM e CA local
• ⏸️ Configuração manual do servidor web (sem plugins Apache/NGINX)
• ❌ Não é substituto direto do certbot para o Let’s Encrypt público

Usaremos certbot para o Let’s Encrypt público e certmonger para fluxos internos nativos.

24.3 Instalação certbot

RHEL 7

#============================================#
# INSTALAR CERTBOT NO RHEL 7 (REQUER EPEL!)
#============================================#

# ⚠️ AVISO: Habilitando repositório terceiros

# Passo 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

# Passo 2: Instalar certbot
sudo yum install certbot python2-certbot-apache python2-certbot-nginx -y

# Verificar
certbot --version

RHEL 8

#============================================#
# INSTALAR CERTBOT NO RHEL 8 (REQUER EPEL!)
#============================================#

# ⚠️ AVISO: Habilitando repositório terceiros

# Passo 1: Habilitar EPEL
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y

# Ou se você tem subscription:
sudo dnf install epel-release -y

# Passo 2: Instalar certbot
sudo dnf install certbot python3-certbot-apache python3-certbot-nginx -y

# Verificar
certbot --version

RHEL 9/10

#============================================#
# INSTALAR CERTBOT NO RHEL 9/10 (REQUER EPEL!)
#============================================#

# ⚠️ AVISO: Habilitando repositório terceiros

# Passo 1: Habilitar EPEL
sudo dnf install epel-release -y

# Passo 2: Instalar certbot
sudo dnf install certbot python3-certbot-apache python3-certbot-nginx -y

# Verificar
certbot --version

Lembrar: EPEL é suportado pela comunidade. Para produção empresarial, considere FreeIPA + certmonger (solução RHEL nativa).

24.4 Uso certbot - Apache

Configuração Apache Automática

#============================================#
# CERTBOT COM APACHE (AUTOMATIZADO!)
#============================================#

# Pré-requisitos:
# - Apache instalado e rodando
# - Porta 80 acessível da internet
# - Domínio resolve para este servidor
# - Repositório EPEL habilitado

# Obter certificado e auto-configurar Apache
sudo certbot --apache -d www.example.com -d example.com

# certbot vai:
# 1. Gerar certificado do Let's Encrypt
# 2. Configurar automaticamente SSL Apache
# 3. Configurar redirect HTTP→HTTPS
# 4. Configurar auto-renovação

# Prompts interativos:
# - Endereço email (para avisos renovação)
# - Concordar com ToS
# - Redirecionar HTTP para HTTPS? (escolher yes)

# Não-interativo (automatização):
sudo certbot --apache \
  -d www.example.com \
  -d example.com \
  --non-interactive \
  --agree-tos \
  --email admin@example.com \
  --redirect

# Localização certificado:
# /etc/letsencrypt/live/www.example.com/fullchain.pem
# /etc/letsencrypt/live/www.example.com/privkey.pem

24.5 Uso certbot - NGINX

Configuração NGINX Automática

#============================================#
# CERTBOT COM NGINX (AUTOMATIZADO!)
#============================================#

# Pré-requisitos:
# - NGINX instalado e rodando
# - Porta 80 acessível
# - Domínio resolve para servidor

# Obter e configurar
sudo certbot --nginx -d api.example.com

# Não-interativo
sudo certbot --nginx \
  -d api.example.com \
  --non-interactive \
  --agree-tos \
  --email admin@example.com \
  --redirect

# certbot atualiza config NGINX automaticamente!
# Nenhuma configuração SSL manual necessária

24.6 Modo Manual certbot (Standalone)

Sem Plugin Servidor Web

#============================================#
# CERTBOT STANDALONE (SEM PLUGIN)
#============================================#

# Usar quando:
# - Servidor web não é Apache/NGINX
# - Quer controle manual sobre config
# - Usando servidor web customizado

# Obter apenas certificado (não configura servidor)
sudo certbot certonly --standalone \
  -d app.example.com \
  --non-interactive \
  --agree-tos \
  --email admin@example.com

# Certificado salvo em:
# /etc/letsencrypt/live/app.example.com/fullchain.pem
# /etc/letsencrypt/live/app.example.com/privkey.pem

# Configurar manualmente seu serviço para usá-lo
# Exemplo Apache:
# SSLCertificateFile /etc/letsencrypt/live/app.example.com/fullchain.pem
# SSLCertificateKeyFile /etc/letsencrypt/live/app.example.com/privkey.pem

24.7 Renovação

Renovação Automática

#============================================#
# AUTO-RENOVAÇÃO CERTBOT
#============================================#

# certbot automaticamente configura timer renovação
systemctl list-timers | grep certbot
# Deveria mostrar: certbot-renew.timer

# Ver detalhes timer
systemctl status certbot-renew.timer

# Testar renovação (dry run - não renova realmente)
sudo certbot renew --dry-run

# Forçar renovação real (se necessário)
sudo certbot renew --force-renewal

# Verificar expiração certificado
sudo certbot certificates

# Renovação executa duas vezes diariamente
# Renova certificados expirando dentro de 30 dias

Hooks Renovação

#============================================#
# HOOKS RENOVAÇÃO (COMANDOS DEPLOY)
#============================================#

# Adicionar hook para recarregar serviço após renovação
sudo certbot renew --deploy-hook "systemctl reload nginx"

# Ou criar script 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 em /etc/letsencrypt/renewal-hooks/:
# - pre/: Executar antes renovação
# - post/: Executar após renovação (mesmo se falhou)
# - deploy/: Executar apenas após renovação bem-sucedida

24.8 Certificados Wildcard

Desafio DNS-01 Requerido