Nextcloud is secure, the editor address is not - and the browser quietly kills the editor. Why both servers need real HTTPS, explained without jargon.
Here is the trap in one line: Nextcloud on HTTPS plus OnlyOffice on HTTP equals a blocked editor, and nothing inside either program is broken. This page explains the browser rule behind it, the two-subdomain fix, and why certificates also matter for the traffic between the servers themselves.
OnlyOffice does not open as a separate website - its editor loads inside the Nextcloud page, in a frame, from the Docs server's address. Browsers enforce a strict rule: a secure HTTPS page may not load active content from an insecure HTTP address. So if Nextcloud is on https:// and the connector points at http:// for the editor, the browser silently blocks the editor. Nextcloud itself looks healthy, which is why people hunt for the fault in the wrong server for days.
This is not an OnlyOffice bug and no setting inside Nextcloud can switch the browser rule off. The only fix is to serve the Docs server over HTTPS too.
cloud.example.com and office.example.com, both pointing at your server.https://office.example.com/ address, then save and re-test a document.It is not only the browser. When the Docs server calls back to Nextcloud to deliver your edited file, it checks Nextcloud's certificate. A self-signed certificate on Nextcloud makes the callback fail even when the browser is happy (browsers let a human click through a warning; a server program does not). This is the second classic trap: it works for the admin who accepted the warning once, and fails for everyone else.
Honest advice: on anything beyond a throwaway test, use real certificates on both names from the start. The half hour it takes saves days of strange half-working behaviour.
If the system truly never leaves the office network, you can run both over HTTP with IP addresses - but understand the trade: logins and documents travel unencrypted on your LAN, browsers nag, and the day someone wants access from home you rebuild the addressing anyway. A cheap domain plus Let's Encrypt is the better foundation even for LAN-first offices. If you must self-sign, expect the server-to-server trust problem above and budget time for it.
The video sets the services up on proper addresses - note the HTTPS addresses used when the connector is filled in.
Watch Full VideoNot as a real solution - modern browsers do not offer a supported switch for this on normal sites, and per-user workarounds are not something you can roll out to a team. Serve the Docs server over HTTPS; that is the actual fix.
Each HTTPS name needs a certificate that covers it - either one certificate per subdomain (Let's Encrypt is free) or a single wildcard certificate for the whole domain. Both patterns work fine behind one reverse proxy.
For a closed office LAN it functions, but traffic including logins is unencrypted and you will rebuild addressing the day remote access is wanted. Moving to real domains with certificates early is far cheaper than migrating a working office later.