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.

Se a Inspection CA tiver de provir da PKI da organização, a CA Default não é a substituição correta. Deve ser usado o processo separado para configurar uma CA subordinada para a inspeção TLS da Sophos Firewall.

Quando uma regeneração é justificada

Pode ser necessária uma renovação 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.

É necessário distinguir uma rotação planeada com uma cadeia antiga cuja validade e ausência de comprometimento foram verificadas da recuperação de um incidente por comprometimento suspeito ou confirmado da chave, ou por uma CA já expirada. Só o primeiro caso permite um período de coexistência limitado. Num incidente, a contenção e um momento de corte aprovado têm prioridade sobre o calendário normal de migração; os serviços afetados não devem continuar a usar a confiança antiga insegura até todos os utilizadores terem migrado.

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.

O download na página da CA guarda apenas o certificado da CA. O SFOS 22 também disponibiliza a entrada CertificateAuthority em Backup and firmware > Import export > Export selective configuration. A sequência Apply selected items > Export > Download permite exportar a configuração da CA, incluindo a chave privada. Este ficheiro é altamente sensível: deve ser guardado encriptado, com controlo de acesso e fora da firewall, e o respetivo período de retenção deve constar da alteração.

O export seletivo é uma proteção adicional, não uma função Undo por testar. Para o importar noutra firewall ou após um reset ou reimage, o SFOS exige a SSMK válida no momento do export; sem ela, as chaves privadas e as configurações dependentes não são importadas. Antes da alteração, verificar o export e o procedimento de importação aprovado numa firewall compatível que não esteja em produção e tenha a mesma versão de firmware ou uma posterior, ou confirmá-los com o Sophos Support. Não efetuar uma importação de teste da CA anterior na firewall de produção. Enquanto este caminho não tiver sido validado com êxito, não o planear como rollback; um restore completo de um backup compatível só é um último caminho de recuperação da cadeia antiga se esta for comprovadamente válida e não estiver comprometida. Mesmo um procedimento de importação validado só é uma opção de recuperação da cadeia antiga se esta for comprovadamente válida e não estiver comprometida; restaurar uma chave antiga comprometida não justifica retomar um serviço seguro.

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. É um último caminho de recuperação planeado para uma cadeia antiga comprovadamente válida e não comprometida, 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 name, State, Locality name, Organization name, Organization unit name, Common name e o endereço de e-mail da pessoa de contacto.
4. Em Key type, selecionar conscientemente RSA ou Elliptic curve, definir Key length para RSA ou Curve name para Elliptic curve e selecionar o algoritmo em Secure hash. Se já estiver definida uma Private key password e se pretender alterá-la, incluir essa alteração na mesma alteração aprovada.
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.

Os campos descrevem a identidade da CA: Country name é o país onde a firewall está implementada, State a região e Locality name a cidade. Organization name identifica o proprietário do certificado, Organization unit name o departamento atribuído e Common name o hostname ou FQDN. O endereço de e-mail pertence à pessoa de contacto.

Private key password refere-se a uma palavra-passe já definida para a chave privada. Não é a palavra-passe do backup nem a SSMK. Uma alteração planeada deve ser registada no gestor de palavras-passe aprovado, não no ticket da alteração nem numa captura de ecrã. A documentação para SFOS 22 e 23 descreve esta alteração condicional da palavra-passe, mas não uma função de reposição nem o significado de um campo de palavra-passe vazio. Se a palavra-passe existente for desconhecida ou o formulário apresentado for diferente, esclarecer a situação com o Sophos Support antes de clicar em Save, em vez de esvaziar o campo a título experimental.

Com RSA, as chaves maiores oferecem mais segurança, mas exigem mais tempo para encriptar e desencriptar. Por isso, o comprimento da chave é aprovado em conjunto com a compatibilidade e os requisitos operacionais; para Elliptic curve, seleciona-se Curve name em alternativa. Secure hash define o algoritmo de hash.

⚠️ 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.

A documentação de atualização para SFOS 22 e 23 confirma a regeneração automática da CA, mas não descreve uma reemissão ou reatribuição automática para cada certificado dependente. Por isso, verificar, para cada serviço, o certificado efetivamente apresentado e a respetiva cadeia; descarregar a nova CA, por si só, não comprova que todos os serviços já passaram a utilizar a nova cadeia.

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. Numa rotação planeada, os perfis antigos só podem continuar em distribuição durante um período de coexistência aprovado e limitado, enquanto a cadeia antiga for comprovadamente válida e não estiver comprometida; a distribuição deve terminar, o mais tardar, após a migração bem-sucedida de todos os utilizadores.

Em caso de comprometimento suspeito ou confirmado, o responsável pelo incidente deve aprovar a contenção e o momento de corte. Nesse momento, retirar os perfis antigos da distribuição e remover a confiança na antiga CA comprometida dos clientes e peers afetados; não esperar pela migração de todos os utilizadores. Uma cadeia já expirada também não permite esta coexistência. Se não for possível disponibilizar uma cadeia segura, independente e validada, parar o serviço afetado e escalar para a equipa de resposta a incidentes ou para o Sophos Support. Restaurar a antiga chave comprometida não restabelece um serviço seguro.

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.

Adicionar a nova CA ao lado da antiga só é permitido durante um período de coexistência aprovado e limitado, com uma cadeia antiga comprovadamente válida e não comprometida. Em caso de comprometimento, retirar a confiança antiga do peer no momento de corte aprovado para o incidente; também não manter o serviço com uma cadeia antiga expirada. Sem uma cadeia de substituição segura e validada, parar o túnel afetado e escalar.

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.

Uma marca de verificação em Trusted confirma apenas que a CA correspondente está instalada na firewall. Não comprova a confiança dos clientes externos, o êxito do início de sessão nem o tráfego de aplicações. Mesmo que o subject permaneça inalterado, as CAs antiga e nova distinguem-se pelo fingerprint; não decidir apenas com base no nome.

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.

Voltar a importar apenas a antiga CA pública num peer ou ativar um perfil de cliente antigo também não restaura a antiga chave da CA na firewall. Um caminho de recuperação de um serviço só funciona se o certificado utilizado, a respetiva chave privada disponível e os peers forem compatíveis com a cadeia antiga aprovada. Se a chave da CA estiver comprometida ou a CA tiver expirado, regressar à cadeia de confiança antiga não constitui uma operação normal segura; nesse caso, envolver a equipa de resposta a incidentes ou o Sophos Support e utilizar uma alternativa segura.

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 e se a cadeia antiga for comprovadamente válida e não estiver comprometida,
• utilizar um restore completo do backup para regressar à cadeia antiga apenas se esta for comprovadamente válida e não estiver comprometida e se os efeitos, o reinício, SSMK e a perda de alterações posteriores forem aceitáveis; caso contrário, utilizar uma cadeia segura, independente e validada ou parar o serviço afetado e escalar,
• 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.
• O certificado da CA anterior, o export seletivo CertificateAuthority, o backup, a palavra-passe e SSMK estão guardados em segurança.
• 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