Exemplo ilustrativo, não um incidente real: Jordan administra um servidor Zimbra fictício em mail.example.com. Após renovar seu certificado SSL/TLS, Jordan abre um marcador salvo no Console de Administração e recebe uma página "404 Não Encontrado". A renovação pode estar relacionada, mas um erro 404 por si só não prova que o certificado é inválido. O endereço pode estar acessando a porta, o proxy, o nome do host ou a rota de URL incorretos.
Neste exemplo, a ordem mais segura recomendada por Jordan é confirmar a URL pretendida do Console de Administração, testar os endpoints diretos e proxy separadamente, verificar o status do serviço Zimbra e os certificados implantados e, somente então, reimplantar ou reiniciar um componente se as evidências apontarem para isso. Siga as instruções específicas da sua versão de instalação: as portas do Zimbra e os procedimentos de certificado podem variar de acordo com a versão e se o servidor usa o Zimbra Proxy, um balanceador de carga separado ou um proxy reverso externo.
Uma resposta HTTP 404 explícita de um navegador geralmente significa que um servidor HTTP respondeu à solicitação, mas não encontrou um recurso ou rota correspondente. Isso torna as verificações de nome do host, porta, caminho da URL, host virtual e rota do proxy importantes. É diferente de um aviso de certificado do navegador ou de uma falha no handshake TLS. No entanto, um proxy reverso ou um firewall de aplicativos da web também pode retornar um erro 404 quando um host ou rota não corresponde, portanto, o status por si só não identifica qual camada é responsável.
7071Por padrão, o Zimbra documenta o acesso direto ao Console de Administração na porta TCP . Se o Zimbra Proxy estiver configurado para encaminhar o acesso ao Console de Administração, a porta padrão documentada para o proxy é 8080 9071; essa configuração é opcional e pode ser personalizada. O endereço de webmail padrão na porta 8080 443não é automaticamente o mesmo endpoint do Console de Administração direto. Consulte as diretrizes de URL do Console de Administração do Zimbra e a referência de portas do Zimbra para comparar com sua configuração.
Use o nome do host e a porta configurados para sua implantação, em vez de presumir que o URL do seu webmail também seja o URL do Console de Administração. Para uma conexão direta típica, a Zimbra documenta um URL no formato ` <nome do host>:<porta>`. https://server.example.com:7071Um administrador que habilitou o Zimbra Proxy para o console pode, em vez disso, usar o nome do host e a porta do proxy, normalmente `<nome do host > https://proxy.example.com:9071:<porta>`. Não adicione um /admincaminho presumido: use o endereço especificado pela sua instalação ou pela documentação do administrador.
No caso hipotético de Jordan, o marcador antigo aponta para o nome do host do webmail público na porta 443. Jordan o compararia com o endpoint de administração documentado ou configurado. Um erro 404 no host do webmail não comprova que o próprio Console de Administração do Zimbra esteja inativo. Se a porta 7071 estiver intencionalmente bloqueada na internet pública, teste-a apenas a partir de uma rede autorizada ou localmente; não a abra publicamente apenas para testar. As diretrizes de proxy do Zimbra recomendam restringir o acesso direto à porta 7071 quando os administradores usam o endpoint de proxy.
Teste uma rota por vez, usando o nome do host, o esquema e a porta corretos. Se o acesso direto na porta 7071 funcionar a partir de uma rede permitida, mas a rota do proxy na porta 9071 retornar 404, concentre-se na configuração do Console de Administração do proxy e no roteamento do nome do host. Se a rota direta também falhar, verifique o servidor de caixa de correio e o certificado implantado no serviço do Console de Administração. Se ambas as rotas do Zimbra funcionarem, mas a URL pública ainda retornar 404, investigue o balanceador de carga externo, o proxy reverso, a CDN ou o firewall de aplicativos da Web na frente do Zimbra.
Use esta comparação como um diagnóstico, não como um comando para habilitar um novo acesso à rede. Uma porta direta bloqueada pode ser um controle de segurança intencional. O guia de configuração do proxy do Console de Administração do Zimbra descreve o ouvinte opcional da porta 9071 e observa que o Console de Administração do servidor de caixa de correio normalmente permanece na porta 7071.
Faça login no host do Zimbra usando a conta administrativa apropriada para sua instalação e, em seguida, verifique o status do serviço. Os seguintes comandos de status são somente leitura:
su - zimbra
zmcontrol status
zmproxyctl statuszmcontrol statusO comando `zimbra status` relata o status dos componentes do Zimbra. zmproxyctl statusÉ útil quando o Zimbra Proxy está instalado; se o comando não estiver disponível ou se sua topologia não tiver um Zimbra Proxy, ignore-o e verifique o componente que está servindo a URL. Um componente de caixa de correio ou proxy parado pode explicar uma rota com falha, mas não reinicie o servidor inteiro simplesmente porque uma URL retorna um erro 404.
Para uma requisição encaminhada por proxy, o Zimbra identifica /opt/zimbra/log/nginx.access.logos /opt/zimbra/log/nginx.loglogs de proxy úteis. Compare o horário da requisição e o host/caminho solicitado com a resposta registrada nesses logs. Se a requisição nunca aparecer nos logs de proxy do Zimbra, o erro 404 pode estar vindo de um balanceador de carga upstream ou de outro serviço front-end. Consulte o Guia de Proxy do Zimbra e sua seção de solução de problemas .
Um certificado renovado em disco não é necessariamente o mesmo certificado atualmente carregado por todos os serviços do Zimbra. No host do Zimbra, execute a verificação de certificado implantado do gerenciador de certificados usando a sintaxe compatível com a sua versão instalada:
/opt/zimbra/bin/zmcertmgr viewdeployedcrt
Analise os detalhes do certificado do serviço que lida com a rota com falha, incluindo as datas de validade e o nome do host ou nomes alternativos do assunto. Se o navegador acessar a porta 443 por meio de um terminador TLS externo, inspecione também o certificado e a configuração de roteamento nesse ponto; o Zimbra pode não ser o componente que apresenta esse certificado público. Em uma implantação com vários servidores, verifique os nós de proxy e de caixa de correio relevantes. O Zimbra observa que viewdeployedcrtreporta o servidor local, portanto, uma verificação em um nó não comprova que todos os nós possuem o certificado renovado.
Se o certificado correto estiver implantado e o único sintoma for um erro HTTP 404, continue investigando o caminho e o roteamento do proxy em vez de renovar o certificado repetidamente. Se o certificado implantado estiver desatualizado, inválido ou não corresponder à chave privada ou à cadeia de certificados, siga o caminho de implantação de certificado específico para a sua versão do Zimbra.
Antes de alterar os certificados, confirme se você possui a chave privada correspondente, o certificado de servidor renovado e a cadeia de certificados da Autoridade Certificadora (CA) completa fornecida pelo seu provedor. Mantenha a chave privada protegida. No exemplo fictício de Jordan, os arquivos são nomeados `<nome_do_arquivo>` commercial.key, commercial.crt`<nome_do_arquivo>` e ca_chain.crt`<nome_do_arquivo>`; substitua esses nomes pelos caminhos reais no seu servidor. Os nomes de arquivo abaixo são exemplos e não arquivos criados automaticamente pelo Zimbra.
Para um certificado comercial, o Zimbra documenta a verificação de que o certificado corresponde à chave e à cadeia de certificados antes da implantação. Adapte o comando aos seus caminhos e aos privilégios de usuário exigidos pela sua versão:
/opt/zimbra/bin/zmcertmgr verifycrt comm \
/opt/zimbra/ssl/zimbra/commercial/commercial.key \
/tmp/commercial.crt \
/tmp/ca_chain.crt
Prossiga somente se a saída da verificação confirmar que a chave corresponde e a cadeia de certificados é válida. Se a verificação falhar, pare e corrija a chave, o certificado ou a cadeia intermediária. Não implante um certificado incompatível para verificar se isso corrige um erro 404.
Quando a verificação for bem-sucedida, o padrão de implantação de certificados comerciais documentado é o seguinte:
/opt/zimbra/bin/zmcertmgr deploycrt comm \
/tmp/commercial.crt \
/tmp/ca_chain.crt
Esses comandos não são instruções universais de renovação. A documentação de certificados do Zimbra contém notas de privilégio específicas para cada versão, e uma implantação com vários nós exige que o certificado seja instalado e verificado nos nós que atendem o tráfego relevante. Consulte as Ferramentas de Certificado do Console de Administração e da CLI e, para uma configuração baseada no Let's Encrypt, as instruções atuais do certificado Let's Encrypt do Zimbra . Não copie comandos de uma versão anterior sem verificá-los em relação à sua versão instalada.
As notas de implantação de certificados do Zimbra recomendam que os serviços sejam reinicializados para que o novo certificado seja carregado. Escolha a reinicialização mais específica compatível com sua topologia e versão. Se apenas o certificado do Zimbra Proxy ou a configuração de proxy gerada precisar ser recarregada, o comando do serviço de proxy é:
zmproxyctl restart
Uma reinicialização completa zmcontrol restartafeta os serviços do Zimbra nesse host e pode interromper o acesso ao e-mail. Use-a durante uma janela de manutenção, quando o procedimento de implantação de certificado para sua versão exigir, e planeje para todos os nós afetados. O guia de certificados do Zimbra documenta uma reinicialização completa do serviço em seu fluxo de certificado comercial para servidor único; seu guia de proxy explica que uma reinicialização do proxy regenera a configuração do proxy antes de iniciá-lo novamente. Não execute ambos os caminhos de reinicialização automaticamente.
Após o serviço selecionado voltar a funcionar, teste novamente os mesmos URLs: primeiro, o endereço direto ou proxy pretendido do Admin Console a partir de uma rede autorizada e, em seguida, o URL público ou com balanceamento de carga. Confirme se a página de login esperada carrega, se o navegador apresenta o certificado renovado para o nome do host e se os logs relevantes não mostram mais um erro de rota ou de upstream para essa solicitação. No exemplo fictício de Jordan, a verificação consiste em saber se o marcador salvo agora aponta para o endpoint configurado — e não se um resultado de teste inventado foi alcançado.
Se os endpoints diretos e os endpoints de proxy configurados do Zimbra responderem corretamente, mas a URL pública ainda retornar 404, o problema provavelmente está em um front-end externo ou em sua regra de host virtual. Verifique o nome do host e a porta upstream do proxy reverso, as configurações de terminação TLS, o cabeçalho de host encaminhado e as regras de reescrita de URL. Se o certificado público terminar fora do Zimbra, renovar o certificado interno do Zimbra por si só não atualizará o listener externo.
Para uma resposta fornecida pelo Zimbra Proxy, compare o carimbo de data/hora e o status nginx.access.logcom os detalhes em nginx.log. Para uma resposta ausente nesses registros, inspecione o proxy externo ou o balanceador de carga. Evite editar diretamente os arquivos Zimbra NGINX gerados; o serviço de proxy do Zimbra regenera sua configuração ao ser reiniciado, portanto, as alterações persistentes devem seguir os métodos de configuração de proxy suportados para a versão instalada.
A documentação oficial do Zimbra consultada para este guia identifica a porta 7071 como a porta padrão para acesso direto ao Console de Administração e a porta 9071 como uma porta opcional para acesso via proxy ao Console de Administração. Como um erro 404 pode ser gerado em diferentes camadas, utilize esses valores padrão como pistas de diagnóstico e verifique os valores reais na sua versão e topologia do Zimbra.
Diagnostique picos de uso da CPU no navegador do Jitsi Meet e reduza a carga do cliente verificando os mosaicos de vídeo, os efeitos da câmera, os gráficos do navegador e as configurações do host.
Monitore a integridade, a carga da conferência e o tráfego do Jitsi Videobridge com seu endpoint Prometheus integrado e, em seguida, explore e visualize os dados em gráficos no Grafana.
Configure um domínio personalizado para o Jitsi Meet Docker com DNS, URL pública, HTTPS, Let's Encrypt, portas de firewall, configurações de NAT e verificação de ponta a ponta.
Corrija os erros 404 do Console de Administração do Zimbra após a renovação do SSL, verificando o URL e a porta corretos, o roteamento do proxy, o status do serviço, os certificados implantados e os logs.
Aprenda a diagnosticar e corrigir o aviso de configuração do PHP OPcache do Nextcloud, verificando o PHP SAPI ativo, os limites de tamanho, os comentários e as configurações de revalidação.
Solucione problemas de falhas na migração do banco de dados Kopano após uma atualização do MySQL ou MariaDB, verificando backups, versões do servidor, modos SQL, conjunto de caracteres, estado do esquema e logs.
Conecte o Nextcloud ao LDAP ou Active Directory com transporte seguro, filtros de usuários e grupos, atributos de login e uma implementação testada.
Corrija as notificações do Element no Android em telefones sem serviços do Google configurando o UnifiedPush, as permissões do Android, as configurações de bateria e realizando testes de verificação confiáveis.
Remova o aviso de índices de banco de dados ausentes do Nextcloud com o comando oficial occ. Primeiro, faça um backup, visualize as alterações, execute o reparo e verifique o resultado.
Configure o SSO do Keycloak para o Element Web conectando o OIDC ao Synapse, definindo a URL de retorno de chamada exata, mapeando as declarações do usuário e testando o logout.
