Windows service + minio with ssl error

Hi - I have Minio with SSL on a Windows 10 machine. I used the excellent guide I found on this forum (thanks).

I am running Duplicati 2.0.3.3. On a windows 10 machine (different one from where minio is running), the connection is fine. However, on a windows 7 machine - with the exact same configuration - I get the error “A WebException with status SecureChannelFailure was thrown.”

I have confirmed that tls 1.2 is enabled on the windows 7 machine, and have restricted the allowed ssl to only tls 1.2, as instructed. Nevertheless… nothing.

This makes me think it is something with Windows 7 & the latest version of duplicati? Anyone have any guesses? Anyone know where I should be looking on the windows 7 computer for duplicati logs? I’m afraid my windows 7 specific knowledge is pretty low (but I do have a couple of these I need to back up).

Thank you for any help you can provide - sorry for replying to an older thread, but it seemed on topic.

Ah, sorry - using kenkend’s suggestion to try connecting to minio through IE instead of Chrome (and without involving duplicati), I indeed found the issue is with Windows SSL configuration.

So, the same issue causing problems for Windows 2012 in the comments above appears to be the problem for me for Windows 7. I will investigate the solution topeju suggests.

I see a similar issue.

I installed Minio on a local linux server with a valid certificate. I originally installed Duplicati the regular non-service way. This worked as expected. I had to use the accept any certificate if I used a LAN IP instead of the FQDN, but otherwise no special options. I exported the backup config, moved to using Duplicati as a service, and imported the backup config. I started getting the same error as originally described in this thread.

The Minio HTTPS page works without issue in chrome and edge. Chrome confirmed TLS 1.2 was in use. In my case moving Duplicati to a service was the only change that made this issue appear. Manually forcing TLS1.2 in the Duplicati options seems to work. Does anyone have any additional insight on this?

I may be way off here, but is it possible your root user SSL certificates are stale (compared to the non-root user)?

I can’t give a complete answer (encryption on Windows is remarkably complicated), but what Chrome says isn’t directly relevant because it does its own encryption. Microsoft browsers such as Edge and Internet Explorer are a little closer, but some of the settings seem to be per-account (test it yourself if you like), and moving Duplicati to run as a service moves it to the SYSTEM account which doesn’t have a nice buttons-to-check TLS screen…

What OS is Duplicati on? The encryption field changes rapidly, and newer Windows are more likely to keep up.

@JonMikelV there are no bad ideas in troubleshooting! I was able to change the service to run as my account instead of system account. It worked as I expected from being my account because it has the backup sets as I had them before moving to the service with the system account. I did however get the same error message:

Amazon.Runtime.AmazonServiceException: A WebException with status SecureChannelFailure was thrown. ---> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.

The fix was the same, force duplicati to use TLS 1.2 with the advanced option “allowed-ssl-versions”. This option is not needed when I was running duplicati from the tray.

This confirms the issue is related to running as a service, not anything to do with the user account associated with the service.

This is windows 10 (up to date).

Open to any other ideas to try or testing I can do to help fix the issue.

Thanks.

Just to clarify, when running Duplicati as a service on your Windows 10 box it can NOT connect to Minio unless you allowforce it to use TLS 1.2 no matter whether running under the system account or your account. Running as tray icon under your account, does work however.

So you’re looking for a way to run it as a service but NOT have to use TLS 1.2? Is there a reason you don’t want want to use TLS 1.2?

What happens if you run a CLI “as admin” and try a command line backup run?

Yes, with one correction,

“can NOT connect to Minio unless you force it to use TLS 1.2 explicitly.”

The default duplicati behavior is to allow anything and presumably negotiate what it thinks is best. TLS 1.2 should be the chosen option, and it is when running from tray. I believe this also happens to be the only thing that Minio supports, at least based on the earlier information in the thread.

This option changes the default SSL versions allowed. This is an advanced option and should only be used if you want to enhance security or work around an issue with a particular SSL protocol. Default value: "SystemDefault,Ssl3,Tls"

I’m looking to run it as a service and use TLS 1.2 without having to explicitly force the option. Forcing the option is a workaround, particularly when it works without it from the tray running mode. It’s also potentially a maintenance and security issue when Minio updates to support only TLS 1.3 an then it doesn’t work or allows a connection on TLS 1.2 even though it’s not secure and 1.3 is supported (hypothetical).

I was hoping the new information that it has to do with running as a service provided some useful information to try and get the issue resolved.

Thanks for explaining the reasoning, it makes sense - especially the future versions consideration.

So I guess the question is what is the service hitting before TLS 1.2 that Minio says it likes but ends up not working with.

