Webserver stopps with HTTPS certificate

Hello Community,

i am stuck with enabling HTTPS. Every time i start Duplicati.Server or Duplicati.WebGUI with


i can not connect to locahost:8200 (http or https). If i use the WebGUI the process stops after 1 second. If i use the Server the process stays and is bound to :8200 but i can not access the site.

I tried --log-file and log --log-level=Verbose but the output is just

[Information-Duplicati.Server.WebServer.Server-ServerListening]: Server started and listing, Port 8200

To get everything working again i have to set --webservice-sslcertificatefile= empty.

I tried CA and self signed (OpenSSL), PKCS12 with or without certificate chain and with or without password but always the same result.

I am running duplicati- on Windows Server 2019 Standard.

Is there a way to debug this in detail?


I don’t have any direct experience with HTTPSin’ an install but I did find this thread suggesting you also have to specify the --webservice-sslcertificatepassword option (even if there is no password) in addition to the --webservice-sslcertificatefile option.

Hope that helps.

Hallo JimboJones,

thanks for the reply. I already tried --webservice-sslcertificatepassword option with or without password but still the same.

I guess that someting with the certificate is not right but i could not find any logs.

No idea what is wrong specifically, but you should know that the last change to the duplicati http server was 7 years ago, that a issue about HTTPS use was filed 4 years ago and gathered no answer, and that finally Duplicati has to migrate to .Net 5 to stay relevant, and as part of this migration full replacement of this outdated http server by the one integrated in more recent .NET versions is planned.
In short, if you want HTTPS right now, the best way IMO is to add a proxy to your system as you can’t expect any support in what you are trying to do. If your server don’t have one installed already, I think that Apache and Nginx have ready to use packages for Windows.

I think last time I tried looking, I didn’t see that Duplicati’s use of the server had HTTPS level logging.

Be careful what you wish for. :wink: There are many generic tools that support such network debugging.

I wonder how that looks in your browser web developer tools (usually available by menu or F12 key)?
Some of the later debug ideas here are better suited for something that fails fast, not after some time.

What happens there? Is there an error message from something? If so, what does your message say?

To avoid web browser issues, you could try curl which might be on Windows, to see what it can show.

Windows also often includes openssl which does all kinds of things, including an s_client command.

An extreme microscopic view, if you think you have a certificate issue, might be Wireshark plus experts.
Starting at a higher level view such as error messages or how far the web browser got would be easier.

I hope it has better logging. I think the current one has some logging possible, but Duplicati isn’t using it.
I don’t see much point in tweaking the old server, but I’m not sure of future path, given limited dev time.

Or we could try to see if we can find something wrong with the setup, or maybe some expert will help.
Code-level support is probably not available, because the person who might do it is not available now.

Hello ts678,

it is not possible to load the web page. The webserver is not running (GUI) or is not answering (Service). Neither with curl or a browser. No error message or log entry.

I thought at least curl would eventually give up and time out with an error. You see it just sit there?

I’m not clear on the difference. You said GUI process stopped after 1 second. Browser logs may help.
The service not answering could happen at TCP/IP/ICMP levels (test with ping or telnet) or further up.
What URL are you using with curl, and can openssl s_client -connect localhost:8200 work?


I said Duplicati logs might not help much. Are you saying browser developer network log is empty too?


You can sometimes get TCP-level clues by netstat -an | findstr 8200. ESTABLISHED is good…