Capítulo 28: Erros Comuns de Certificados no RHEL

Aprenda da Dor dos Outros: Este capítulo cataloga os erros de certificados mais comuns no RHEL, organizados por tipo e versão. Quando encontrar um erro, procure aqui primeiro!

28.1 Usando Este Capítulo

Como usar este guia de solução de problemas:

1. Viu um erro? Busque neste capítulo pela mensagem de erro
2. Serviço não inicia? Verifique Seção 28.3 (Erros de Configuração)
3. Conexão falha? Verifique Seção 28.4 (Erros de Validação)
4. Após atualização RHEL? Verifique Seção 28.7 (Específico por Versão)
5. Não tem certeza? Use a metodologia do Capítulo 27

28.2 Erros Mais Comuns (Top 10)

Tabela de Referência Rápida

28.3 Erros de Configuração

Erro: “SSLCertificateFile: file does not exist or is empty”

Serviços: Apache

Sintoma:

AH00526: Syntax error on line 100 of /etc/httpd/conf.d/ssl.conf:
SSLCertificateFile: file '/etc/pki/tls/certs/server.crt' does not exist or is empty

Diagnóstico:

ls -l /etc/pki/tls/certs/server.crt
# ls: cannot access '/etc/pki/tls/certs/server.crt': No such file or directory

Soluções:

# Solução 1: Corrigir caminho na config
sudo vi /etc/httpd/conf.d/ssl.conf
# Corrigir o caminho SSLCertificateFile

# Solução 2: Instalar certificado no local esperado
sudo cp server.crt /etc/pki/tls/certs/

# Solução 3: Restaurar do backup
sudo cp /var/backups/certificates/latest/server.crt /etc/pki/tls/certs/

Erro: “Private key does not match this certificate”

Serviços: Apache, NGINX, Postfix

Sintoma:

SSL Library Error: error:0B080074:x509 certificate routines:
X509_check_private_key:key values mismatch

Diagnóstico:

# Verificar se cert e chave coincidem
CERT_MOD=$(openssl x509 -noout -modulus -in /etc/pki/tls/certs/server.crt | openssl md5)
KEY_MOD=$(openssl rsa -noout -modulus -in /etc/pki/tls/private/server.key | openssl md5)

echo "Cert: $CERT_MOD"
echo "Key:  $KEY_MOD"
# Se diferentes → desajuste!

Causa: Certificado foi emitido para uma chave privada diferente

Solução:

# Regenerar CSR com a chave CORRETA
openssl req -new -key /etc/pki/tls/private/server.key -out server.csr \
  -subj "/CN=server.example.com"

# Submeter CSR para CA, obter novo certificado
# Instalar novo certificado

Erro: “Permission denied” na Chave Privada

Serviços: Todos

Sintoma:

Permission denied: Can't open PEM file '/etc/pki/tls/private/server.key'

Diagnóstico:

ls -l /etc/pki/tls/private/server.key
# -rw-r--r--. 1 root root  ← Muito permissivo!

# Verificar se usuário do serviço pode ler
sudo -u apache cat /etc/pki/tls/private/server.key >/dev/null
# Permission denied

Solução:

# Definir permissões corretas
sudo chmod 600 /etc/pki/tls/private/server.key
sudo chown apache:apache /etc/pki/tls/private/server.key

# Para serviços que necessitam propriedade específica:
# OpenLDAP:
sudo chown ldap:ldap /etc/openldap/certs/ldap.key

# PostgreSQL:
sudo chown postgres:postgres /var/lib/pgsql/data/server.key

# MySQL:
sudo chown mysql:mysql /etc/mysql/certs/server.key

28.4 Erros de Validação

Erro: “certificate verify failed”

Serviços: Todos

Erro Completo:

SSL_connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

Causas Comuns:

Causa 1: Certificado autoassinado não confiável

# Diagnóstico
openssl verify /etc/pki/tls/certs/server.crt
# error 18: self signed certificate

# Solução: Adicionar ao repositório de confiança
sudo cp server.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Causa 2: Certificado CA faltando

# Diagnóstico
openssl verify /etc/pki/tls/certs/server.crt
# error 20: unable to get local issuer certificate

