Unable to add rTorrent client via SSL XMLRPC

Sonarr version (exact version): 3.0.6.1342
Mono version (if Sonarr is not running on Windows): 6.12.0.122
OS: Debian 10 Host (running in docker, tried both linuxserver/sonarr and hotio/sonarr:release images)
Debug logs: https://github.com/Sonarr/Sonarr/files/7461178/sonarr.trace.txt
Description of issue: I’m unable to connect to rTorrent client using SSL from Sonarr.
I am using same settings in Radarr and Prowlarr and they can connect to my rTorrent instance without any issues.

I’m not sure if this is error with docker image, Sonarr itself or Mono version that I’m running, but it’s really frustrating. I see that hotio/sonarr image runs cert-sync /etc/ssl/certs/ca-certificates.crt on boot, but that also doesn’t help. My rTorrent is behing nginx proxy with Let’s Encrypt SSL certificate. Are there any special steps I need to do to get Let’s Encrypt certificate working?

I’ve also tried Settings > General and change Certificate Validation to Disabled (just for debugging, don’t want to run it like that), but the error still remains.
I’d appreciate any suggestions or debugging steps as right now I’m just stuck, no idea what to try next.

edit - sorry missed that youd already done this.

from what i can make out from the error message the site you are connecting to is using TLS 1.0 - which is classed as insecure. (TLSV1_ALERT_PROTOCOL_VERSION)

you should be able to verify this by going to the url in a web browser and checking, most browsers wont let you in as its insecure.

if you can somehow reconfigure mono to use TLS 1.0 in your docker image it might work,. but it wouldnt really be a good idea.

realistically the site has to shift to TLS 1.2 or preferably 1.3 as you wont be the only person having an issue with them. i’d expect its actually their hosting service that has screwed up somehow if TLS 1.0 is still active.

That’s what’s confusing me. I’m not sure if the message really says that the server only supports TLSv1.0 and that’s why it refuses to connect.

After a few more moments of banging my head against the wall, I’ve got it. I didn’t expect Mono not to support TLSv1.3, so I’ve never considered this. My server is configured to only allow TLSv1.3, and for some reason Mono doesn’t support that, so it’s throwing the above message (it’s kinda misleading, right?)…

Anyways, enabling TLSv1.2 and TLSv1.3 fixes the issue - in that case I can connect to my rTorrent instance! Yay :smiley:

However, I’d like to keep only TLSv1.3 enabled if possible. Do you have any idea how to enable that, or if it is currently possible with Mono?

true, but it also makes sense once you realise that the message is probably the equivalent to “unsupported tls version” - still, a better error message there would have been nice and cut down on the confusion.

i think the only way youre going to be able to do that is to find an os that does support 1.3 and put sonar on that instead. note that may mean finding mono or .net versions that support it as well.

Blame the mono developers for having a crappy error message :man_shrugging:

Sonarr is mono on *nix / .net framework on windows. There is no timeline on converting to .net

Yeah, I know Mono is producing the error message, not Sonarr. I’m just glad it’s finally working :slight_smile: Does anyone have verified combo of OS/Mono version on which TLSv1.3 works 100%? I’d rather just use something that is supposed to work than spend a day messing around trying out different distros and/or Mono versions

Likely just try updating your mono version and use the official repo which would follow sonarr’s installation steps

I’ve tried this separate of Sonarr and I just can’t get it working. This is the app I’m using for testing:

using System;
using System.Net.Http;
using System.Threading.Tasks;

namespace MonoBugTLS {
	internal static class Program {
		private static void Main() => Reproduce().Wait();

		private static async Task Reproduce() {
			using (HttpClient httpClient = new HttpClient()) {
				try {
					await httpClient.GetAsync("https://tls13.1d.pw/").ConfigureAwait(false);
					Console.WriteLine("OK!");
				} catch (Exception e) {
					Console.WriteLine("Exception: " + e.Message + " | Stacktrace: " + Environment.NewLine + e.StackTrace);

					while (e.InnerException != null) {
						e = e.InnerException;
						Console.WriteLine("Inner exception: " + e.Message + " | Stacktrace: " + Environment.NewLine + e.StackTrace);
					}

					Environment.Exit(1);
				}
			}
		}
	}
}

Compile and run with:

mcs Program.cs /r:System.Net.Http.dll && mono Program.exe

Pretty simple, should work, right? Nop, doesn’t work on my system (manjaro, has mono 6.12.0), nor in official docker Mono images (tried 6.12, 6.10, 6.8 and 5.20 - no luck). Always get the same exception:

Inner exception: Ssl error:1000042e:SSL routines:OPENSSL_internal:TLSV1_ALERT_PROTOCOL_VERSION

I’m starting to think that Mono just doesn’t support TLSv1.3, is that possible?

That error message TLSV1_ALERT_PROTOCOL_VERSION seems to indicate that the site is running TLSv1.0 from some googling - so TLSv1.3 has no bearing in that.

Unless I’m missing something, that is not true (as I’ve said, the error message is confusing/misleading). The test site used in the small app above throws the same error, and that site ( https://tls13.1d.pw) has only TLSv1.3 enabled. My host is configured the same.

You can see it here:

https://www.cdn77.com/tls-test/result?domain=https%3A%2F%2Ftls13.1d.pw

So either I’m missing some kind of obvious configuration option or Mono has issues/bug with TLSv1.3. IMO that simple app and the site should just work without any additional config (i.e. using official docker Mono image), but it doesn’t.

Mono supports v1.3 and I’m able to curl that URL from within the Sonarr container.

If you use the SSL Labs test on your domain, does it flag anything useful?

Could be a config issue similar to this.

Using cURL doesn’t test if Mono support TLSv1.3, just the underlying system/libraries + the cURL app. If you have the time, could you please try the small app I’ve posted above and see if that works for you from within the container or fails with an exception?

I have tested my host using

curl -I -v --tlsv1.3 --tls-max 1.3 https://my.host.com

and that works fine:

*   Trying **ip-redacted**:443...
* Connected to **host-redacted** (**ip-redacted**) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=**host-redacted**
*  start date: Sep 22 14:23:07 2021 GMT
*  expire date: Dec 21 14:23:06 2021 GMT
*  subjectAltName: host "**host-redacted**" matched cert's "**host-redacted**"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55f21106d9a0)
> HEAD /login HTTP/2
> Host: **host-redacted**
> user-agent: curl/7.79.1
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 200
HTTP/2 200

I’ve also scanned using SSL Labs test and currently it reports bith TLSv1.2 and TLSv1.3 as turned on. When I disable v1.2, SSL Labs test reports just TLSv1.3 turned on and in that case Sonarr can’t connect anymore to my host.

I thought curl would have used mono in the container, apparently not.

Perhaps an extension of this current bug/limitation - https://github.com/Sonarr/Sonarr/issues/4392 (but Mono and linux)

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.