Solucione un error de certificado de sincronización de ownCloud Desktop corrigiendo el certificado TLS que presenta el servidor o instalando la CA privada de confianza que lo emitió. Primero, confirme que el certificado sea válido para el nombre de host exacto del servidor e incluya su cadena intermedia; no desactive las comprobaciones de certificados ni ignore las advertencias sin explicación.
Verifique la versión del cliente antes de realizar cualquier cambio. A partir de octubre de 2026, las notas de la versión de ownCloud indican que la aplicación de escritorio es compatible con las versiones 7.1.0 y 6.0.3: la serie 7.x solo admite Infinite Scale, mientras que ownCloud Server Classic 10 u 11 requiere la serie 6.x. Las mismas notas también explican que un portal cautivo puede provocar una discrepancia en el certificado y pausar la sincronización. Consulte las notas de la versión de la aplicación de escritorio de ownCloud .
Compara la URL del servidor que aparece en la aplicación de escritorio de ownCloud con la dirección que funciona en tu navegador. Utiliza el mismo nombre de host y ruta. En ocasiones, un navegador puede recuperar automáticamente un certificado intermedio que falte, mientras que un cliente de escritorio no puede.
Inspeccione los detalles del certificado y confirme que su Nombre Alternativo del Sujeto (SAN), es decir, los nombres de host que cubre, incluya el nombre de host que ingresó. Un certificado files.internal.localno cubre cloud.example.comnecesariamente un servidor si ambos nombres llegan al mismo servidor. Verifique las fechas de validez y el emisor, y compruebe la hora del equipo; una fecha local incorrecta puede hacer que un certificado válido aparezca como vencido o aún no válido.
Si el navegador también informa un error o varios dispositivos fallan, es probable que la reparación se encuentre en el servidor o en el proxy inverso. Si solo falla un equipo, compruebe su almacén de confianza, la hora, el proxy y la versión del cliente. La guía de solución de problemas de la aplicación de escritorio de ownCloud recomienda confirmar el acceso al navegador y comprobar la URL del servidor o el proxy cuando los clientes de escritorio no pueden conectarse.
Solicite al administrador del servidor que instale un certificado cuyo SAN incluya el nombre de host público que ingresan los usuarios, cuyas fechas estén actualizadas y cuya clave privada coincida con el certificado. Un certificado puede cifrar una conexión y aun así fallar en la verificación de identidad si su nombre de host es incorrecto o no se puede verificar su emisor.
El punto final HTTPS debe presentar el certificado del servidor y los certificados CA intermedios necesarios en el orden correcto. Normalmente, no debería enviar el certificado raíz de la CA; los clientes ya deben confiar en él. Verifique el proxy inverso o el balanceador de carga que gestiona HTTPS, no solo el host de ownCloud. Es posible que el proxy siga sirviendo una cadena de certificados antigua o incompleta después de que se hayan actualizado los archivos de backend.
Para un diagnóstico rápido desde una máquina con OpenSSL, ejecute este comando después de reemplazar el nombre de host de ejemplo:
openssl s_client -connect cloud.example.com:443 -servername cloud.example.com -showcerts -verify_return_error </dev/null-servernameEnvía el nombre de host para la Indicación de Nombre de Servidor cuando un servidor aloja varios sitios TLS. Revise la cadena y el resultado de la verificación: un fallo del emisor sugiere la falta de un certificado intermedio o una CA no confiable; un error de nombre de host o fecha requiere corregir el certificado o la URL. Esto verifica solo el punto final alcanzado desde esa máquina y ruta de red. Consulte la referencia de OpenSSLs_client .
Si su organización utiliza una autoridad de certificación (CA) privada, obtenga su certificado raíz a través de un canal autenticado y verifique su huella digital con el administrador. Instale ese certificado de CA (no la clave privada del servidor) en el almacén de confianza del sistema operativo y, a continuación, reinicie el cliente ownCloud. En Debian o Ubuntu, un administrador puede colocar un certificado de CA codificado en PEM con extensión .pm en .crty /usr/local/share/ca-certificates/ejecutar sudo update-ca-certificates. Otras plataformas utilizan diferentes herramientas de almacén de confianza.
El comportamiento de TLS puede variar según la compilación del cliente y la plataforma. Qt documenta que su configuración TLS predeterminada utiliza la lista de CA del sistema, pero no todos los paquetes se configuran necesariamente de la misma manera. Si agregar la CA no soluciona el problema, pida al administrador que revise el paquete del cliente y los registros; nunca importe un certificado de un navegador no verificado. Consulte la documentación de configuración de certificados CA de Qt . Las preguntas frecuentes del servidor de ownCloud sobre certificados SSL autofirmados remiten a los administradores a su guía de seguridad; no recomiendan debilitar la verificación normal del cliente.
Un certificado de servidor autofirmado no es lo mismo que un certificado emitido por una CA privada de confianza. Si se utiliza una CA privada, distribuya y confíe en la raíz de la CA a través de un canal controlado y, a continuación, proporcione un certificado de servidor que coincida con el nombre de host y que esté firmado por dicha CA. Evite aceptar una solicitud de cambio de certificado como solución habitual: esto puede acostumbrar a los usuarios a aprobar a un impostor durante un ataque de intermediario.
Si el fallo se produce únicamente en redes Wi-Fi públicas, redes de hoteles o una red corporativa recientemente modificada, abra un navegador y complete primero la página de inicio de sesión de la red. Un portal cautivo intercepta las solicitudes antes del inicio de sesión y puede presentar un certificado que no pertenece al nombre de host de ownCloud. Las notas de la versión de ownCloud indican explícitamente que la sincronización puede pausarse cuando un portal cautivo provoca una discrepancia en el certificado y debería reiniciarse una vez que se haya borrado el contenido del portal.
En un dispositivo de trabajo administrado, un proxy de inspección HTTPS puede reemplazar el certificado del servidor por uno firmado por la CA de inspección de la organización. Consulte con el departamento de TI si esto es lo esperado y si la CA aprobada está instalada en el cliente de escritorio. No omita la verificación para que funcione la sincronización; el administrador debe corregir la configuración del proxy o de confianza.
Cierre y vuelva a abrir el cliente, confirme que la cuenta se conecta a la URL HTTPS exacta y espere a que el estado de sincronización indique que se ha completado. Cree un archivo de prueba pequeño en la carpeta de sincronización y confirme que aparece en la interfaz web; a continuación, revise el registro del cliente para detectar cualquier mensaje recurrente de verificación TLS. Si el fallo del certificado persiste, envíe al administrador el nombre de host exacto, la versión del cliente, el sistema operativo, la hora del fallo y el error específico del certificado; nunca envíe contraseñas ni claves privadas. Si la interfaz web de ownCloud funciona, pero todas las aplicaciones de escritorio compatibles siguen fallando, proporcione la URL del servidor y la salida de diagnóstico TLS para que el administrador pueda investigar el proxy o la cadena de certificados.
Restaure la sincronización de ownCloud Desktop comprobando el nombre de host del servidor, la cadena de certificados, la confianza de la CA privada y los problemas del portal cautivo sin deshabilitar la verificación TLS.
Utilice el informe de archivos no válidos para identificar archivos principales o firmas de aplicaciones que no coincidan, restaurar los archivos de lanzamiento correctos y verificar la integridad de forma segura.
Implementa ownCloud Infinite Scale desde su ejemplo oficial de Compose, configura los dominios y el almacenamiento persistente, y luego verifica TLS, los contenedores y el primer inicio de sesión.
Configure el controlador S3NG, los permisos del bucket, el almacenamiento persistente de metadatos y el tamaño de carga para que ownCloud Infinite Scale pueda almacenar el contenido de los archivos de forma fiable.
Descubre por qué se detiene una carga en ownCloud Server cerca de completarse comprobando el estado del archivo, la cuota, el espacio temporal en disco, los límites de PHP y los tiempos de espera del proxy.
Configure AllowOverride All solo para la raíz web de ownCloud, valide el vhost Apache activo y recargue de forma segura para restaurar las reglas de .htaccess.
Habilite la aplicación de auditoría empresarial de ownCloud, dirija los eventos de admin_audit a un archivo de registro protegido y confirme que se están registrando las acciones reales de los usuarios.
Alinea el emisor del reino, el cliente web y las reclamaciones de usuario de Keycloak para permitir que ownCloud Infinite Scale inicie sesión de forma fiable en los clientes web y móviles.
Transfiere los archivos propios y los recursos compartidos salientes con el comando occ de ownCloud, comprende qué se queda y verifica el acceso antes de eliminar la cuenta antigua.
Aprende cuándo los índices de la base de datos ownCloud 10 necesitan atención, cómo aplicar de forma segura las actualizaciones de esquema compatibles y cuándo la optimización de consultas o un cambio en la base de datos es la mejor solución.