# Solução: Adicionar certificado CA
sudo cp ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Causa 3: Certificado intermediário faltando

# Diagnóstico
openssl s_client -connect server.example.com:443 -showcerts
# Verify return code: 21 (unable to verify the first certificate)

# Solução: Incluir intermediário no arquivo cert
cat server.crt intermediate.crt > /etc/pki/tls/certs/server-chain.crt
# Atualizar config do serviço para usar server-chain.crt

Erro: “certificate has expired”

Serviços: Todos

Sintoma:

SSL_connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate has expired

Diagnóstico:

# Verificar expiração
openssl x509 -in /etc/pki/tls/certs/server.crt -noout -dates
# notAfter=Jan 15 23:59:59 2024 GMT  ← No passado!

Soluções:

# Solução 1: Se certmonger rastreando
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/server.crt

# Solução 2: Renovação manual
# Gerar novo CSR, submeter para CA, instalar novo cert

# Solução 3: Emergência - autoassinado temporário
sudo /usr/local/bin/emergency-self-signed-cert.sh $(hostname -f)
# Veja Capítulo 33 para procedimentos de emergência

Erro: “hostname (or IP address) does not match certificate”

Serviços: Todos (especialmente navegadores)

Erro Completo:

SSL: certificate subject name 'server.example.com' does not match target host name 'www.example.com'

Diagnóstico:

# Verificar CN e SANs do certificado
openssl x509 -in /etc/pki/tls/certs/server.crt -noout -subject -ext subjectAltName

# Saída:
# subject=CN=server.example.com
# X509v3 Subject Alternative Name:
#     DNS:server.example.com
#
# Problema: Acessando www.example.com mas cert tem apenas server.example.com

Solução:

# Reemitir certificado com SANs corretos
openssl req -new -key server.key -out server.csr \
  -subj "/CN=www.example.com" \
  -addext "subjectAltName=DNS:www.example.com,DNS:server.example.com,DNS:example.com"

# Ou usar wildcard: *.example.com

28.5 Erros de Cadeia de Confiança

Erro: “unable to get local issuer certificate”

Código Erro: 20

Sintoma:

openssl verify /etc/pki/tls/certs/server.crt
# error 20 at 0 depth lookup: unable to get local issuer certificate

Causa: A CA que assinou o certificado não está no repositório de confiança do sistema

Solução:

# Obter certificado CA (da CA ou extrair da cadeia)
# Adicionar ao repositório de confiança
sudo cp issuing-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# Verificar
openssl verify /etc/pki/tls/certs/server.crt
# /etc/pki/tls/certs/server.crt: OK

Erro: “unable to verify the first certificate”

Código Erro: 21

Sintoma:

openssl s_client -connect server.example.com:443
# Verify return code: 21 (unable to verify the first certificate)

Causa: Servidor enviando certificado sem intermediário(s)

Diagnóstico:

# Contar certificados na cadeia
openssl s_client -connect server.example.com:443 -showcerts 2>&1 | \
  grep -c "BEGIN CERTIFICATE"
# Se mostra 1: Apenas cert servidor (intermediário faltando!)
# Deveria mostrar 2+: Servidor + intermediário(s)

Solução:

# Criar bundle de certificado com intermediário
cat server.crt intermediate.crt > /etc/pki/tls/certs/server-bundle.crt

# Atualizar config do serviço
# Apache:
SSLCertificateFile /etc/pki/tls/certs/server-bundle.crt

# Ou usar SSLCertificateChainFile (Apache):
SSLCertificateChainFile /etc/pki/tls/certs/intermediate.crt

# NGINX:
ssl_certificate /etc/pki/tls/certs/server-bundle.crt;

# Recarregar serviço

28.6 Erros de Crypto-Policy (RHEL 8/9/10)

Erro: “no shared cipher”

Serviços: Todos (RHEL 8/9/10)

Sintoma:

SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

Diagnóstico:

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

# Testar conexão mostrando ciphers
openssl s_client -connect server:443 -cipher 'ALL'

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

Causas Comuns e Soluções:

