Web UI SSL Protocol Error: missing certificate

Please describe what you are doing to trigger the bug:
Trying to make my linux Web GUI visible over HTTPS connection.
As per Gilbert’s response to previous support request 2191, I set settings.json like this:

{
“listening_address”: “:80”,
“https_address”: “:8080”,
“https_domain”: “my.domain.name”,
“temporary_directory”: “/home/brian/.duplicacy-web/repositories”,
“log_directory”: “/home/brian/.duplicacy-web/logs”,
“dark_mode”: false
}

And opened up the relevant ports in my firewall.

Please describe what you expect to happen (but doesn’t):
I expected to open a web page with the secure lock icon against the URL

Please describe what actually happens (the wrong behaviour):
Firefox reports:

This site can’t provide a secure connection
my.domain.name sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

and the log shows:

2020/02/08 12:38:36 Failed to marshal the configuration: json: error calling MarshalJSON for type main.StorageCredentials: No master password provided
2020/02/08 12:38:36 Temporary directory set to /home/brian/.duplicacy-web/repositories
2020/02/08 12:38:36 Duplicacy Web Edition 1.1.0 (818F2B)
2020/02/08 12:38:36 Duplicacy CLI 2.3.0
2020/02/08 12:38:37 http: TLS handshake error from 192.168.88.1:33064: 403 urn:acme:error:unauthorized: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See End of Life Plan for ACMEv1 - API Announcements - Let's Encrypt Community Support for details.
2020/02/08 12:38:37 http: TLS handshake error from 192.168.88.1:33062: acme/autocert: missing certificate

If I set the https_address & https_domain fields to empty strings, it all works fine, but only as an HTTP connection with a local numeric IP address.
The “MarshalJSON” error in the log also goes away when I blank out the https fields. Whether this relates to the ACME problem I have no idea.

Note that I have a current LetsEncrypt certificate for the domain name that I’m using, issued on 11-Dec-2019 and due to expire on 10-Mar-2020. My normal web server (running on the same machine) is visible via the domain name on both HTTP and HTTPS.

Regards
Brian

I’ve actually fixed this (by updating the go crypto library) in the new release (to be released as 1.2.0 over the weekend). If you want to try it now you can download this version (basically a release candidate for 1.2.0 despite its version number):

https://acrosync.com/duplicacy-web/duplicacy_web_linux_x64_1.1.4

Thanks for the remarkably rapid response!!

I downloaded 1.1.4 and installed it. It runs both from a terminal and as a service. But it hasn’t solved the certificate problem.
The log entries from startup look like this:

2020/02/08 19:25:45 Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: DBUS_SESSION_BUS_ADDRESS not set
2020/02/08 19:25:45 Failed to decrypt the testing data using the password from KeyChain/Keyring: crypto/aes: invalid key size 0
2020/02/08 19:25:45 Temporary directory set to /home/brian/.duplicacy-web/repositories
2020/02/08 19:25:45 Duplicacy Web Edition 1.1.4 (92E6A6)
2020/02/08 19:25:46 Duplicacy CLI 2.3.0
2020/02/08 19:29:04 http: TLS handshake error from 192.168.88.1:49432: acme/autocert: unable to satisfy “https://acme-v02.api.letsencrypt.org/acme/authz-v3/2704825664” for domain “brian.marriott.id.au”: no viable challenge type found

Notes:

  1. The DBUS error only occurs when running as a service and so is not related to the current problem. It’s a Ubuntu/Linux thing that I’ve seen before when trying to use the keyring from a service.
  2. I can run sudo certbot renew --dry-run without error from a terminal. Note that that has to be run with sudo to give it the relevant permissions to mess with Apache.
  3. The IP address given is that of the router, not the actual machine on which Duplicacy is running. Is that a clue?

Cheers
Brian

That is because currently only the http-01 challenge is supported. For that to work you need to make your 80 port open to the internet (so Let’s Encrypt’s server can place a challenge file on that address via http).

Port 80 is open to the internet. But it does have Apache listening on it.
Could that be an issue?
B.

It must be the web GUI that is listening on port 80, not Apache.