Como adicionar uma CA privada ao repositório de confiança do sistema na família RHEL e no Debian/Ubuntu

Objetivo

Fazer com que o certificado de uma CA privada ou interna seja considerado confiável em todo o sistema pelo OpenSSL, pelo curl e por outras bibliotecas que leem o repositório de confiança do SO, tanto em Linux da família RHEL quanto da família Debian.

Pré-requisitos

Privilégios de root; o certificado da CA em formato PEM (as âncoras da família RHEL também aceitam DER); o pacote ca-certificates instalado (Debian/Ubuntu) ou o pacote ca-certificates que fornece o update-ca-trust (RHEL, Fedora e derivados como Rocky/Alma, RHEL 7 e posteriores).

Passos

Família RHEL:

1. Copie o certificado da CA (PEM ou DER; aqui o nome e a extensão do arquivo não importam) para /etc/pki/ca-trust/source/anchors/. Não o coloque no diretório pai /etc/pki/ca-trust/source/: certificados simples nesse local são tratados como não confiáveis.
2. Execute update-ca-trust extract como root (o update-ca-trust sem argumentos faz o mesmo). Ele lê o diretório de âncoras e os padrões do fornecedor e regenera os arquivos consolidados em /etc/pki/ca-trust/extracted/ (bundles PEM, um keystore Java); aplicações baseadas em NSS leem as mesmas fontes por meio do módulo p11-kit-trust.
3. Execução não interativa: o comando não faz perguntas e pode ser usado com segurança em scripts de provisionamento sem supervisão.

Debian/Ubuntu:

1. Copie o certificado da CA para /usr/local/share/ca-certificates/ (subdiretórios são permitidos); o arquivo deve terminar em .crt e deve estar em PEM (BEGIN CERTIFICATE). O update-ca-certificates só considera arquivos .crt nesse local, e um arquivo DER renomeado para .crt não vira uma entrada utilizável no bundle; converta-o antes com openssl x509 -inform der.
2. Execute update-ca-certificates como root. Ele atualiza os links de hash em /etc/ssl/certs, regenera /etc/ssl/certs/ca-certificates.crt e depois executa os hooks em /etc/ca-certificates/update.d/.
3. Em instalações sem supervisão, DEBIAN_FRONTEND=noninteractive não tem efeito aqui, pois a própria ferramenta não é interativa; só importa para a etapa apt-get install ca-certificates ao redor, caso o pacote não esteja instalado.

Resultado esperado

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt mycert.pem (Debian) ou openssl verify -CAfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem mycert.pem (família RHEL; versões mais antigas também o expõem no caminho legado /etc/pki/tls/certs/ca-bundle.crt) informa OK para um certificado cuja cadeia leva à nova CA. Na família RHEL, trust list | grep -i "<CA common name>" (p11-kit) confirma que a âncora foi registrada; no Debian/Ubuntu, o comando trust só existe se o pacote p11-kit estiver instalado.

Limites e base de verificação

Um arquivo .pem colocado no diretório errado, ou um arquivo Debian sem a extensão .crt, é ignorado silenciosamente pelas duas ferramentas: não há erro, apenas uma cadeia que continua sem ser validada. O OpenJDK empacotado pela distribuição normalmente lê um keystore gerado a partir desse mesmo repositório (/etc/pki/java/cacerts na família RHEL; /etc/ssl/certs/java/cacerts via hook do ca-certificates-java no Debian/Ubuntu), mas um JDK de fornecedor extraído de um tarball e um certifi instalado via pip mantêm repositórios próprios. Processos que já carregaram o bundle continuam com o conjunto antigo até serem reiniciados. Para remover uma CA, apague o arquivo do diretório de âncoras ou de /usr/local/share/ca-certificates e execute novamente o mesmo comando (no Debian, update-ca-certificates --fresh reconstrói os links do zero caso sobre algum link obsoleto).