Causa 1: Cliente muito antigo (necessita TLS 1.0)

# Teste temporário com LEGACY
sudo update-crypto-policies --set LEGACY
sudo systemctl restart httpd

# Se funciona → problema compatibilidade cliente
# Correção apropriada: Atualizar cliente ou criar módulo política customizado

Causa 2: Crypto-policy do servidor muito restritiva

# Se usando política FUTURE com clientes antigos
update-crypto-policies --show
# FUTURE

# Temporário: Usar DEFAULT
sudo update-crypto-policies --set DEFAULT
sudo systemctl restart services

Erro: “SSL routines:tls_post_process_client_hello:no shared cipher”

Serviços: Todos (RHEL 9+)

Sintoma: Cliente não consegue negociar cipher com servidor

Solução:

# RHEL 9: Verificar se cliente usando ciphers muito antigos
# Pode necessitar política LEGACY temporariamente

# Verificar configuração do servidor para overrides
grep -r "SSLCipherSuite\|ssl_ciphers" /etc/httpd/ /etc/nginx/

# Se ciphers codificados encontrados, removê-los
# Deixar crypto-policy lidar com isso

28.7 Erros Específicos por Versão RHEL

Erros Específicos RHEL 7

Erro: “dh key too small”

SSL routines:ssl3_check_cert_and_algorithm:dh key too small

Causa: Parâmetros DH padrão muito pequenos para clientes modernos

Solução:

# Gerar parâmetros DH mais fortes
openssl dhparam -out /etc/pki/tls/dhparams.pem 2048

# Apache: Adicionar a ssl.conf
SSLOpenSSLConfCmd DHParameters "/etc/pki/tls/dhparams.pem"

# NGINX: Adicionar à config
ssl_dhparam /etc/pki/tls/dhparams.pem;

Erros Específicos RHEL 8/9/10

Erro: “ca md too weak” (RHEL 9+)

error 3 at 0 depth lookup: CA md too weak

Causa: Certificado tem assinatura SHA-1 (bloqueado no RHEL 9+)

Diagnóstico:

openssl x509 -in server.crt -noout -text | grep "Signature Algorithm"
# Signature Algorithm: sha1WithRSAEncryption  ← Problema!

Solução:

# Reemitir certificado com SHA-256 ou melhor
# Sem workaround - SHA-1 é bloqueado por segurança

# Solicitar novo certificado
openssl req -new -key server.key -out server.csr -sha256 \
  -subj "/CN=server.example.com"

Erro: “Provider ‘legacy’ could not be loaded” (RHEL 9+)

openssl: error while loading shared libraries: Provider 'legacy' could not be loaded

Causa: Tentando usar algoritmo legado sem provider

Solução:

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

# Ou atualizar para usar algoritmo moderno
openssl sha256 file.txt

28.8 Erros SELinux

Erro: SELinux Prevenindo Acesso ao Certificado

Sintoma:

audit: type=1400 audit(timestamp): avc: denied { read } for pid=1234 comm="httpd"
name="server.key" dev="sda1" ino=12345 scontext=system_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0

Diagnóstico:

# Verificar negações AVC
sudo ausearch -m avc -ts recent | grep cert

# Verificar contexto SELinux
ls -Z /etc/pki/tls/certs/server.crt
ls -Z /etc/pki/tls/private/server.key

Solução:

# Corrigir contexto SELinux
sudo restorecon -Rv /etc/pki/tls/

# Verificar
ls -Z /etc/pki/tls/certs/server.crt
# system_u:object_r:cert_t:s0  ← Correto

# Se ainda houver problemas, verificar se SELinux está bloqueando
sudo ausearch -m avc -ts recent

# Gerar política se necessário
sudo ausearch -m avc -ts recent | audit2allow -M mycert
sudo semodule -i mycert.pp

28.9 Erros certmonger

Erro: CA_UNREACHABLE

Sintoma:

sudo getcert list
# status: CA_UNREACHABLE

Diagnóstico:

# Verificar conectividade IPA
ipa ping

# Verificar ticket Kerberos
klist

# Verificar serviços IPA
ssh ipa-server "sudo ipactl status"

