Como instalar um certificado SSL comercial em um servidor Zimbra

Um certificado SSL comercial no Zimbra pode falhar de diversas maneiras frustrantes, mesmo quando a autoridade certificadora afirma que o certificado foi emitido corretamente. Os problemas mais comuns geralmente não estão no certificado em si: a chave privada não corresponde ao certificado retornado, uma autoridade certificadora intermediária está ausente, o nome do host está ausente do Nome Alternativo do Assunto (SAN) do certificado ou o administrador implanta os arquivos antes de validar a cadeia de certificados.

A maneira mais segura de lidar com essa tarefa é tratá-la como uma sequência de verificações, em vez de um único comando de "instalar certificado". A ferramenta de certificado documentada do Zimbra, `zimbra- zmcertmgrcertificate`, pode criar uma solicitação de assinatura de certificado (CSR), verificar a chave privada e a cadeia de autoridades certificadoras (CA), implantar o certificado nos serviços do Zimbra e exibir o certificado atualmente ativo. O Centro Técnico oficial do Zimbra documenta esses comandos em seu guia de Ferramentas de Certificado para Console de Administração e CLI .

Como deve ser uma instalação bem-sucedida do SSL Zimbra

Antes de alterar qualquer coisa, defina o resultado desejado. Uma implementação correta deve atender a todas estas condições:

• A lista SAN do certificado inclui todos os nomes de host públicos que os clientes realmente usam, como mail.example.com.
• O certificado emitido corresponde à chave privada armazenada para o certificado comercial.
• O Zimbra consegue validar toda a cadeia, desde o certificado do servidor, passando pelos certificados das autoridades certificadoras intermediárias, até a autoridade certificadora raiz.
• zmcertmgr deploycrt commA operação é concluída sem erros de incompatibilidade de chave ou validação de cadeia.
• Os serviços do Zimbra foram reiniciados sem problemas.
• zmcertmgr viewdeployedcrtExibe o certificado esperado.
• Um navegador ou cliente TLS que se conecta ao nome de host público vê o novo certificado e não recebe nenhum aviso de confiança.

Se uma dessas verificações falhar, corrija essa camada específica antes de continuar. A reimplementação repetida dos mesmos arquivos raramente resolve um problema de chave, SAN ou cadeia.

Antes de começar: escolha o fluxo de trabalho de certificado correto.

A página atual do Centro Técnico do Zimbra observa que, no Zimbra 8.7 e versões posteriores, o zmcertmgrcomando é executado como o zimbrausuário. Também documenta que a chave privada comercial deve ser nomeada commercial.keyno arquivo /opt/zimbra/ssl/zimbra/commerciale que o certificado do servidor, juntamente com o arquivo da cadeia de CA, deve ser armazenado em um diretório temporário antes da implantação.

Passo 1: faça backup do material do certificado atual

Não comece excluindo o diretório SSL existente. Primeiro, crie um backup que possa ser restaurado caso a nova implantação falhe. Como administrador (root), um exemplo conservador seria:

cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.backup-$(date +%Y%m%d-%H%M%S)

Anote também o certificado atualmente implantado antes de alterá-lo:

su - zimbra
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Isso fornece uma base de comparação após a alteração. Se o seu ambiente tiver vários nós do Zimbra, capture o estado atual do certificado em cada servidor relevante, em vez de presumir que sejam idênticos.

Etapa 2: gere um CSR com os nomes de host que você realmente precisa.

Para um novo certificado comercial, crie a CSR com o nome do host de produção e quaisquer SANs adicionais. A documentação do Zimbra descreve a seguinte sintaxe:

/opt/zimbra/bin/zmcertmgr createcsr comm -new \
-subject "/C=US/ST=CA/L=Sunnyvale/O=Example/OU=IT/CN=mail.example.com" \
-subjectAltNames "mail.example.com"

Se os usuários também se conectarem por meio de outro nome, como webmail.example.com, inclua-o na lista SAN ao solicitar o certificado. Os clientes TLS modernos validam os nomes de host em relação às SANs; portanto, um certificado que pareça correto apenas pelo nome comum ainda pode gerar um aviso do navegador se o nome do host estiver ausente.

Analise o CSR antes de enviá-lo à sua autoridade certificadora:

/opt/zimbra/bin/zmcertmgr viewcsr comm /opt/zimbra/ssl/zimbra/commercial/commercial.csr

Ponto de verificação: pare aqui se os nomes DNS solicitados estiverem incorretos. Emitir o certificado primeiro e descobrir posteriormente a ausência de um SAN significa que, normalmente, você precisará que a Autoridade Certificadora (CA) o reemita.

Etapa 3: coletar o certificado do servidor e a cadeia de CA completa.

Após a validação, sua CA comercial normalmente retorna o certificado do servidor mais um ou mais certificados intermediários. O procedimento oficial de certificado comercial de nó único do Zimbra espera o certificado do servidor no formato PEM e instrui os administradores a combinar os certificados intermediários e da CA raiz em um arquivo de cadeia.

Um layout de palco típico é:

/tmp/commercial.crt
/tmp/ca_intermediary.crt
/tmp/ca.crt

Em seguida, construa a cadeia na ordem documentada pelo Zimbra:

cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt

Utilize os arquivos fornecidos pela sua autoridade certificadora para o seu produto de certificado específico. Não copie um certificado intermediário de um tutorial não relacionado apenas porque o nome da marca da AC parece semelhante. As hierarquias de AC mudam com o tempo, e o uso de um certificado intermediário incorreto é uma causa comum de problemas unable to get local issuer certificate.