If we identify that protocol and can confirm whether or not it works with something other than Minio then we can know if the issue is on the Duplicati or Minio implementation side.

My guess is the SystemDefault protocol may be different for different users.

Transport Layer Security (TLS) best practices with the .NET Framework starts by agreeing with this fine idea:

When your app lets the OS choose the TLS version:

    It automatically takes advantage of new protocols added in the future, such as TLS 1.3.
    The OS blocks protocols that are discovered not to be secure.

and then you can keep reading to see how messy it gets. See my previous post on “remarkably complicated”. Life seems to be getting better in new .NET Framework versions. Duplicati targets 4.5, and I’m not sure what would break if it went to a higher target. Duplicati might give old behavior to Windows users who keep the old .NET Framework deliberately (e.g. by limiting updates), but I’m not sure where fully updated Mono users land. Obviously a graceful degradation is far preferable to any complete failure (whether Windows or Linux or etc.).

One can also see here that Duplicati is not in direct control of where the negotiation happens. It’s far far lower but there are some controls Duplicati can use. The most disturbing failure to me is when I told Duplicati to use SystemDefault and got total failure to connect. Observing with Wireshark showed not even a TLS negotiation, simply a close (presumably from Windows). I wonder if this is what above-quoted “blocks protocols” looks like? This was as a Windows service on 2.0.3.3 beta on latest fully updated Windows 10. I haven’t tried other ways yet. You got ahead of me, plus I might be taking a break. Feel free to test yourself, preferably with a test job…

  --allowed-ssl-versions (Flags): Sets allowed SSL versions
    This option changes the default SSL versions allowed. This is an advanced
    option and should only be used if you want to enhance security or work
    around an issue with a particular SSL protocol.
    * values: Ssl3, Tls, Tls11, Tls12, SystemDefault
    * default value: SystemDefault,Ssl3,Tls

While it might be nice if Duplicati can do something on its own, security is best with general Windows securing which (unfortunately) involves registry changes. One possible source is available from these folks who aim to help their customers meet the requirements for a properly secured Point-of-Sale (POS) system. PCI Security and TLS 1.2 – Is Your Restaurant Ready? offers TheLevelUp/pos-tls-patcher which I haven’t personally tried. One thing I like about this compared to things like .reg files I see around is that it comes with an uninstaller…

If anyone wants to give securing their Windows system a try through registry change, please post the result. For any who don’t think the patcher has earned sufficient trust yet, see above article for a Microsoft .reg file.

To followup on how I got this working with Windows 7 Duplicati client and Minio on Linux using a namecheap.com certificate. I already had set it to use TLS1.2 only, and only ran into issues after upgrading Minio to the current version. Per the pull request link on topeju’s post from March 6th, Minio removed older ciphers.

  1. Ran the test_ciphers.sh script shown at security - How do I list the SSL/TLS cipher suites a particular website offers? - Super User to figure out what ciphers I current supported. Found out that only two were listed.

  2. Looked at list of ciphers that Windows 7 supports, found that I didn’t have a match. TLS Cipher Suites in Windows 7 | Microsoft Docs

With a little more research, I realized that I needed an ssl certificate that provides ECDSA instead of RSA.
I used IE on my Duplicati client to verify that I couldn’t connect to Minio.

  1. Regenerated my certificate. Basically followed topeju’s post of March 7th for the openssl command to get the CSR, then used that to regenerate my certificate with namecheap.com

  2. Replaced my certificates in minio’s certs directory, cycled minio, ran the script from step 1, and also used IE on Duplicati client to verify that I could now connect. Since both IE and Duplicati use the Windows SSL support, IE connecting to the page should mean that Duplicati will also work.

  3. Ran restore from Duplicati and verified.

Thanks to everyone who posted on this thread, this was really helpful to me. I didn’t really understand what ECDSA was, didn’t understand that my certificate was created with support for it, didn’t understand that there are also ciphers associated and that the issue was finding common ground between the ssl certificate, what minio supports, and what the windows OS supports

for what it’s worth I found that minio has pretty limited https support in terms of configuration, number of ciphers, negotiations and such. using a letsencrypt certificate with minio and windows 10 duplicati client required selecting tls1.2 explicitly in the options. i wasn’t able to get windows 7 to work since it required an older tls version minio wouldn’t support.i landed on using nginx reverse proxy with minio to get better https support. now i don’t need the additional option in windows 10 and windows 7 is supported.

https://docs.minio.io/docs/setup-nginx-proxy-with-minio

note: $host vs $http_host was messing me up. i was getting errors with duplicati even though it was working in the browser.