Soluções:

# Solução 1: Renovar ticket Kerberos
kinit -k host/$(hostname -f)@REALM

# Solução 2: Verificar conectividade de rede
ping ipa.example.com

# Solução 3: Reiniciar certmonger
sudo systemctl restart certmonger

# Solução 4: Reenviar requisição
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/server.crt

Erro: CA_REJECTED

Sintoma:

sudo getcert list
# status: CA_REJECTED
# ca-error: Server unwilling to issue certificate

Causas Comuns:

Causa 1: Principal de serviço não existe

# Verificar se principal existe
ipa service-show HTTP/$(hostname -f)

# Se não encontrado, adicioná-lo
ipa service-add HTTP/$(hostname -f)

# Reenviar
sudo ipa-getcert resubmit -f /etc/pki/tls/certs/server.crt

Causa 2: Host não registrado no IPA

# Verificar registro
ipa host-show $(hostname -f)

# Se não registrado
sudo ipa-client-install

28.10 Erros de Chaves GPG/PGP Legadas

Erro: “skipped PGP-2 keys” ao Importar

Ferramenta: GnuPG (gpg)

Sintoma:

$ gpg --allow-old-cipher-algos --import keyfile.asc
gpg: Total number processed: 2
gpg:     skipped PGP-2 keys: 2

A chave é rejeitada silenciosamente — mesmo com --allow-old-cipher-algos.

Causa: O arquivo de chave contém chaves OpenPGP versão 3 (era PGP 2.x). GnuPG moderno (2.2+) recusa completamente a importação de pacotes de chave v3. Essas chaves tipicamente usam RSA com assinaturas MD5, ambos criptograficamente obsoletos.

Diagnóstico — Inspecionar os pacotes da chave:

gpg --list-packets keyfile.asc

Saída de exemplo:

# off=0 ctb=95 tag=5 hlen=3 plen=930
:key packet: [obsolete version 3]
# off=933 ctb=b4 tag=13 hlen=2 plen=27
:user ID packet: "User Name <user@example.org>"
# off=962 ctb=89 tag=2 hlen=3 plen=277
:signature packet: algo 1, keyid A1B2C3D4E5F60789
        version 3, created 1034280585, md5len 5, sigclass 0x10
        digest algo 1, begin of digest a1 26
        data: [2047 bits]

Os indicadores críticos são:

• :key packet: [obsolete version 3] — formato v3, rejeitado pelo GnuPG moderno
• algo 1 — RSA (criptografar ou assinar)
• digest algo 1 — MD5 (criptograficamente quebrado)
• version 3 na assinatura — formato de assinatura antigo
• sigclass 0x10 — certificação genérica de um ID de usuário

Solução: Não há como “atualizar” uma chave v3. Você deve gerar uma chave moderna nova e aposentar a antiga:

# 1. Gerar uma chave moderna (Ed25519 + Curve25519)
gpg --full-generate-key
#    Escolher: (9) ECC (assinar e criptografar)
#    Curva:    ed25519 (assinatura), cv25519 (criptografia)

# 2. Verificar a nova chave
gpg --list-keys --keyid-format long

# 3. Se ainda controla a chave antiga, assinar cruzado para continuidade de confiança
gpg --default-key OLDKEYID --sign-key NEWKEYID

# 4. Gerar um certificado de revogação para a chave antiga
gpg --output revoke-old.asc --gen-revoke OLDKEYID

# 5. Publicar a nova chave
gpg --send-keys NEWKEYID

# 6. Revogar a chave antiga
gpg --import revoke-old.asc
gpg --send-keys OLDKEYID

Após a migração, atualize todos os sistemas que referenciam a chave antiga (CI/CD, assinatura de pacotes, criptografia de e-mail).

Entendendo a Saída de gpg --list-packets

Ao depurar problemas de chaves GPG, gpg --list-packets mostra a estrutura de pacotes OpenPGP em bruto. Aqui está uma referência completa para interpretar a saída.

Campos do Cabeçalho do Pacote

Cada linha de pacote começa com:

# off=0 ctb=95 tag=5 hlen=3 plen=930

Tags de Pacote (tag=)