Etapa 4: verifique a chave privada, o certificado do servidor e a cadeia de certificados antes da implantação.

Este é o ponto de verificação de segurança mais importante. Execute o comando de verificação documentado como usuário Zimbra nas versões atuais do Zimbra:

su - zimbra
/opt/zimbra/bin/zmcertmgr verifycrt comm \
/opt/zimbra/ssl/zimbra/commercial/commercial.key \
/tmp/commercial.crt \
/tmp/ca_chain.crt

Uma verificação bem-sucedida indica que o certificado e a chave privada correspondem e que o certificado é válido. A documentação da ferramenta de certificados do Zimbra explica que ela verifycrtcombina uma verificação de chave e uma verificação da cadeia de certificados.

Se a verificação falhar, escolha a correção com base no erro.

• Certificado e chave privada incompatíveis: o certificado da CA não foi emitido pela CSR associada ao usuário atual commercial.key. Restaure a chave correta ou emita um novo certificado a partir de uma nova CSR.
• Não foi possível validar a cadeia de certificados: o pacote intermediário/raiz está incompleto, na ordem incorreta, expirado ou não é a cadeia correta para este certificado de servidor. Obtenha a cadeia correta da Autoridade Certificadora emissora.
• Certificado expirado: não o implemente. Solicite um certificado atual e verifique também se um certificado intermediário ou raiz na cadeia expirou. O Zimbra documenta esse modo de falha em seu guia de solução de problemas de CA raiz expirada .
• Nome do host ausente: a verificação pode não representar a mesma verificação de nome do host que um navegador realiza. Inspecione os SANs emitidos e emita novos se o nome público não estiver presente.

Etapa 5: implantar o certificado comercial

Você só deve implantá-lo após a verificação ser bem-sucedida:

/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt

O processo de implantação documentado do Zimbra copia o certificado comercial para sua área SSL, anexa a cadeia de CA, atualiza a configuração do certificado e instala o material de certificado para serviços como MTA, LDAP, proxy e componentes de caixa de correio, conforme aplicável ao servidor.

Não sobrescreva manualmente keystores Java ou arquivos de certificado de serviço aleatórios, a menos que a documentação da sua versão específica do Zimbra exija isso explicitamente. O objetivo zmcertmgré manter a consistência do material de certificado específico do serviço.

Etapa 6: reinicie os serviços do Zimbra

Após a implantação, reinicie o Zimbra:

su - zimbra
zmcontrol restart

Em seguida, verifique o estado do serviço:

zmcontrol status

Se um serviço não retornar ao estado inicial Running, investigue antes de declarar a alteração do certificado como concluída. Problemas com certificados podem afetar LDAP, proxy, caixas de correio ou outras comunicações dependentes de TLS, especialmente em instalações com vários nós.

Etapa 7: verifique o resultado tanto no Zimbra quanto no lado do cliente.

Use primeiro a visualização de certificados do próprio Zimbra:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Você também pode verificar se algum certificado de serviço implantado está perto de expirar:

/opt/zimbra/bin/zmcertmgr checkcrtexpiration all -days 30

Por fim, teste o nome de host público exato que os usuários acessam. Uma verificação útil do OpenSSL a partir de outra máquina é:

openssl s_client -connect mail.example.com:443 -servername mail.example.com -showcerts

Procure o certificado folha esperado, o nome de host correto, uma cadeia completa e um resultado de verificação bem-sucedido. Em seguida, abra o mesmo URL HTTPS em um navegador atual. Um teste no navegador é importante porque testa o nome de host que os usuários realmente acessam, e não apenas os arquivos de certificado no disco.

Quando o procedimento padrão não é suficiente

Mude sua abordagem em vez de forçar as etapas de nó único se alguma destas condições se aplicar:

• Zimbra com vários nós: a implantação de certificados pode precisar abranger funções de proxy, caixa de correio, LDAP e MTA em hosts diferentes. A ferramenta de certificados do Zimbra oferece suporte a opções para vários servidores, mas verifique o procedimento para sua topologia antes de usá-las.
• O proxy reverso ou balanceador de carga externo encerra o TLS: o certificado público também pode precisar ser instalado nesse dispositivo. Um certificado Zimbra válido por si só não alterará o que os clientes veem se o TLS for encerrado na origem.
• Você está importando uma chave existente: certifique-se de que ela esteja localizada no mesmo lugar onde o Zimbra espera encontrar a chave privada comercial e que as permissões correspondam aos requisitos da versão antes da verificação.
• Sua Autoridade Certificadora (AC) fornece apenas um pacote intermediário: siga as instruções da cadeia de certificados atual da AC em vez de criar um certificado raiz. O Zimbra precisa de uma cadeia que possa validar; os arquivos exatos dependem da autoridade emissora.
• O certificado foi renovado com o mesmo nome de host, mas com uma chave diferente: atualize a chave privada correspondente antes da verificação. Um commercial.keycertificado anterior não pode ser validado para um novo par de chaves.

Autoverificação final

A instalação só estará completa quando todas as seguintes condições forem verdadeiras: verifycrto processo for deploycrtaprovado, os serviços do Zimbra voltarem a funcionar, viewdeployedcrto novo certificado for exibido e uma conexão TLS externa com o nome de host real receber o mesmo certificado válido, sem aviso de confiança ou de nome de host.

Para obter informações sobre a sintaxe dos comandos e o comportamento específico de cada versão, utilize a documentação oficial do certificate-tools do Zimbra como referência principal. Os exemplos aqui apresentados utilizam mail.example.comvalores genéricos; substitua nomes, arquivos de certificado e detalhes organizacionais pelos valores emitidos para o seu ambiente.