Fix Zimbra Certificate Expired: Renew Self-Signed Certificates Safely

A Zimbra server can appear healthy until users suddenly hit a browser warning such as “certificate expired,” mail clients refuse an SSL/TLS connection, or an administrator discovers that the certificate date has passed. The fastest safe response is not to replace every certificate component immediately. First determine what expired, then renew the smallest necessary part.

Zimbra’s current Tech Center procedure for a single-server self-signed deployment uses zmcertmgr to create and deploy certificates. Importantly, Zimbra states that creating a new Certificate Authority (CA) is optional for an ordinary self-signed certificate renewal; you do not need to replace the CA every time the server certificate expires. The official references used for this guide were checked on October 6, 2026: Regenerate Self-Signed SSL Certificate — Single-Server and Administration Console and CLI Certificate Tools.

Why an expired Zimbra certificate causes real service problems

Zimbra uses TLS certificates across services such as the web interface, proxy, LDAP, and mail protocols. Once a certificate is outside its validity period, clients can reject the connection even though the underlying Zimbra processes are still running. A browser warning is therefore only one symptom. Depending on your topology and client policy, you may also see failed secure IMAP/POP/SMTP connections, proxy errors, or LDAP/TLS problems.

There are two different expiration cases to distinguish:

• Only the server certificate is expired. This is the easier case. Keep the existing Zimbra CA if it is still valid, generate a new server certificate, deploy it, and restart services.
• The Zimbra CA itself is expired. Recreate and deploy the CA, then create and deploy a new server certificate signed by that CA. In a multi-server deployment, CA consistency across nodes matters, so do not treat a multi-node environment like a single server.

Before making changes, take a current backup or snapshot appropriate to your environment. Certificate regeneration is normally straightforward, but a backup gives you a recovery point if the server has older customizations, manually installed certificates, or a mixed topology.

Step 1: Confirm that the deployed certificate is actually expired

Switch to the Zimbra account and inspect the certificate currently deployed to local services:

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

Review the validity dates and the certificate subject. If the certificate is still within its validity period, investigate hostname mismatch, an untrusted self-signed CA, an old certificate still served by a proxy, or incorrect server/client time instead of regenerating certificates unnecessarily.

Você também pode verificar o certificado que um cliente remoto realmente recebe em HTTPS. Substitua ` mail.example.com<hostname>` pelo nome do host ao qual os usuários se conectam:

openssl s_client -connect mail.example.com:443 -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Essa verificação remota é útil quando viewdeployedcrttudo parece correto, mas os navegadores ainda veem um certificado antigo, pois testa o certificado apresentado na rede, e não apenas os arquivos no disco.

Etapa 2: Verifique o estado do serviço e decida se a CA também precisa ser renovada.

Antes de alterar os certificados, confirme o estado atual do serviço Zimbra para ter uma base de comparação:

zmcontrol status

Se apenas o certificado do servidor estiver expirado e a CA do Zimbra ainda for válida, ignore a recriação da CA e vá diretamente para os comandos de certificado do servidor na próxima seção. Isso minimiza as alterações na cadeia de confiança. A documentação do Zimbra para servidor único afirma explicitamente que a criação de uma nova CA é opcional e não é necessária sempre que você renova um certificado autoassinado.

Se a Autoridade Certificadora expirou ou se você tem um motivo documentado para substituí-la, crie uma nova:

/opt/zimbra/bin/zmcertmgr createca -new
/opt/zimbra/bin/zmcertmgr deployca

Etapa 3: Gere e implemente um novo certificado de servidor autoassinado.

Para uma renovação simples em um único servidor, a Zimbra documenta a seguinte sequência. O exemplo cria um certificado válido por 365 dias:

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365
/opt/zimbra/bin/zmcertmgr deploycrt self

Se os clientes se conectarem por meio de mais de um nome DNS, gere o certificado com os Nomes Alternativos do Assunto (SAN) necessários, em vez de presumir que o nome de host padrão seja suficiente. A ferramenta de certificados do Zimbra oferece suporte a isso -subjectAltNames. Por exemplo:

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365 -subjectAltNames "mail.example.com,webmail.example.com"
/opt/zimbra/bin/zmcertmgr deploycrt self