IDs de Algoritmo de Chave Pública (algo)

IDs de Algoritmo de Digest (Hash) (digest algo)

Classes de Assinatura (sigclass)

Versões de Pacote de Chave

Campos do Pacote de Assinatura

Para uma assinatura como:

:signature packet: algo 1, keyid A1B2C3D4E5F60789
        version 3, created 1034280585, md5len 5, sigclass 0x10
        digest algo 1, begin of digest a1 26
        data: [2047 bits]

28.11 Erros de Assinatura RPM Após Atualização RHEL

Erro: “Certificate invalid: policy violation — SHA1 is not considered secure”

Ferramentas: RPM, DNF

Sintoma:

Após atualizar para o RHEL 9+ ou o RHEL 10, comandos RPM geram erros de verificação de assinatura para pacotes de terceiros:

$ rpm -qa
error: Verifying a signature using certificate
  D4E7A923F10B82C6459831AE5F6C0D9BA47E31D2
  (Third-Party Vendor (Release signing) <security@vendor.example.com>):
  1. Certificate 5F6C0D9BA47E31D2 invalid: policy violation
      because: No binding signature at time 2024-08-12T10:44:42Z
      because: Policy rejected non-revocation signature
               (PositiveCertification) requiring second pre-image resistance
      because: SHA1 is not considered secure
  2. Certificate 5F6C0D9BA47E31D2 invalid: policy violation
      because: No binding signature at time 2026-04-16T19:46:38Z
      because: Policy rejected non-revocation signature
               (PositiveCertification) requiring second pre-image resistance
      because: SHA1 is not considered secure

Os comandos RPM ainda funcionam, mas produzem saída de erro excessiva para cada pacote assinado com a chave afetada.

Causa: Chaves GPG de assinatura de terceiros que usam SHA-1 para as assinaturas vinculantes (certificações autoassinadas) são rejeitadas pelas crypto-policies do RHEL 9+ (SHA-1 bloqueado por padrão) e pelo RHEL 10 (suporte a SHA-1 removido por completo). Pacotes instalados antes da atualização retêm assinaturas SHA-1 antigas no banco de dados do RPM.

Diagnóstico:

# Listar todas as chaves GPG importadas no banco de dados do RPM
rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n'

Solução:

# 1. Remover a chave de assinatura antiga do terceiro
#    O ID do certificado 5F6C0D9BA47E31D2 mapeia para a versão a47e31d2 no RPM
rpm -e --allmatches gpg-pubkey-a47e31d2-6142699d

# 2. Importar a chave atualizada do fornecedor
rpm --import https://vendor.example.com/keys/signing.asc

# 3. Verificar se os erros desapareceram
rpm -qa > /dev/null

Mapeamento do Key ID: O ID do certificado no erro (por exemplo, 5F6C0D9BA47E31D2) corresponde à versão gpg-pubkey do RPM em hexadecimal minúsculo (a47e31d2). Se rpm -e reportar “not installed”, liste todas as chaves com rpm -q gpg-pubkey --qf '...' para localizar a string exata de version-release.

28.12 Corrupção do Banco de Dados RPM Após Atualização RHEL

Erro: “Malformed MPI” / “non-conformant OpenPGP implementation”

Ferramentas: RPM

Sintoma:

Após atualizar para o RHEL 9+ ou o RHEL 10, o RPM reporta assinatura corrompida em toda consulta ao banco de dados:

error: rpmdbNextIterator: skipping h#       9
Header RSA signature: BAD (header tag 268: invalid OpenPGP signature:
  Parsing an OpenPGP packet:
  Failed to parse Signature Packet
      because: Signature appears to be created by a non-conformant
               OpenPGP implementation, see
               <https://github.com/rpm-software-management/rpm/issues/2351>.
      because: Malformed MPI: leading bit is not set: expected bit 8 to
               be set in   110010 (32))
Header SHA256 digest: OK
Header SHA1 digest: OK

Causa: Alguns pacotes de terceiros foram assinados com implementações OpenPGP não padrão que produzem valores MPI (inteiro de múltipla precisão) malformados nas assinaturas RSA. O RPM mais antigo no RHEL 7/8 tolerava isso, mas o analisador baseado em Sequoia-PGP no RHEL 9+/10 rejeita.

