Renovar de forma controlada a Default CA do Sophos Firewall

A CA integrada Default do Sophos Firewall não é um simples campo descritivo. Assim que as suas definições são guardadas, o SFOS regenera automaticamente a CA. É criada uma nova chave e, consequentemente, um novo trust anchor. As relações de confiança existentes não se adaptam automaticamente.

Por isso, uma renovação controlada não começa com Save, mas com uma lista completa de dependências. Esta inclui certificados assinados localmente, WebAdmin e portais, perfis SSL VPN, peers IPsec baseados em certificados e sistemas externos que confiam na CA anterior.

⚠️ Importante: Renovar a CA Default apenas com um backup verificado, acesso de gestão independente, uma janela de manutenção e um plano para todos os serviços dependentes. Uma alteração estética ao país, organização ou common name não justifica uma regeneração não planeada.

Renovar a Default CA em dez passos

1. Documentar o motivo técnico, o responsável pela alteração, a janela de manutenção e os critérios de sucesso.
2. Identificar todos os certificados, serviços, perfis VPN, peers e clientes que confiam na atual CA Default.
3. Verificar se o objetivo real é apenas o ApplianceCertificate ou a CA separada SecurityAppliance_SSL_CA.
4. Testar com êxito o backup de configuração atual, SSMK, acesso de administrador local e caminho de recuperação.
5. Descarregar a antiga CA Default e registar o respetivo fingerprint SHA-256, subject, número de série e validade.
6. Aprovar por escrito os novos dados da CA, o tipo de chave e a compatibilidade com todos os peers.
7. Em Certificates > Certificate authorities > Default, introduzir os valores preparados e guardá-los apenas durante a janela de manutenção.
8. Descarregar a nova CA pública e distribuí-la de forma controlada a peers, clientes e trust stores.
9. Testar separadamente WebAdmin, portais, SSL VPN, IPsec e todos os outros serviços dependentes.
10. Documentar o fingerprint, os logs, os resultados dos testes e os perfis antigos restantes. Utilizar o caminho de recuperação preparado se ocorrer um erro crítico.

Distinguir Default CA, ApplianceCertificate e Inspection CA

O Sophos Firewall contém vários objetos com funções diferentes:

• Default: CA interna para certificados assinados localmente.
• ApplianceCertificate: certificado de servidor integrado utilizado por predefinição para WebAdmin, User Portal e Captive Portal. É assinado pela CA Default e pode ser regenerado separadamente.
• SecurityAppliance_SSL_CA: CA integrada separada para HTTPS Inspection e Re-Signing quando selecionada na configuração de TLS Inspection.

Estes objetos não devem ser tratados como equivalentes. Um problema com um único ApplianceCertificate não prova que a CA Default está danificada. Da mesma forma, alterar a CA Default não executa automaticamente uma rotação planeada de SecurityAppliance_SSL_CA.

Importar e atribuir certificados no Sophos Firewall explica o trabalho geral com certificados, chaves privadas, CSR e cadeias de CA. A Inspection CA tem um procedimento próprio em Distribuir o certificado CA para HTTPS Scanning.

Quando uma regeneração é justificada

Pode ser necessária uma alteração planeada quando:

• a chave da CA anterior está comprovadamente ou plausivelmente comprometida,
• a CA está a expirar e ainda é efetivamente utilizada em produção,
• a identidade, o tipo de chave ou os requisitos criptográficos estão a ser migrados de forma controlada,
• o Sophos Support exige a regeneração para um problema confirmado.

Um download VPN isolado que falhou, um aviso do browser sem análise da cadeia, um pedido estético relativo ao subject ou um comando antigo da comunidade não são razões suficientes. Para um problema com .ovpn e ApplianceCertificate, primeiro diagnosticar sistematicamente o download da configuração SSL VPN.

Inventariar as dependências antes da alteração

Certificados e serviços atribuídos

Em Certificates > Certificates, registar pelo menos o nome, subject, issuer, validade e atribuição real de cada certificado assinado localmente. Dependendo do ambiente, isto inclui:

• WebAdmin, User Portal e Captive Portal,
• o certificado de servidor SSL VPN,
• IPsec site-to-site e remote access com Digital certificate,
• WAF, SMTP, API ou outros serviços TLS,
• certificados de cliente ou servidor gerados localmente fora da firewall.

Um certificado visível não é automaticamente uma dependência. O que importa é se um serviço de produção o utiliza e se o peer confia na CA Default emissora.

Sistemas que confiam e caminhos de distribuição

Documentar também:

• browsers e sistemas operativos com a CA antiga importada,
• MDM, GPO ou distribuição de software para a nova CA,
• peers IPsec com Default.pem, Remote CA ou mapeamento DN importados,
• utilizadores SSL VPN e o caminho de distribuição de novos perfis .ovpn,
• monitorização, clientes API ou integrações com certificate pinning,
• acesso de gestão HA, de emergência e externo.

