Importar e atribuir certificados na Sophos Firewall

Na Sophos Firewall, um certificado só fica operacional quando quatro elementos correspondem entre si: hostname, certificado de servidor, chave privada e cadeia da CA emissora. Depois, o certificado ainda tem de ser atribuído ao serviço correto. A simples existência de uma entrada em Certificates > Certificates não altera qualquer portal nem regra WAF.

Para um certificado de uma CA interna ou pública, o procedimento padrão mais seguro é:

1. Criar um Certificate Signing Request (CSR) em Certificates > Certificates > Add.
2. Solicitar à CA pretendida que assine o CSR.
3. Importar o certificado emitido através da ação de importação do CSR existente.
4. Verificar em Trusted se a CA correspondente está instalada e em Valid until se o certificado está válido.
5. Atribuir o certificado ao serviço pretendido e testá-lo a partir de um cliente.

Neste procedimento, a chave privada é criada na firewall e não tem de sair do equipamento. Também é possível carregar um certificado que já tenha sido criado externamente, mas será necessária a chave privada correspondente e, se aplicável, as CA intermédias e raiz em falta.

Se já existir um ficheiro PFX ou PEM, o procedimento rápido passa por Certificates > Certificates > Add > Upload certificate: selecionar o formato, carregar o certificado com a chave privada necessária e a respetiva palavra-passe e, em seguida, verificar a CA associada, a validade e a atribuição ao serviço.

Que método de certificado deve ser utilizado?

• CA pública ou interna, certificado novo: criar o CSR na firewall. Isto reduz o transporte de chaves e evita que se confundam facilmente pares de certificado e chave.
• Certificado existente com chave privada: carregar o certificado em formato PEM, DER, CER ou PKCS12. O formato, a palavra-passe e a cadeia da CA têm de corresponder.
• Let’s Encrypt para um serviço público da firewall: o processo integrado pode tratar da emissão e da renovação. O procedimento completo está descrito em Configurar certificados Let’s Encrypt na Sophos Firewall.
• Certificado wildcard externo: criá-lo fora da firewall e importá-lo depois. O planeamento e a validação DNS-01 estão descritos em Criar um certificado wildcard Let’s Encrypt.
• Apenas para clientes internos e geridos: um certificado assinado localmente pode ser suficiente, desde que todos os clientes confiem na CA interna emissora.

Um certificado autoassinado ou assinado localmente não utiliza, por esse motivo, uma encriptação insegura. Contudo, sem uma cadeia de confiança distribuída, o cliente não consegue confirmar a identidade de forma fiável e apresenta um aviso. Para portais acessíveis publicamente e aplicações WAF, uma CA pública é, por isso, normalmente a melhor opção.

Distinguir certificado, CA, chave privada e CSR

Estes quatro elementos têm funções diferentes:

• Certificado de servidor: contém a identidade, os dados da chave pública, os nomes válidos e o período de validade. É apresentado ao cliente.
• Chave privada: comprova que a firewall está autorizada a utilizar o certificado. Nunca deve ser incluída em tickets, capturas de ecrã ou repositórios públicos.
• Certificados de CA: formam a cadeia de confiança desde a CA intermédia emissora até à CA raiz. Para isso, não é necessária qualquer chave privada da CA.
• CSR: contém o pedido de certificado e a chave pública. Quando o CSR é criado na firewall, a chave privada correspondente permanece no equipamento.

Uma CA para TLS Inspection tem uma função diferente de um certificado de servidor para WebAdmin ou WAF. Durante a desencriptação, a CA de inspeção assina novos certificados para os clientes. A respetiva seleção e distribuição são explicadas em Distribuir o certificado da CA da Sophos Firewall para TLS Inspection.

Preparar nomes, validade e cadeia

Antes da importação, deve estar claro qual é o nome que os utilizadores e sistemas irão efetivamente abrir. Os clientes modernos verificam sobretudo os Subject Alternative Names (SAN). O Common Name, por si só, não é um substituto fiável.

Exemplo:

• URL utilizada: https://vpn.example.com
• nome do certificado no SFOS: public-vpn-example-com-2026
• SAN no certificado: vpn.example.com
• DNS: vpn.example.com aponta para o acesso previsto à firewall ou à WAF

vpn.example.com é apenas um exemplo e deve ser substituído pelo FQDN utilizado. Se um administrador aceder através do endereço IP ou de outro alias, o certificado só será válido se esse nome ou endereço IP também estiver incluído como SAN.