Diagnóstico:

# Identificar o pacote corrompido usando o número do cabeçalho do erro (h# 9)
rpm -q --nosignature --querybynumber 9

Solução:

# 1. Fazer backup do banco de dados do RPM
tar zcvf /var/preserve/rpmdb-$(date +"%d%m%Y").tar.gz /usr/lib/sysimage/rpm/
# Nota: no RHEL 8/9, o banco de dados fica em /var/lib/rpm/

# 2. Identificar o pacote danificado
rpm -q --nosignature --querybynumber <NUMERO_DO_ERRO>

# 3. Remover o pacote com a assinatura corrompida
rpm -e --nosignature --nodigest <nome-do-pacote>
# Se a remoção falhar, remova apenas a entrada do banco de dados:
rpm -e --justdb --nodeps <nome-do-pacote>

# 4. Reconstruir o banco de dados do RPM
rpm --rebuilddb

# 5. Verificar se os erros foram resolvidos
rpm -qa > /dev/null

# 6. Reinstalar a partir de um repositório atualizado
dnf install <nome-do-pacote>

Nota: No RHEL 10, o banco de dados do RPM fica em /usr/lib/sysimage/rpm/. No RHEL 8/9, fica em /var/lib/rpm/.

Referência: A issue #2351 do RPM documenta a análise MPI mais rigorosa introduzida com o backend Sequoia-PGP.

Cenário combinado: ambos os erros após a atualização

Ao atualizar do RHEL 7/8 para o RHEL 9+/10, ambos os erros costumam aparecer ao mesmo tempo. Resolva nesta ordem:

1. Remova chaves de assinatura SHA-1 antigas e importe chaves atualizadas do fornecedor
2. Reconstrua o banco de dados do RPM com rpm --rebuilddb
3. Se erros de MPI malformado persistirem, identifique os pacotes afetados pelo número do header (rpm -q --nosignature --querybynumber <N>), remova-os e reinstale a partir de repositórios atualizados

28.13 Erros Navegador/Cliente

Erro: “NET::ERR_CERT_COMMON_NAME_INVALID”

Sintoma: Navegador mostra “Your connection is not private”

Causa: Hostname não coincide com CN ou SANs do certificado

Diagnóstico:

# Verificar o que você está acessando
echo "Acessando: www.example.com"

# Verificar SANs do certificado
openssl s_client -connect www.example.com:443 2>&1 | \
  openssl x509 -noout -ext subjectAltName
# X509v3 Subject Alternative Name:
#     DNS:server.example.com  ← Não inclui www.example.com!

Solução:

# Reemitir certificado com SANs corretos
openssl req -new -key server.key -out server.csr \
  -subj "/CN=www.example.com" \
  -addext "subjectAltName=DNS:www.example.com,DNS:server.example.com,DNS:example.com"

Erro: “NET::ERR_CERT_AUTHORITY_INVALID”

Sintoma: Navegador não confia no certificado

Causa: CA não está no repositório de confiança do navegador (autoassinado ou CA interna)

Para CA Interna:

# Distribuir certificado CA para clientes
# Usuários precisam instalar CA no seu navegador

# Ou adicionar ao repositório de confiança do sistema (clientes Linux)
sudo cp corporate-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Para Autoassinado (Apenas Teste):

# Não usar autoassinado em produção!
# Obter certificado apropriado da CA

28.14 Erros Firewall/Rede

Erro: Timeout de Conexão

Sintoma: Não consegue conectar à porta HTTPS

Diagnóstico:

# Verificar se serviço está escutando
ss -tlnp | grep :443

# Verificar firewall
sudo firewall-cmd --list-services | grep https

# Testar localmente
curl -vk https://localhost/

# Testar remotamente
telnet server.example.com 443

Solução:

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

# Verificar
sudo firewall-cmd --list-all

28.15 Dicionário de Mensagens de Erro

Tabela de Consulta Rápida

28.16 Comandos de Diagnóstico Rápido

Comandos Universais de Solução de Problemas