Se não estiver claro quem distribuiu a CA anterior ou que peers confiam nela, a alteração é interrompida.

Preservar o estado inicial e o caminho de recuperação

Antes da janela de manutenção, descarregar a CA Default em Certificates > Certificate authorities. O arquivo contém a parte pública, não automaticamente uma exportação utilizável de forma independente da sua chave privada.

Os dados PEM podem ser verificados em modo só de leitura num computador de administração:

openssl x509 -in Default.pem -noout -subject -issuer -serial -dates -fingerprint -sha256

Para um ficheiro DER, especificar o formato de entrada:

openssl x509 -inform DER -in Default.der -noout -subject -issuer -serial -dates -fingerprint -sha256

Guardar o fingerprint e o resultado no estado anterior juntamente com o nome da firewall, o número de série, a build do SFOS e o ticket da alteração. Não anexar ficheiros de certificados e dados PKI internos sem proteção a tickets públicos.

Guardar também externamente um backup atual do Sophos Firewall com a palavra-passe e SSMK. Um restore substitui toda a configuração, reinicia a firewall e pode reverter alterações posteriores. É o último caminho de recuperação planeado, não uma função rápida de desfazer para a CA.

Preparar a janela de manutenção

Antes de Save, todos os pontos seguintes devem estar confirmados:

• conta admin local ou segundo administrador testado a partir da rede de gestão,
• consola ou outro caminho de recuperação independente disponível,
• novos valores da CA e criptografia compatíveis com todos os sistemas peer,
• responsáveis pelos peers VPN, MDM/GPO e portais disponíveis,
• novos perfis, distribuição para trust stores e contas de teste preparados,
• tempo suficiente para um restore completo do backup, se necessário.

Num cluster HA, realizar a alteração suportada do WebAdmin no Primary atual. O SFOS não documenta continuidade ininterrupta da CA ou das sessões para esta alteração. Por isso, depois de um failover planeado, testar novamente novos inícios de sessão e todos os serviços críticos. Não editar a CA de forma independente em ambos os nodes.

Atualizar a Default CA no SFOS

1. Abrir Certificates > Certificate authorities.
2. Clicar em Default. O nome não pode ser alterado.
3. Verificar Country, State, Locality, Organization, Organizational unit, Common name e o endereço de e-mail.
4. Em Private key settings, selecionar conscientemente RSA ou Elliptic curve, o comprimento da chave ou a curva correspondente e o Secure hash.
5. Comparar os valores com o ticket da alteração e a lista de compatibilidade.
6. Clicar em Save apenas durante a janela de manutenção.

Valores de exemplo como CH, Zurich, Example AG, IT Security, fw01.example.com e pki@example.com são apenas dados de documentação. Substituí-los pela própria organização, pela referência real da firewall e pela convenção de nomes PKI aprovada.

⚠️ Save é o ponto de mudança. O SFOS regenera automaticamente a CA Default. Voltar a introduzir os valores anteriores do subject não restaura a chave nem o fingerprint anteriores.

Imediatamente depois, descarregar a nova CA Default e executar a mesma verificação OpenSSL. É esperado um novo fingerprint SHA-256 depois da regeneração. Campos inesperados, um erro de download ou um estado que não possa ser documentado são condições de paragem.

Migrar os serviços dependentes de forma controlada

WebAdmin e portais

Verificar que certificado está selecionado para WebAdmin, User Portal e Captive Portal em Administration > Admin and user settings. Se for utilizado um certificado assinado localmente com a nova CA, os clientes que lhe acedem devem confiar na nova CA.

Manter aberta uma sessão Full Admin existente durante o teste. Novas janelas privadas do browser testam o FQDN, a cadeia de certificados e o início de sessão a partir da origem de gestão prevista. O comando CLI que repõe o certificado WebAdmin para o certificado predefinido do dispositivo não é um rollback da chave antiga da CA.

SSL VPN

Se SSL VPN utilizar o ApplianceCertificate ou outro certificado de servidor assinado localmente, os utilizadores devem descarregar e importar um novo ficheiro .ovpn depois da alteração das definições da CA Default. Um nome de ficheiro existente ou um túnel verde com um perfil antigo não são validação suficiente.

Pelo menos um utilizador piloto descarrega o novo perfil pelo caminho de portal previsto, estabelece uma nova ligação e testa DNS, rotas e tráfego real de aplicações. Remover os perfis antigos da distribuição apenas depois de todos os utilizadores terem migrado com êxito.

Peers IPsec baseados em certificados

Com Digital certificate, os peers do Sophos Firewall trocam os seus certificados CA. Se o peer tinha importado anteriormente o Default.pem remoto, substituir ou adicionar de forma controlada a nova CA pública no peer e voltar a verificar o mapeamento.