Antes da alteração, verificar:

• A data, a hora e o NTP da firewall estão corretos.
• Todos os FQDN necessários constam do pedido ou do certificado como SAN.
• A chave privada e o certificado correspondem entre si.
• As CA intermédias e raiz são conhecidas.
• A data de expiração e a responsabilidade pela renovação estão documentadas.
• O certificado atual e as respetivas atribuições são mantidos para permitir o rollback.

Método recomendado: criar o CSR na firewall

Criar o CSR

1. Abrir Certificates > Certificates.
2. Selecionar Add.
3. Em Action, selecionar Generate certificate signing request (CSR).
4. Atribuir um nome interno claro, por exemplo public-vpn-example-com-2026.
5. Selecionar o Key Type, o comprimento da chave ou a curva e o hash necessários, de acordo com os requisitos de segurança e da CA.
6. Em Common name, introduzir o FQDN principal, por exemplo vpn.example.com.
7. Em Subject Alternative Names, adicionar pelo menos o nome DNS que será efetivamente utilizado.
8. Guardar e descarregar o CSR através do ícone de download.

O nome interno do certificado é apenas uma designação do SFOS. Não tem de ser igual ao FQDN, mas deve permitir identificar a finalidade e o ano de renovação. Em contrapartida, as entradas SAN fazem parte da verificação técnica da identidade e têm de corresponder à URL utilizada posteriormente.

Solicitar a assinatura do CSR

Entregar o CSR descarregado à CA pública ou interna responsável. Não solicitar a criação de novos ficheiros de chave se for utilizada a chave privada criada na firewall. Em seguida, a CA fornece o certificado de servidor assinado e, consoante o fornecedor, certificados intermédios adicionais.

Antes da importação, confirmar:

• A CA assinou o CSR correto.
• A lista de SAN contém todos os nomes autorizados.
• A validade e o emissor correspondem à encomenda ou à política interna.
• A cadeia da CA está completa.

Importar o certificado assinado para o CSR

1. Abrir Certificates > Certificates.
2. Na linha do CSR correto, selecionar a ação de importação em Manage.
3. Carregar o certificado emitido ou colar o respetivo texto.
4. Como finalidade, selecionar normalmente Certificate only. Se o mesmo ficheiro também incluir a cadeia da CA, selecionar a finalidade adequada para o certificado e a CA.
5. Executar Import certificate.

O SFOS associa o certificado à chave privada existente na firewall e remove depois a entrada do CSR. Por isso, antes da importação, é importante confirmar que foi realmente selecionada a linha do CSR correto.

Carregar um certificado existente com chave privada

Se o certificado e a chave já tiverem sido criados fora da firewall:

1. Abrir Certificates > Certificates > Add.
2. Selecionar Upload certificate.
3. Atribuir um nome inequívoco.
4. Selecionar o formato de ficheiro existente.
5. Carregar o certificado e os dados da chave exigidos pelo formato.
6. Se a chave privada estiver encriptada, introduzir a respetiva palavra-passe.
7. Guardar.

O SFOS suporta os seguintes formatos de certificado:

• PEM (.pem): codificado em Base64; normalmente, o certificado e a chave privada encontram-se em ficheiros separados.
• DER (.der) e CER (.cer): formatos binários de certificado; a chave privada encontra-se num ficheiro separado.
• PKCS7 (.p7b): pode conter certificados e uma cadeia, mas não uma chave privada.
• PKCS12 (.pfx ou .p12): pode conter, em conjunto, o certificado de servidor, a cadeia da CA e a chave privada.

São suportadas chaves RSA e ECC. Para a palavra-passe de uma chave privada importada, o SFOS aceita no máximo 30 caracteres. Este limite do produto não justifica a utilização de uma chave privada sem proteção: para a transferência, deve ser definida uma palavra-passe forte dentro deste limite e o ficheiro de importação deve depois ser removido de locais temporários inseguros.

Completar uma cadeia da CA em falta

Em Certificates > Certificates, uma entrada verde em Trusted indica que a CA correspondente está instalada no SFOS. Se essa indicação estiver em falta, verificar primeiro o emissor e a cadeia:

1. Abrir Certificates > Certificate authorities.
2. Selecionar Add.
3. Carregar a CA intermédia ou raiz em falta ou colar o texto do certificado.
4. Para uma cadeia utilizada apenas para estabelecer confiança, selecionar Validation only.
5. Guardar e voltar a verificar o estado Trusted do certificado de servidor.