#============================================#
# EXECUTAR ESTES PARA QUALQUER ERRO DE CERTIFICADO
#============================================#

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

# 2. Verificar arquivo certificado
openssl x509 -in /path/to/cert.crt -noout -text

# 3. Verificar expiração
openssl x509 -in /path/to/cert.crt -noout -dates

# 4. Verificar confiança
openssl verify /path/to/cert.crt

# 5. Verificar permissões
ls -lZ /path/to/cert.crt
ls -lZ /path/to/key.key

# 6. Verificar coincidência cert/chave
openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in key.key | openssl md5

# 7. Testar conexão
openssl s_client -connect server:443

# 8. Verificar logs
sudo journalctl -xe | grep -i cert
sudo tail -f /var/log/httpd/ssl_error_log

# 9. Verificar SELinux
sudo ausearch -m avc -ts recent | grep cert

# 10. Verificar crypto-policy (RHEL 8+)
update-crypto-policies --show

28.17 Fluxograma de Resolução de Erros

Erro de Certificado Ocorreu
    │
    ├─ Serviço não inicia?
    │   ├─ Verificar sintaxe config
    │   ├─ Verificar caminhos arquivo
    │   ├─ Verificar permissões (600 para chaves)
    │   └─ Verificar contexto SELinux
    │
    ├─ Conexão falha?
    │   ├─ Verificar firewall
    │   ├─ Verificar serviço escutando
    │   ├─ Testar com openssl s_client
    │   └─ Verificar roteamento rede
    │
    ├─ Erro validação certificado?
    │   ├─ Verificar expiração
    │   ├─ Verificar cadeia confiança
    │   ├─ Verificar coincidência hostname
    │   └─ Verificar certs intermediários
    │
    ├─ Erro cipher/protocolo?
    │   ├─ Verificar crypto-policy (RHEL 8+)
    │   ├─ Verificar versões TLS
    │   └─ Testar com versão TLS diferente
    │
    └─ Erro certmonger?
        ├─ CA_UNREACHABLE → Verificar conectividade IPA
        ├─ CA_REJECTED → Verificar se principal existe
        └─ Ver Capítulo 30

28.18 Principais Conclusões

1. Maioria dos erros são previsíveis - Padrões comuns
2. Sempre verificar expiração primeiro - Causa #1 de problemas
3. Permissões importam - 600 para chaves, 644 para certs
4. Cadeia de confiança crítica - CA ou intermediário faltando
5. Versão RHEL importa - Erros diferentes por versão
6. crypto-policies afetam tudo (RHEL 8+)
7. SELinux pode bloquear - Verificar contextos
8. Consulte o Capítulo 27 para abordagem sistemática

Cartão de Referência Rápida

┌──────────────────────────────────────────────────────────────────┐
│ REFERÊNCIA RÁPIDA ERROS COMUNS CERTIFICADOS                      │
├──────────────────────────────────────────────────────────────────┤
│ Expirado:          Ver: openssl x509 -noout -dates               │
│                    Solução: Renovar certificado                  │
│                                                                  │
│ Confiança:         Ver: openssl verify cert.crt                  │
│                    Solução: Adicionar CA a /etc/pki/ca-trust/... │
│                                                                  │
│ Hostname:          Ver: openssl x509 -noout -ext subjectAltName  │
│                    Solução: Reemitir com SANs corretos           │
│                                                                  │
│ Permissões:        Ver: ls -lZ cert.crt key.key                  │
│                    Solução: chmod 600 key.key                    │
│                                                                  │
│ Coincidência:      Ver: Comparar MD5 de módulo                   │
│                    Solução: Regenerar CSR com chave correta      │
│                                                                  │
│ No shared cipher:  Ver: update-crypto-policies --show            │
│                    Solução: Atualizar política ou cliente        │
│                                                                  │
│ SELinux:           Ver: ausearch -m avc | grep cert              │
│                    Solução: restorecon -Rv /etc/pki/tls/         │
└──────────────────────────────────────────────────────────────────┘

Sempre começar com: Capítulo 27 (metodologia de 7 passos)

Navegação do Capítulo