Use nomes que realmente apontem para este serviço Zimbra e que seus usuários ou integrações de fato utilizem. Um certificado pode estar válido, mas ainda assim falhar na validação se o nome do host solicitado não estiver coberto pelos valores de assunto/SAN.

Não utilize este procedimento de certificado autoassinado para sobrescrever acidentalmente um certificado comercial/publicamente confiável. Se o seu servidor deve usar um certificado comercial, pare aqui e siga o procedimento de implantação de certificado comercial do Zimbra.

Etapa 4: Verifique a implantação, reinicie o Zimbra e teste a partir do lado do cliente.

Confirme se o Zimbra implementou o novo certificado:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Em seguida, reinicie o Zimbra para que os serviços carreguem o novo certificado:

zmcontrol restart

Após a reinicialização ser concluída, execute:

zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

O resultado desejado é simples: os serviços esperados estão em execução e o certificado implantado agora possui uma data de expiração futura. Por fim, repita o teste remoto do OpenSSL com o nome de host que os usuários realmente acessam. Isso comprova o que está sendo servido na rede após a reinicialização.

Se o navegador ainda exibir o certificado antigo ou expirado,

Não gere um novo certificado imediatamente. Analise as camadas restantes na seguinte ordem:

• Confirme o DNS e o nome do host. Certifique-se de estar testando o mesmo nome de host abrangido pelo novo certificado e de estar acessando o servidor Zimbra pretendido.
• Verifique o caminho do proxy. A documentação de resolução de problemas de certificados do Zimbra observa que, em alguns casos, um proxy pode continuar apresentando um certificado antigo. Inspecione o certificado apresentado remotamente, e não apenas os arquivos de certificado locais. Consulte Erros de certificado do Zimbra .
• Verifique a confiança do cliente. Um certificado autoassinado renovado pode estar válido até a data especificada, mesmo que ainda não seja considerado confiável por navegadores ou clientes de e-mail. Expiração e confiança são questões distintas.
• Verifique a hora do sistema. Um relógio muito incorreto no servidor ou no cliente pode fazer com que um certificado válido pareça inválido ou expirado.
• Verifique a Autoridade Certificadora (CA). Se o certificado de folha for novo, mas a CA emissora do Zimbra estiver expirada, substitua a CA e gere um novo certificado de servidor a partir da nova CA.

O Zimbra com vários servidores exige um nível de cuidado diferenciado.

Para uma instalação com vários nós, use o procedimento para vários servidores em vez de repetir cegamente os comandos de servidor único em cada host. A documentação do Zimbra descreve como criar/implantar a CA e, em seguida, implantar o certificado autoassinado em todos os nós deploycrt self -allserver; ela também alerta que o viewdeployedcrtprocedimento reporta apenas o servidor local. A referência oficial é Regenerate Self-Signed SSL Certificate — Multi-Server .

A incompatibilidade da CA entre um servidor LDAP mestre e as réplicas pode causar problemas de TLS e replicação. Se você opera uma topologia com vários servidores, verifique a cadeia de CA em cada nó afetado e siga a ordem de implantação documentada.

Autoverificação: como saber se o reparo está completo

Antes de encerrar o incidente, verifique todos os seguintes itens:

• zmcontrol statusMostra os serviços Zimbra esperados em execução.
• zmcertmgr viewdeployedcrtMostra um certificado cuja data de validade é futura.
• Uma verificação remota openssl s_clientretorna as mesmas datas de novos certificados para os nomes de host públicos/internos que os usuários realmente utilizam.
• O assunto do certificado ou SAN abrange esse nome de host.
• O webmail e os protocolos de e-mail utilizados no seu ambiente podem estabelecer conexões TLS.
• Se você substituiu intencionalmente a Autoridade Certificadora (CA) do Zimbra, os clientes ou sistemas internos que utilizam ou confiam na CA antiga foram atualizados conforme necessário.

Para o vencimento rotineiro de um certificado de servidor, a abordagem menos disruptiva geralmente consiste em manter uma Autoridade Certificadora (CA) Zimbra ainda válida, criar um novo certificado autoassinado para o servidor, implantá-lo, reiniciar os serviços e verificar o certificado externamente ao servidor. A CA deve ser substituída somente quando expirar ou houver outro motivo claro para a sua substituição. Essa abordagem corrige a interrupção imediata, evitando alterações desnecessárias na cadeia de confiança.