DocSpace Community Problem - when switching to https.
Installation on Windows 2019 - everything works great with http, I can log in, configure everything, create and manage spaces.
When I activate https using the Powershell script under sbin, I only get a welcome site and can maybe access the DocSpace admin area - but no longer my 2 test spaces I set up.
Installed as a local admin - the server is in Active Directory.
Using an AD certificate. Installed newest Version.
What can I do - where might possible errors be - or can the Community version only do http??
Thanks for the screenshots — they’re very helpful.
The page you’re seeing after enabling HTTPS is the Document Server welcome page, not DocSpace. Your spaces and data are still there — the request just isn’t reaching the DocSpace frontend.
We tested the HTTPS switch on our lab (DocSpace Community on Windows Server, self-signed certificate, docspace-ssl-setup.ps1 -f) and it worked without issues — rooms were accessible over HTTPS as expected. So the script itself is not the problem.
The most likely cause is a hostname mismatch: your DocSpace tenant was registered under the hostname you used over HTTP, and the domain on your AD certificate (the one you passed to the script) is different. DocSpace resolves the portal by the exact hostname in the browser, so if those don’t match, it can’t find your existing tenant.
To help narrow this down, could you please share:
The exact URL you used to access DocSpace over HTTP (e.g. http://servername, http://server.domain.local, or an IP address).
The exact command you ran — specifically the domain you passed to docspace-ssl-setup.ps1 -f.
Directly after the installation – due to the lack of input options during the installation – I accessed DocSpace via http://servername. But I could also access http://servername.domain.de – so both worked. The newly created spaces were also reachable at space01.domain.de.
Thanks for the update — I think the main issue is the certificate format. The script expects two separate PEM files (certificate + key), but you passed a PFX file. You can convert it with OpenSSL:
Regarding the domain — in your first screenshot there’s actually a “Domain-Einstellungen” section with an “Bearbeiten” button in the admin panel. You could try updating the domain to servername.domain.de there.
Also keep in mind: since your spaces use subdomains like space01.domain.de, your certificate needs to cover those too — either a wildcard (*.domain.de) or SANs for each.
Could you try converting the certificate and rerunning the script?
thanks a lot for your reply. I tried it this morning with the converted certificates – still didn’t work. The OpenResty service didn’t start. First, I looked at the OpenResty logs. The certificate wasn’t recognized there. Then I checked the nginx.conf – that’s where I found the error. In the HTTPS instructions for the DocServer, there are double \\ in the path to the certificates, which apparently the PowerShell script doesn’t handle.
The only problem (so far) that still exists – I can’t access the Space Management – I get a 403 there – sorry, access denied.
Could you share the exact certificate paths you used in the command and the lines from nginx.conf that had the double backslashes? We want to understand whether the script generated those paths or if something else caused it.
Thanks for the details — this looks like a bug in the script. The certificate paths appear to be written with backslashes into the Nginx config, which causes characters like \t to be interpreted as escape sequences. We’ve reported this internally for investigation.
As a workaround, you can manually replace the backslashes with forward slashes in C:\OpenResty\conf\onlyoffice-proxy.conf (lines 60–61).
Regarding the 403 on Space Management — which URL are you using when you get that error?
That might be a separate issue from the certificate one. You’re accessing Space Management from space01.domain.de, which is a space subdomain. Could you try accessing it from your main portal domain instead — e.g. https://servername.domain.de/management?
Thanks for the log — the 307 redirect to /error/403 means it’s the DocSpace application itself denying access, not the proxy configuration. To understand why, we’d need to check the DocSpace backend logs.
Could you zip the folder C:\Program Files (x86)\Ascensio System SIA\DocSpace\Logs\ and upload it to any file sharing service (Google Drive, WeTransfer, etc.)?
You can share the link here or via DM if you prefer.
Had a look at the logs — thanks for sharing. The Management service has been unable to reach the backend API since the HTTPS switch (every internal call fails with fetch failed), which is what’s causing the 403.
I think the Node.js services don’t trust your AD certificate. The script only sets up certificate trust automatically for self-signed certs. Could you try this in PowerShell (as admin):
Glad it’s working now!
And good catch on including the root certificate in the PEM file — that was the missing piece.
Regarding the backslash issue you found earlier in the script, it’s been confirmed and registered as a bug on our end. Thanks for reporting it.
