Es posible que el cliente ownCloud Desktop deje de sincronizarse e informe de un error en la verificación del certificado SSL, incluso cuando el servidor parezca accesible en el navegador. Este mensaje indica que el cliente no pudo determinar si el certificado del servidor HTTPS es válido para la dirección del servidor y si el entorno del cliente confía en él. Se trata de una comprobación de identidad TLS, no de un error de contraseña, y aceptar repetidamente un certificado no verificado puede exponer las credenciales y los archivos de la cuenta a posibles interceptaciones.
Comience por verificar la dirección del servidor, la validez del certificado y la cadena de certificados. Corrija estos datos en el servidor o en su proxy inverso, si es posible. Si el servidor utiliza intencionadamente una autoridad de certificación (CA) privada, agregue el certificado raíz verificado de dicha CA al almacén de certificados de confianza del equipo. A continuación, reinicie el cliente de escritorio y confirme que la sincronización se reanuda sin advertencias de certificado.
ownCloud cuenta actualmente con ownCloud Classic Server (versiones 10 y 11) y ownCloud Infinite Scale (oCIS). No todas las versiones de la aplicación de escritorio son intercambiables. Según la información de la página de descargas de ownCloud del 1 de septiembre de 2026, la aplicación de escritorio 7.1.1 es para Infinite Scale, mientras que ownCloud Classic es compatible con un cliente 6.x; la página indica la versión 6.0.3 para Classic. Si un cliente se actualizó recientemente y el backend es ownCloud Server 10 u 11, compruebe la compatibilidad antes de considerar un fallo de conexión como un error de certificado.
Confirme también la URL exacta configurada en la cuenta de sincronización. El nombre de host de dicha URL debe coincidir con un nombre en el certificado del servidor. Para un servidor clásico instalado en una ruta, la cuenta podría tener este aspecto https://cloud.example.com/owncloud; una instalación de oCIS podría usar una URL base diferente. Utilice la dirección configurada por su administrador en lugar de alternar entre un nombre de host, una dirección IP y un dominio alternativo.
Asegúrese de que la fecha, la hora y la zona horaria del ordenador sean correctas. Un reloj muy descalibrado puede hacer que un certificado válido aparezca como caducado o aún no válido. A continuación, abra la URL exacta de ownCloud de la cuenta de sincronización en un navegador del mismo ordenador. Compruebe los detalles del certificado: nombre de host, fecha de caducidad y emisor. Que el navegador cargue la página sin advertencias es un indicio útil, pero no demuestra que el cliente de escritorio utilice el mismo almacén de certificados ni que todas las solicitudes WebDAV sigan la misma ruta de proxy.
Si el fallo solo se produce en redes Wi-Fi públicas, como hoteles, aeropuertos, escuelas o de otros tipos, finalice el proceso de inicio de sesión en esa red e inténtelo de nuevo. Las notas de la versión de la aplicación de escritorio de ownCloud describen cómo pausar la sincronización cuando un portal cautivo provoca una discrepancia en el certificado y cómo reiniciarla una vez que se haya solucionado el problema del portal. Que una página del portal intercepte HTTPS no justifica confiar en el certificado inesperado.
Solicite al administrador del servidor que verifique el certificado TLS en el punto final público, incluyendo el servidor web o el proxy inverso que gestiona HTTPS. El certificado debe estar vigente, incluir el nombre DNS exacto utilizado por el cliente y servirse con los certificados intermedios necesarios. Un error común de implementación es configurar solo el certificado hoja en lugar de la cadena completa. Si el certificado se renovó recientemente, asegúrese de que el proxy inverso presente el certificado nuevo y no uno obsoleto.
En un sistema con OpenSSL, puede inspeccionar el protocolo de enlace TLS y verificar el nombre de host con este comando. Reemplace el nombre de ejemplo con el nombre de host de ownCloud, sin la ruta URL:
openssl s_client -connect cloud.example.com:443 \
-servername cloud.example.com \
-verify_hostname cloud.example.com \
-verify_return_error </dev/nullRevise el resultado de la verificación y las fechas de los certificados. Esta prueba examina el punto final desde el equipo donde se ejecuta; no reproduce todos los detalles del almacén de confianza del cliente de escritorio. Si el resultado identifica un certificado caducado, una discrepancia en el nombre de host, un emisor faltante o una CA no confiable, corrija el certificado o la cadena en el punto final TLS y vuelva a realizar la prueba. No intente solucionar un problema de nombre de host o cadena en el servidor instalando un certificado no relacionado en cada equipo.
Para un servicio ownCloud con acceso a internet, la solución más sencilla suele ser un certificado emitido por una CA pública de confianza para los sistemas operativos actuales. Configure el punto final HTTPS con el certificado y la cadena completa para el nombre de host público y verifique que la renovación funcione correctamente. Si un proxy inverso gestiona HTTPS, el certificado debe estar en dicho proxy; modificar únicamente la configuración de la aplicación ownCloud no alterará el certificado que reciben los clientes.
Después de que el administrador actualice el punto final, pruebe el nombre de host exacto desde la misma red que un equipo afectado. Las comprobaciones del navegador y la línea de comandos ya no deberían mostrar una advertencia de certificado, y el cliente ownCloud debería volver a conectarse tras un reintento o reinicio. Si solo algunos equipos siguen fallando, compare sus actualizaciones del sistema operativo, almacenes de confianza, configuración de proxy y compilaciones del cliente.
Las organizaciones suelen utilizar una CA interna para los servicios privados de ownCloud. En ese caso, obtenga el certificado raíz de la CA de la organización a través de un canal autenticado y verifique su huella digital con el administrador. Instale la CA raíz en cada equipo cliente afectado mediante el proceso de administración de certificados del sistema operativo o la política de dispositivos administrados de la empresa. No agregue un certificado descargado de la página de advertencia como raíz solo porque el cliente de sincronización lo ofrezca; primero verifique que pertenece a la CA prevista.
.crtarchivo en /usr/local/share/ca-certificates/y ejecute sudo update-ca-certificates. Esto actualiza el almacén de confianza del sistema para las aplicaciones que lo utilizan. Ubuntu advierte que las aplicaciones Snap podrían no usar automáticamente los certificados agregados al almacén del host, por lo que un paquete confinado podría necesitar una solución de confianza específica para el paquete.Reinicia el cliente de escritorio de ownCloud después de actualizar la confianza. El paquete del cliente y el sistema operativo pueden afectar al almacén de certificados que lee. Si hay una CA instalada y el navegador confía en el sitio, pero la aplicación de escritorio sigue fallando, revisa el comportamiento de confianza y los registros del paquete del cliente en lugar de importar varias copias del certificado del servidor al azar.
ownCloud Server dispone de un occ security:certificatescomando para los certificados en los que el propio servidor debe confiar, como los utilizados para la federación o el almacenamiento externo. Se trata de un almacén de confianza del lado del servidor. No corrige la decisión de confianza tomada por el cliente de sincronización de escritorio del usuario al conectarse al sitio web de ownCloud. Si se produce un error de verificación de escritorio, corrija el punto final HTTPS o la configuración de confianza del equipo afectado.
Evite deshabilitar la validación de certificados como solución permanente. El cliente de línea de comandos de ownCloud documenta una --trustopción, pero suprimir o aceptar un error de verificación no soluciona un certificado caducado, un nombre de host incorrecto, una cadena de CA faltante o una conexión no confiable. Utilice estos controles de confianza únicamente dentro de un plan de prueba deliberado y verificado, no como reemplazo de una configuración TLS correcta en una cuenta de sincronización de producción.
Si el sitio web se abre pero la sincronización sigue sin conectarse después de que las comprobaciones TLS se hayan superado, revise la configuración de WebDAV y del servidor. La aplicación de escritorio ownCloud utiliza WebDAV para ownCloud Classic; la guía de solución de problemas del proveedor recomienda comprobar que el punto final de WebDAV sea accesible cuando todos los clientes fallan pero el acceso al navegador funciona. Si el error del certificado ha desaparecido pero el inicio de sesión o la sincronización siguen fallando, investigue el error de autenticación, proxy inverso o WebDAV que aparece en el registro.
El certificado presentado para el nombre de host configurado está vigente, contiene dicho nombre de host y se encadena a una CA de confianza para el equipo cliente. El cliente de escritorio se reconecta sin solicitar un certificado y un archivo de prueba se sincroniza en ambas direcciones. Si la cadena de certificados públicos es correcta, pero solo un cliente administrado sigue fallando, revise la hora, el almacén de confianza, el proxy de red, el portal cautivo y la versión compatible del cliente de ese equipo.
Estas comprobaciones solucionan los fallos de verificación de certificados. No pueden corregir problemas de cuenta, WebDAV, cortafuegos o disponibilidad del servidor que no estén relacionados, y los menús exactos varían según el sistema operativo y la versión de la aplicación de escritorio ownCloud. Utilice los registros del cliente y la configuración del punto final TLS del servidor para identificar qué parte sigue sin estar de acuerdo.
Configure Z-Push con Kopano para la sincronización segura de correo electrónico, contactos, calendario y tareas mediante ActiveSync. Compare las opciones de backend e implementación y, a continuación, verifique la configuración móvil.
Solucione los problemas de desconexión de Jitsi Meet con una lista de verificación práctica para navegadores, dispositivos móviles, redes inestables, cortafuegos y servidores autogestionados.
Solucione los problemas de calidad de las llamadas de Nextcloud Talk, configure coturn, abra los puertos correctos, pruebe los candidatos ICE y decida cuándo TURN o HPB es la solución adecuada.
Implementa Element Web en Nginx con un servidor principal personalizado, HTTPS, almacenamiento en caché y encabezados de seguridad, además de comprobaciones sencillas para detectar problemas de configuración comunes.
Solucione el error de presentación "Tipo de archivo no compatible" de BigBlueButton comprobando la extensión del archivo, exportando un PDF real, probando con otro archivo e identificando cuándo debe ponerse en contacto con un administrador.
Solucione los errores de Matrix Synapse "Demasiados archivos abiertos" comprobando el límite del servicio, aplicando una modificación de systemd y verificando el proceso en ejecución.
Configura la búsqueda de texto completo de Nextcloud con Elasticsearch 8, instala las aplicaciones necesarias, configura el índice, ejecuta el primer rastreo y verifica los resultados de la búsqueda.
Crea un bot de Matrix con Python y Simple-Matrix-Bot-Lib, compara las opciones de autenticación y despliegue, prueba los comandos y comprende cuándo usar matrix-nio en su lugar.
Instala Jitsi Meet en Ubuntu 24.04 con DNS, reglas de firewall, repositorios oficiales, SSL de Let's Encrypt, comprobaciones de servicio y solución de problemas de NAT.
Solucione los errores de certificado de sincronización de ownCloud Desktop comprobando la URL del servidor, el nombre y la cadena del certificado, la hora del sistema, la versión del cliente y el almacén de CA de confianza.