Para validar uma CA raiz ou intermédia pública, não é necessária qualquer chave privada. Signing and validation destina-se apenas a uma CA com a qual a firewall deve assinar certificados e cuja chave privada é deliberadamente mantida na firewall.

Upgrade para SFOS 21 ou posterior: verificar nomes de CA reservados

Durante o primeiro upgrade de uma instalação anterior para SFOS 21 ou posterior, NC-146082 pode bloquear a migração. A causa não é a validade do certificado, mas uma entrada de CA já configurada com um nome de que o SFOS necessita para as CA Let’s Encrypt integradas:

Lets_Encrypt_R10
Lets_Encrypt_R11
Lets_Encrypt_R12
Lets_Encrypt_R13
Lets_Encrypt_R14
Lets_Encrypt_E5
Lets_Encrypt_E6
Lets_Encrypt_E7
Lets_Encrypt_E8
Lets_Encrypt_E9

Antes da janela de manutenção:

1. Criar um backup recente da configuração e ter disponíveis a palavra-passe do backup e a Secure Storage Master Key.
2. Em Certificates > Certificate authorities, procurar os nomes exatos. Se não houver correspondências, NC-146082 não exige qualquer alteração.
3. Se houver uma correspondência, documentar o tipo, Subject, Issuer, finalidade e a presença do ícone de chave. O ícone indica que a firewall possui a chave privada da CA.
4. Exportar também uma CA com chave privada em Backup and firmware > Import export > Export selective configuration como CertificateAuthority. Em seguida, identificar os certificados e serviços que dependem da CA, por exemplo VPN, WebAdmin e portais, WAF, SMTP TLS ou TLS Inspection.
5. Remover uma entrada configurada pelo administrador apenas depois de substituir todas as dependências ou confirmar que já não são necessárias. Em seguida, repetir o upgrade.

Não remover uma CA integrada. Se o WebAdmin recusar a eliminação, se faltar a chave privada original ou se alguma referência permanecer incerta, interromper o upgrade e contactar o suporte Sophos. Alterações na base de dados ou através da Advanced Shell não são uma alternativa segura.

Após o upgrade, confirmar que as CA Let’s Encrypt integradas estão presentes, que os certificados dependentes voltam a apresentar Trusted e que os serviços afetados funcionam.

Atribuir o certificado ao serviço correto

Antes da atribuição: garantir um caminho de retorno

Uma mudança de certificado não deve começar pela eliminação da entrada anterior:

1. Importar o novo certificado e a cadeia completa da CA.
2. Verificar os SAN, o emissor, a validade e Trusted.
3. Documentar a atribuição atual e os serviços afetados.
4. Atribuir primeiro o novo certificado a um único serviço.
5. Testar esse serviço através do FQDN e da porta reais.
6. Em caso de erro, voltar a selecionar imediatamente o certificado anterior.
7. Migrar os restantes serviços de forma sequencial e verificar cada um.
8. Remover o certificado anterior apenas quando deixar de ter referências e o novo estado estiver estável.

A WAF e o SMTP podem ser alterados de forma sequencial. Em contrapartida, WebAdmin, User Portal, VPN Portal, Captive Portal e os dois portais SPX são alterados em simultâneo através de uma seleção de certificado comum.

Ao alterar o WebAdmin, deve também ser mantida aberta uma sessão de administrador existente e um acesso de gestão local alternativo até que o login e o certificado tenham sido verificados através do FQDN previsto.

WebAdmin e portais

Em Administration > Admin and user settings > Admin console and end-user interaction, é selecionado um certificado comum para estes serviços:

• WebAdmin Console
• User Portal
• VPN Portal
• Captive Portal
• SPX Registration Portal
• SPX Reply Portal

No campo Certificate, selecionar o novo certificado e guardar com Apply. O certificado tem de abranger todos os FQDN através dos quais os serviços utilizados estão acessíveis. Se, por exemplo, for utilizado admin.example.com para o WebAdmin e vpn.example.com para o VPN Portal, ambos os nomes têm de estar incluídos como SAN ou o planeamento das URL deve ser uniformizado.

O certificado do VPN Portal protege a página HTTPS através da qual os utilizadores obtêm perfis e clientes. Não é automaticamente o Local Certificate nem o Remote Certificate de um túnel IPsec.

WAF

Numa publicação WAF, editar a respetiva regra em Rules and policies > Firewall, ativar HTTPS, selecionar o novo certificado em HTTPS certificate e guardar. A regra utiliza Protect with web server protection. O SNI, o domínio da regra e o SAN do certificado têm de descrever o mesmo hostname.

