O cliente ownCloud Desktop pode parar de sincronizar e exibir uma mensagem de erro informando que a verificação do certificado SSL falhou, mesmo que o servidor pareça acessível no navegador. Essa mensagem significa que o cliente não conseguiu comprovar que o certificado HTTPS do servidor é válido para o endereço do servidor e confiável para o ambiente do cliente. Trata-se de uma verificação de identidade TLS, não de um erro de senha, e aceitar repetidamente um certificado não verificado pode expor as credenciais e os arquivos da conta a interceptações.
Comece verificando o endereço do servidor, a validade do certificado e a cadeia de certificados. Corrija esses dados no servidor ou em seu proxy reverso, quando possível. Se o servidor usar intencionalmente uma autoridade de certificação (CA) privada, adicione o certificado raiz verificado dessa CA ao repositório de certificados confiáveis do computador. Em seguida, reinicie o cliente de desktop e confirme se a sincronização é retomada sem aviso de certificado.
O ownCloud atualmente possui o ownCloud Classic Server (versões 10 e 11) e o ownCloud Infinite Scale (oCIS). As versões do aplicativo para desktop não são intercambiáveis entre si. Na página de downloads do ownCloud, em 1º de setembro de 2026, o aplicativo para desktop 7.1.1 era compatível com o Infinite Scale, enquanto o ownCloud Classic era suportado pelo cliente 6.x; a página listava a versão 6.0.3 para o Classic. Se um cliente foi atualizado recentemente e o backend é o ownCloud Server 10 ou 11, verifique a compatibilidade antes de tratar uma falha de conexão como um problema de certificado.
Confirme também o URL exato configurado na conta de sincronização. O nome do host nesse URL deve corresponder a um nome no certificado do servidor. Para um servidor Classic instalado em um caminho específico, a conta pode ser semelhante a ` https://cloud.example.com/owncloud<nome_do_servidor>`; uma instalação do oCIS pode usar um URL base diferente. Use o endereço configurado pelo seu administrador em vez de alternar entre um nome de host, endereço IP e domínio alternativo.
Certifique-se de que a data, a hora e o fuso horário do computador estejam corretos. Um relógio muito incorreto pode fazer com que um certificado válido pareça expirado ou ainda inválido. Em seguida, abra o URL exato do ownCloud da conta de sincronização em um navegador no mesmo computador. Inspecione os detalhes do certificado, como o nome do host, a data de expiração e a autoridade emissora. Um navegador que carrega a página sem aviso é uma pista útil, mas não prova que o cliente desktop usa o mesmo repositório de certificados ou que todas as solicitações WebDAV seguem o mesmo caminho de proxy.
Se a falha ocorrer apenas em redes Wi-Fi de hotéis, aeroportos, escolas ou redes públicas, conclua o login no portal dessa rede e tente novamente. As notas de versão do aplicativo para desktop do ownCloud descrevem a pausa na sincronização quando um portal cativo causa uma incompatibilidade de certificado e a retomada da sincronização após a liberação do portal. Uma página de portal que intercepta HTTPS não é motivo para confiar no certificado inesperado.
Peça ao administrador do servidor para verificar o certificado TLS no endpoint público, incluindo o servidor web ou proxy reverso que encerra o HTTPS. O certificado deve estar atualizado, incluir o nome DNS exato usado pelo cliente e ser fornecido com os certificados intermediários necessários. Um erro comum de implementação é configurar apenas o certificado de folha em vez da cadeia completa. Se o certificado foi renovado recentemente, certifique-se de que o proxy reverso esteja apresentando o novo certificado e não um certificado desatualizado.
Em um sistema com OpenSSL, você pode inspecionar o handshake TLS e verificar o nome do host com este comando. Substitua o nome de exemplo pelo nome do host do ownCloud, sem o caminho da URL:
openssl s_client -connect cloud.example.com:443 \
-servername cloud.example.com \
-verify_hostname cloud.example.com \
-verify_return_error </dev/nullAnalise o resultado da verificação e as datas dos certificados. Este teste examina o endpoint do computador onde você o executa; ele não reproduz todos os detalhes do repositório de certificados confiáveis do cliente desktop. Se a saída identificar um certificado expirado, incompatibilidade de nome de host, emissor ausente ou CA não confiável, corrija o certificado ou a cadeia de certificados no endpoint TLS e teste novamente. Não tente corrigir um problema de nome de host ou cadeia de certificados no servidor instalando um certificado não relacionado em cada desktop.
Para um serviço ownCloud exposto à internet, a solução mais simples geralmente é um certificado emitido por uma Autoridade Certificadora (CA) pública confiável pelos sistemas operacionais atuais. Configure o endpoint HTTPS com o certificado e a cadeia completa para o nome de host público e verifique se a renovação está funcionando. Se um proxy reverso estiver gerenciando o HTTPS, o certificado pertence a esse proxy; alterar apenas a configuração do aplicativo ownCloud não alterará o certificado recebido pelos clientes.
Após o administrador atualizar o endpoint, teste o nome de host exato na mesma rede que um computador afetado. As verificações no navegador e na linha de comando não devem mais exibir um aviso de certificado, e o cliente ownCloud deve se reconectar após uma nova tentativa ou reinicialização. Se apenas alguns computadores ainda apresentarem problemas, compare as atualizações do sistema operacional, os repositórios de certificados confiáveis, as configurações de proxy e as versões do cliente.
As organizações geralmente usam uma CA interna para serviços ownCloud privados. Nesse caso, obtenha o certificado da CA raiz da organização por meio de um canal autenticado e verifique sua impressão digital com o administrador. Instale a CA raiz em cada computador cliente afetado usando o processo de gerenciamento de certificados do sistema operacional ou a política de dispositivos gerenciados da empresa. Não adicione um certificado baixado da página de aviso como raiz apenas porque o cliente de sincronização o oferece; primeiro verifique se ele pertence à CA pretendida.
.crtarquivo em `/etc/ca.conf` /usr/local/share/ca-certificates/e execute `sudo apt-get update` sudo update-ca-certificates. Isso atualiza o repositório de certificados confiáveis do sistema para os aplicativos que o utilizam. O Ubuntu alerta que os aplicativos Snap podem não usar automaticamente os certificados adicionados ao repositório do host, portanto, um pacote isolado pode precisar de uma solução de confiança específica para o pacote.Reinicie o cliente ownCloud Desktop após atualizar a confiança. O pacote do cliente e o sistema operacional podem afetar qual repositório de certificados ele lê. Se uma Autoridade Certificadora (CA) estiver instalada e um navegador confiar no site, mas o aplicativo desktop ainda falhar, verifique o comportamento de confiança e os registros do pacote do cliente em vez de importar várias cópias do certificado do servidor aleatoriamente.
O servidor ownCloud possui um occ security:certificatescomando para certificados nos quais o próprio servidor deve confiar, como certificados usados para federação ou armazenamento externo. Trata-se de um repositório de confiança do lado do servidor. Ele não corrige a decisão de confiança tomada pelo cliente de sincronização do usuário ao se conectar ao site do ownCloud. Para um erro de verificação na área de trabalho, corrija o endpoint HTTPS ou a configuração de confiança do computador afetado.
Evite desativar a validação de certificados como uma solução permanente. O cliente de linha de comando do ownCloud documenta uma --trustopção, mas suprimir ou aceitar uma falha de verificação não corrige um certificado expirado, um nome de host incorreto, uma cadeia de CA ausente ou uma conexão não confiável. Use esses controles de confiança somente em um plano de teste deliberado e verificado, e não como substituto para a configuração correta de TLS em uma conta de sincronização de produção.
Se o site abrir, mas a sincronização ainda não conseguir conectar após as verificações TLS serem aprovadas, verifique o WebDAV e a configuração do servidor. O aplicativo ownCloud Desktop usa WebDAV para o ownCloud Classic; o guia de solução de problemas do fornecedor recomenda verificar se o endpoint WebDAV está acessível quando todos os clientes falham, mas o acesso pelo navegador funciona. Se o erro de certificado desaparecer, mas o login ou a sincronização ainda falharem, investigue o erro de autenticação, proxy reverso ou WebDAV separado exibido no log.
O certificado apresentado para o nome de host configurado está válido, contém esse nome de host e está vinculado a uma Autoridade Certificadora (CA) confiável pelo computador cliente. O cliente desktop se reconecta sem solicitar um certificado e um arquivo de teste é sincronizado em ambas as direções. Se a cadeia de certificados públicos estiver correta, mas apenas um cliente gerenciado continuar apresentando falhas, verifique em seguida o relógio, o repositório de certificados confiáveis, o proxy de rede, o portal cativo e a versão compatível do cliente desse computador.
Essas verificações resolvem falhas na verificação de certificados. Elas não corrigem problemas não relacionados à conta, WebDAV, firewall ou disponibilidade do servidor, e os menus exatos variam entre sistemas operacionais e versões do aplicativo ownCloud Desktop. Use os logs do cliente e a configuração do endpoint TLS do servidor para identificar qual lado ainda apresenta divergências.
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.
