Corrija um erro de certificado de sincronização do ownCloud Desktop corrigindo o certificado TLS apresentado pelo servidor ou instalando a CA privada confiável que o emitiu. Primeiro, confirme se o certificado é válido para o nome de host exato do servidor e inclui sua cadeia intermediária; não desative as verificações de certificado nem ignore avisos sem explicação.
Verifique a versão do cliente antes de fazer qualquer alteração. Em outubro de 2026, as notas de lançamento do ownCloud listam o aplicativo Desktop nas versões 7.1.0 e 6.0.3: a série 7.x suporta apenas o Infinite Scale, enquanto o ownCloud Server Classic 10 ou 11 requer a série 6.x. As mesmas notas também explicam que um portal cativo pode causar uma incompatibilidade de certificado e pausar a sincronização. Consulte as notas de lançamento do aplicativo Desktop do ownCloud .
Compare o URL do servidor exibido no aplicativo ownCloud Desktop com o endereço que funciona no seu navegador. Use o mesmo nome de host e caminho. Um navegador pode, às vezes, recuperar automaticamente um certificado intermediário ausente, enquanto um cliente desktop não consegue.
Inspecione os detalhes do certificado e confirme se o Nome Alternativo do Assunto (SAN) — os nomes de host que ele abrange — inclui o nome de host que você inseriu. Um certificado para um nome de host files.internal.localnão abrange outro cloud.example.comapenas porque ambos os nomes alcançam o mesmo servidor. Verifique as datas de validade e a autoridade emissora, e confira o relógio do computador; uma data local incorreta pode fazer com que um certificado válido pareça expirado ou ainda não válido.
Se o navegador também reportar um erro ou se vários dispositivos falharem, a solução provável está no servidor ou no proxy reverso. Se apenas um computador falhar, verifique o armazenamento de certificados confiáveis, o relógio, o proxy e a versão do cliente. As orientações de solução de problemas do aplicativo para desktop do ownCloud recomendam confirmar o acesso pelo navegador e verificar o URL do servidor ou o proxy quando os clientes de desktop não conseguirem se conectar.
Solicite ao administrador do servidor que instale um certificado cujo SAN inclua o nome de host público inserido pelos usuários, cujas datas estejam atualizadas e cuja chave privada corresponda à do certificado. Um certificado pode criptografar uma conexão e ainda assim falhar na verificação de identidade se o nome de host estiver incorreto ou se a autoridade emissora não puder ser verificada.
O endpoint HTTPS deve apresentar o certificado do servidor e os certificados CA intermediários necessários na ordem correta. Normalmente, não deve enviar o certificado CA raiz; os clientes precisam confiar nessa raiz. Verifique o proxy reverso ou balanceador de carga que encerra o HTTPS, e não apenas o host do ownCloud. O proxy pode ainda estar servindo uma cadeia de certificados antiga ou incompleta após a atualização dos arquivos de backend.
Para um diagnóstico rápido a partir de uma máquina com OpenSSL, execute este comando após substituir o nome do host de exemplo:
openssl s_client -connect cloud.example.com:443 -servername cloud.example.com -showcerts -verify_return_error </dev/null-servernameEnvia o nome do host para Indicação de Nome do Servidor (Server Name Indication) quando um servidor hospeda vários sites TLS. Analise a cadeia e o resultado da verificação: uma falha na autoridade emissora sugere a ausência de uma autoridade certificadora intermediária ou não confiável; um erro no nome do host ou na data requer a correção do certificado ou da URL. Esta verificação abrange apenas o endpoint alcançado a partir daquela máquina e caminho de rede. Consulte a referência do OpenSSLs_client .
Se sua organização utiliza uma autoridade de certificação (CA) privada, obtenha o certificado raiz por meio de um canal autenticado e verifique a impressão digital com o administrador. Instale esse certificado da CA — não a chave privada do servidor — no armazenamento de certificados confiáveis do sistema operacional e reinicie o cliente ownCloud. No Debian ou Ubuntu, um administrador pode colocar um certificado da CA codificado em PEM com a extensão .pem em `/etc/account.conf` .crte /usr/local/share/ca-certificates/executar `account.conf` sudo update-ca-certificates. Outras plataformas utilizam ferramentas diferentes para armazenamento de certificados confiáveis.
O comportamento do TLS pode variar de acordo com a versão e a plataforma do cliente. A documentação do Qt indica que sua configuração padrão de TLS utiliza a lista de CAs do sistema, mas nem todos os pacotes são configurados da mesma forma. Se adicionar a CA não resolver o problema, peça ao administrador para verificar o pacote e os logs do cliente; nunca importe um certificado de um navegador que apresente um aviso de certificado não verificado. Consulte a documentação de configuração de certificados CA do Qt . As Perguntas Frequentes do servidor ownCloud sobre certificados SSL autoassinados direcionam os administradores para suas orientações de segurança; a documentação não recomenda enfraquecer a verificação normal do cliente.
Um certificado de servidor autoassinado não é o mesmo que um certificado emitido por uma Autoridade Certificadora (AC) privada confiável. Se uma AC privada for utilizada, distribua e confie na raiz da AC por meio de um canal controlado e, em seguida, forneça um certificado de servidor correspondente ao nome do host, assinado por essa AC. Evite aceitar uma solicitação de alteração de certificado como solução alternativa rotineira: isso pode levar os usuários a aprovar um impostor durante um ataque do tipo "homem no meio".
Se a falha ocorrer apenas em redes Wi-Fi públicas, redes de hotéis ou em uma rede corporativa recém-alterada, abra um navegador e conclua primeiro a página de login da rede. Um portal cativo intercepta as solicitações antes do login e pode apresentar um certificado que não pertence ao hostname do ownCloud. As notas de versão do ownCloud afirmam explicitamente que a sincronização pode ser pausada quando um portal cativo causa uma incompatibilidade de certificado e deve ser reiniciada após a limpeza do portal.
Em um dispositivo de trabalho gerenciado, um proxy de inspeção HTTPS pode substituir o certificado do servidor por um assinado pela CA de inspeção da organização. Consulte o departamento de TI para saber se isso é esperado e se a CA aprovada está instalada no cliente de desktop. Não ignore a verificação para que a sincronização funcione; a configuração do proxy ou da confiança precisa ser corrigida pelo administrador.
Feche e abra novamente o cliente, confirme se a conta se conecta ao URL HTTPS correto e aguarde a conclusão da sincronização. Crie um pequeno arquivo de teste na pasta de sincronização e confirme se ele aparece na interface web. Em seguida, verifique o log do cliente em busca de mensagens recorrentes de verificação TLS. Se a falha no certificado persistir, envie ao administrador o nome do host exato, a versão do cliente, o sistema operacional, o horário da falha e o erro específico do certificado — nunca envie senhas ou chaves privadas. Se a interface web do ownCloud funcionar, mas todos os aplicativos de desktop compatíveis continuarem apresentando falhas, forneça o URL do servidor e a saída de diagnóstico TLS para que o administrador possa investigar o proxy ou a cadeia de certificados.
Atribua limites de armazenamento em bytes para novos usuários do ownCloud Infinite Scale por função, com um exemplo de proxy.yaml e uma lista de verificação de segurança.
Restaure a sincronização do ownCloud para desktop verificando o nome do host do servidor, a cadeia de certificados, a confiança da CA privada e problemas com o portal cativo, sem desativar a verificação TLS.
Use o relatório de arquivos inválidos para identificar arquivos principais ou assinaturas de aplicativos incompatíveis, restaurar os arquivos de versão corretos e verificar a integridade dos dados com segurança.
Implante o ownCloud Infinite Scale a partir do exemplo oficial do Compose, configure os domínios e o armazenamento persistente e, em seguida, verifique o TLS, os contêineres e o primeiro login.
Configure o driver S3NG, as permissões do bucket, o armazenamento persistente de metadados e o dimensionamento de upload para que o ownCloud Infinite Scale possa armazenar o conteúdo dos arquivos de forma confiável.
Descubra por que um upload para o servidor ownCloud para perto da conclusão, verificando o status do arquivo, a cota, o espaço em disco temporário, os limites do PHP e os tempos limite do proxy.
Defina AllowOverride All apenas para a raiz da web do ownCloud, valide o vhost ativo do Apache e recarregue com segurança para restaurar as regras do .htaccess.
Ative o aplicativo Enterprise Auditing do ownCloud, direcione os eventos admin_audit para um arquivo de log protegido e confirme se as ações reais do usuário estão sendo registradas.
Alinhe as declarações do emissor de domínio, do cliente web e do usuário do Keycloak para permitir que o ownCloud Infinite Scale faça login de usuários de forma confiável nos clientes web e móveis.
Transfira arquivos próprios e compartilhamentos de saída com o comando occ do ownCloud, entenda o que permanece nos arquivos salvos e verifique o acesso antes de excluir a conta antiga.