Uma alteração a uma regra WAF reinicia as regras de Web Server Protection e termina as ligações existentes. Por isso, em aplicações produtivas, a mudança de certificado deve ser realizada numa janela de manutenção. A publicação e a verificação completas estão descritas em Sophos Firewall WAF: publicar servidores web com segurança.

SMTP TLS no modo MTA

Para Mail Protection, selecionar o novo certificado de servidor no campo TLS certificate, em Email > General settings > SMTP TLS configuration, e guardar com Apply. Para comunicação SMTP pública, recomenda-se um certificado de uma CA pública, para que os sistemas remotos possam verificar a identidade sem ser necessário distribuir uma CA própria. O restante fluxo de correio está descrito em Sophos Firewall Mail Protection no modo MTA.

Após a alteração, criar um novo backup da Sophos Firewall e documentar a data de expiração, o responsável e a próxima renovação.

Verificar o certificado e a sua entrega

Verificar o ficheiro antes da importação

Num computador de administração com OpenSSL, é possível verificar um certificado PEM sem o alterar:

openssl x509 -in firewall.pem -noout -subject -issuer -dates -ext subjectAltName -fingerprint -sha256

firewall.pem deve ser substituído pelo caminho local do ficheiro. O resultado deve apresentar o Subject esperado, o emissor, o período de validade, os SAN necessários e uma impressão digital SHA-256. O comando não lê qualquer chave privada.

Verificar o serviço HTTPS a partir do exterior

Testar o WebAdmin, os portais e a WAF a partir de um computador de administração com OpenSSL:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_hostname vpn.example.com -verify_return_error </dev/null

Substituir o FQDN e a porta pelos dados do serviço HTTPS real. -servername envia o nome através de SNI, para que seja selecionado o certificado correto quando existirem vários destinos WAF ou de portal. A verificação é bem-sucedida quando é apresentado o certificado esperado, o hostname corresponde e, no final, aparece Verification: OK.

Se for utilizada uma CA interna, o computador de administração já tem de confiar nessa CA ou recebê-la explicitamente como âncora de confiança para o teste. Caso contrário, um erro de verificação pode dever-se ao equipamento de teste, mesmo que a firewall entregue a cadeia correta.

Verificar SMTP com STARTTLS

Normalmente, o SMTP nas portas 25 ou 587 começa sem encriptação e só depois muda para TLS através de STARTTLS. Para isso, é necessário um teste próprio:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error </dev/null

Substituir mail.example.com e a porta 25 pelo FQDN SMTP e pela porta STARTTLS efetivamente utilizados. Para TLS implícito na porta 465, não se utiliza -starttls smtp. Também neste caso, o certificado esperado, o hostname e Verification: OK têm de corresponder entre si.

Verificar também no browser ou no cliente:

• A URL utiliza um dos SAN incluídos.
• O emissor e a data de expiração correspondem ao novo certificado.
• Não é apresentado qualquer aviso de certificado.
• O serviço WebAdmin, portal, WAF ou de correio esperado funciona.
• Um teste externo não continua a apresentar o certificado de um load balancer ou Reverse Proxy colocado a montante.

Erros típicos e próxima verificação

• Trusted permanece vazio: falta uma CA intermédia, foi importada a CA errada ou a cadeia não corresponde ao certificado de servidor. Verificar o emissor e a ordem das CA.
• A importação é recusada: verificar o formato do ficheiro, a palavra-passe da chave privada, o limite de 30 caracteres, o par certificado-chave e a hora do sistema.
• O browser indica um nome incorreto: o FQDN ou o endereço IP utilizado não consta dos SAN. Comparar a URL, o DNS e os nomes do certificado.
• O browser continua a apresentar o certificado anterior: o serviço ainda utiliza a atribuição anterior ou um proxy colocado a montante termina o TLS. Verificar o destino esperado diretamente com openssl s_client e SNI.
• A WAF entrega o certificado errado: verificar Hosted Address, Listen Port, Domain, SNI e a ordem de regras WAF sobrepostas.
• Apenas alguns clientes apresentam avisos: verificar o Trust Store, os certificados intermédios, a hora do sistema e eventuais limitações de Certificate Pinning desse cliente.
• Após a mudança, um portal deixa de estar acessível: voltar a selecionar o certificado anterior e verificar separadamente o FQDN, a porta, Device Access e a cadeia do certificado.

FAQ