A configuração completa da ligação permanece em Configurar IPsec site-to-site no Sophos Firewall. Para a alteração da CA, testar pelo menos o estabelecimento IKE, a Child SA, ambas as direções do tráfego e as aplicações reais. Um túnel verde, por si só, não comprova o caminho de retorno.

HTTPS Inspection e outros caminhos de assinatura

Para HTTPS Inspection, identificar primeiro a Signing CA realmente selecionada em Web > General settings. Se for SecurityAppliance_SSL_CA ou uma CA externa, não a redistribuir apenas porque a CA Default foi regenerada.

Incluir um caminho de assinatura na alteração apenas quando estiver comprovado que utiliza a CA Default modificada ou um certificado dependente. Assim, as alterações ao trust store ficam limitadas aos endpoints realmente afetados.

Verificar o resultado e os logs

A validação separa configuração e funcionamento:

1. Descarregar a nova CA e documentar subject, issuer, número de série, validade e fingerprint SHA-256.
2. Em Certificates > Certificates, verificar issuer, Trusted e os objetos de certificado afetados.
3. Testar individualmente WebAdmin, portais, SSL VPN, IPsec e outros serviços atribuídos.
4. Verificar em vpncertificate.log a operação da CA e do certificado no momento da alteração.
5. Verificar em configuration-audit.log o administrador, a hora e os dados antes/depois suportados.
6. Correlacionar nos logs de serviço correspondentes apenas os erros e êxitos pertencentes ao teste.

Rastrear alterações de configuração com configuration-audit.log explica o audit trail. Nem todos os serviços escrevem o mesmo nível de detalhe em configuration-audit.log, por isso a validação funcional continua obrigatória.

Rollback e condições de paragem

Uma CA regenerada não tem um controlo Undo simples. Guardar novamente o texto anterior não restaura a antiga chave privada.

Por isso, o caminho de recuperação é definido antecipadamente para cada serviço:

• manter o acesso de gestão independente e a sessão de administrador existente,
• voltar a atribuir aos portais um certificado externo independente e já validado, se estiver disponível e puder ser atribuído em segurança,
• reverter a confiança dos peers e os perfis de cliente apenas de acordo com o estado anterior documentado,
• utilizar um restore completo do backup apenas quando os efeitos, o reinício, SSMK e a perda de alterações posteriores forem aceitáveis,
• escalar para o Sophos Support com evidências quando uma dependência for desconhecida ou o estado do certificado não puder ser reproduzido.

Não efetuar alterações à base de dados pela shell, eliminar certificados em massa, reiniciar serviços ou regenerar a CA uma segunda vez por suspeita. Interromper a alteração quando não for possível coordenar um peer crítico, o novo trust anchor não estiver distribuído ou o caminho de recuperação não tiver sido testado com êxito.

Erros típicos depois da regeneração

O browser comunica uma ligação não fidedigna

Verificar a cadeia de certificados realmente fornecida para o FQDN. Se o certificado de servidor for assinado pela nova CA Default, exatamente essa CA deve estar presente no trust store. Não importar SecurityAppliance_SSL_CA indiscriminadamente.

SSL VPN já não liga com o perfil antigo

Correlacionar o certificado de servidor SSL selecionado, a nova CA, o download do portal e sslvpn.log. Descarregar um novo ficheiro .ovpn e importá-lo como novo perfil. Distinguir perfis antigos e novos pelo certificado e pela ligação bem-sucedida, não pelo nome do ficheiro.

IPsec permanece down depois da alteração da CA

Em ambos os lados, verificar a importação da CA, o estado Trusted, Local/Remote certificate, ID e strongswan.log. Com DER ASN1 DN, uma alteração do subject da CA também pode afetar a identidade. Não flexibilizar perfis ou IDs por suspeita.

HTTPS Inspection apresenta erros de certificado

Verificar primeiro a Signing CA realmente selecionada. Se SecurityAppliance_SSL_CA continuar em uso e não tiver sido alterada, o erro não é causado automaticamente pela nova CA Default. Investigar separadamente a cadeia de certificados, a Decryption Rule e a confiança do endpoint.

Lista de verificação

• O motivo e o âmbito da regeneração da CA estão documentados.
• A CA antiga, o fingerprint, o backup, a palavra-passe e SSMK estão preservados.
• Todos os certificados, serviços, peers, clientes e caminhos de distribuição estão inventariados.
• Default, ApplianceCertificate e SecurityAppliance_SSL_CA foram avaliados separadamente.
• A janela de manutenção, o caminho de recuperação de administrador e os responsáveis estão preparados.
• Os novos valores da CA e a criptografia são compatíveis com todos os peers.
• A CA foi guardada apenas na janela aprovada e descarregada depois.
• WebAdmin, portais, SSL VPN, IPsec e outros serviços foram testados separadamente.
• vpncertificate.log, configuration-audit.log e os logs de serviço foram preservados.
• O rollback ou a escalada para suporte são possíveis sem alterações descontroladas pela shell.

FAQ