Quando a segurança derruba a conexão

Se um servidor Linux parou de acessar a internet logo depois que a inspeção SSL foi ativada no firewall, a causa quase sempre é a mesma: o servidor não confia no certificado do próprio firewall. A solução é instalar a Autoridade Certificadora (CA) do firewall no sistema, e o processo leva poucos minutos.

O sintoma é conhecido. Estações Windows da empresa navegam normalmente, mas o servidor Linux falha em tudo que usa HTTPS: atualizações de pacotes, chamadas de API e, em muitos casos, a validação de licença de aplicações que precisam se conectar a um servidor externo para continuar funcionando.

O que é Deep Inspection

Deep Inspection (ou inspeção SSL/TLS profunda) é o recurso do firewall que abre o tráfego criptografado para analisá-lo. Sem ele, o firewall vê apenas o destino da conexão, não o conteúdo, e deixa passar malware e vazamento de dados escondidos dentro do HTTPS.

Para abrir o tráfego, o firewall se coloca no meio da conexão:

1. O servidor pede uma conexão segura a um site externo.
2. O firewall intercepta o pedido e abre ele mesmo a conexão com o site.
3. O firewall inspeciona o conteúdo e o entrega ao servidor, assinado com um certificado gerado na hora pela CA do próprio firewall.

Para o servidor, o certificado recebido não foi emitido por uma autoridade pública conhecida, e sim pela CA interna do firewall. Se essa CA não estiver na lista de autoridades confiáveis do sistema, a conexão é recusada.

Por que o Linux é o primeiro a falhar

Estações Windows em domínio costumam receber a CA do firewall automaticamente, por política de grupo (GPO). Servidores Linux ficam de fora dessa distribuição e continuam confiando apenas nas autoridades públicas que vêm com o sistema.

O resultado aparece em mensagens como SSL certificate problem: unable to get local issuer certificate. Na prática, isso significa:

• apt update ou dnf update falham ao baixar pacotes.
• Integrações com APIs externas param de responder.
• Aplicações que validam a licença online deixam de funcionar ou entram em modo restrito, porque não conseguem confirmar a licença no servidor do fabricante.

Este último caso é o mais crítico: um serviço em produção pode parar sem nenhuma alteração no próprio servidor, apenas por uma mudança de política no firewall.

Passo a passo: instalando a CA no Linux

1. Obtenha a CA do firewall

A CA pode ser exportada no painel do firewall, na área de perfis de inspeção SSL. Outra opção é exportá-la de uma estação Windows que já confia nela:

1. Abra certmgr.msc (ou certlm.msc).
2. Vá em Autoridades de Certificação Raiz Confiáveis → Certificados e localize a CA do firewall.
3. Clique com o botão direito → Todas as Tarefas → Exportar e escolha X.509 codificado na base 64 (.CER).

2. Transfira o arquivo para o servidor

No PowerShell do Windows (substitua usuário e IP pelos do seu ambiente):

scp C:\caminho\ca-firewall.cer usuario@IP_DO_SERVIDOR:/tmp/ca-firewall.cer

Atenção: o comando é executado no Windows, onde está o arquivo, e não dentro do servidor.

3. Confira o formato

As extensões .cer e .crt são apenas nomes. O que importa é o conteúdo:

head -1 /tmp/ca-firewall.cer

Se aparecer -----BEGIN CERTIFICATE-----, o arquivo está em PEM (texto). Se aparecerem caracteres ilegíveis, está em DER (binário) e precisa ser convertido.

4. Instale no Ubuntu / Debian

Arquivo em PEM:

sudo cp /tmp/ca-firewall.cer /usr/local/share/ca-certificates/ca-firewall.crt
sudo update-ca-certificates

Arquivo em DER:

sudo openssl x509 -inform der -in /tmp/ca-firewall.cer -out /usr/local/share/ca-certificates/ca-firewall.crt
sudo update-ca-certificates

O resultado esperado é 1 added. Se aparecer 0 added, o arquivo não está na pasta correta, não termina em .crt ou não está em PEM.

5. Instale no RHEL / Rocky / AlmaLinux

sudo cp /tmp/ca-firewall.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

Como validar

Um teste com curl confirma em segundos se o servidor voltou a navegar:

curl -I https://www.google.com

A resposta HTTP/2 200 (ou um código 301/302) indica sucesso. Para confirmar que o tráfego passa pelo firewall e que a CA é aceita:

openssl s_client -connect www.google.com:443 </dev/null 2>/dev/null | grep -E "issuer=|Verify return"

O emissor (issuer) deve ser a CA do firewall, e a linha final deve mostrar Verify return code: 0 (ok). Por fim, reinicie os serviços da aplicação para que ela carregue a nova lista de autoridades e consiga validar a licença.

Cuidados e boas práticas

Containers não herdam a CA do host. Se a aplicação roda em Docker, monte o bundle atualizado dentro do container e recrie-o:

volumes:
  - /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro

Algumas aplicações ignoram o sistema. Certos programas trazem a própria lista de autoridades embutida e não leem o store do Linux. Nesses casos, instalar a CA não resolve, e o caminho é ajustar o firewall.

Nem todo tráfego é HTTPS. Aplicações com protocolos próprios podem ser corrompidas pela inspeção profunda. Para servidores críticos, avalie aplicar um perfil de inspeção apenas de certificado (sem abrir o conteúdo) ou uma exceção para os destinos de licenciamento.

Documente e monitore a validade. A CA do firewall tem data de expiração. Registre onde ela foi instalada para que a renovação não pare os serviços de surpresa.

Conclusão

Deep Inspection é uma camada importante de proteção, mas exige que todos os equipamentos da rede confiem no firewall, não só as estações de trabalho. Incluir a CA nos servidores Linux deve fazer parte do checklist sempre que a inspeção SSL for ativada ou o certificado do firewall for renovado.

A equipe da VM SERV apoia empresas na implantação de políticas de segurança de rede sem impacto na operação, da configuração do firewall à adequação dos servidores. Fale com a gente para avaliar o seu ambiente.