SecureChannelFailure (The authentication or decryption has failed.) - nzbhydra

Help & Support
#1

I got the same issue on Debian with both Sonarr and Radarr.

I was using Mono 4.6 and I had this issue.

I upgraded to Mono 5 and I still got the issue.

The solution for the Environment Variable didn’t work at all on my case in Debian.

Here my original post: https://github.com/Sonarr/Sonarr/issues/2078

Here is the main thread about this issue: https://github.com/Sonarr/Sonarr/issues/1928

Here is the fix for the environment variable that work on some systems: https://www.reddit.com/r/sonarr/comments/6b3ifc/sonarrs_crashing_because_of_something_to_do_with/

Sorry after the Mono 5 upgrade I got this error:

Error: ConnectFailure (TLS Support not available.)

I had to remove the environment variable to correct the TLS Support not available.

If I remove it I got the SecureChannelFailure one…

System.Net.WebException: Error: SecureChannelFailure (The authentication or decryption has failed.): 'http://192.168.3.47:5075/getnzb?apikey=400E10653B2F499C6D8BB4F36A549148&searchresultid=79d93adc636b061c374f2d1d866a9f409e5e10f1’
at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x00168] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Common\Http\Dispatchers\ManagedHttpDispatcher.cs:83
at NzbDrone.Common.Http.Dispatchers.FallbackHttpDispatcher.GetResponse (NzbDrone.Common.Http.HttpRequest request, System.Net.CookieContainer cookies) [0x000cc] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Common\Http\Dispatchers\FallbackHttpDispatcher.cs:60
at NzbDrone.Common.Http.HttpClient.Execute (NzbDrone.Common.Http.HttpRequest request) [0x0007e] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Common\Http\HttpClient.cs:70
at NzbDrone.Common.Http.HttpClient.Get (NzbDrone.Common.Http.HttpRequest request) [0x00007] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Common\Http\HttpClient.cs:193
at NzbDrone.Core.Download.UsenetClientBase`1[TSettings].Download (NzbDrone.Core.Parser.Model.RemoteEpisode remoteEpisode) [0x00028] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Core\Download\UsenetClientBase.cs:43

So I guess I’m stuck! :slight_smile:

Newznab Indexer Error - Error: SecureChannelFailure (Object reference not set to an instance of an object) ---> System.NullReferenceException: Object reference not set to an instance of an object
#2

Merged your posts and moved to a new thread as it was unrelated to the thread you posted in as your issue is not with teh new TLS provider, but likely a lack of libcurl.

You’ll need to enable ((trace logging)), restart Sonarr and look for: Curl not available, using default WebClient.

If that is present, it confirms that Sonarr cannot fallback to libcurl and you’ll need to fix that, which would be similar to what is outlined here:

#3

I enabled the trace logging and I didn’t get any Curl error.

I did verify the libcurl like your asked:

#ldconfig -p | grep libcurl

libcurl.so.4 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcurl.so.4
libcurl-gnutls.so.4 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4


#dpkg -S libcurl

libcurl3:amd64: /usr/share/doc/libcurl3/NEWS.Debian.gz
libcurl3-gnutls:amd64: /usr/share/doc/libcurl3-gnutls/changelog.Debian.gz
libcurl3:amd64: /usr/share/doc/libcurl3/changelog.gz
libcurl3:amd64: /usr/share/doc/libcurl3
libcurl3:amd64: /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0
libcurl3-gnutls:amd64: /usr/share/doc/libcurl3-gnutls/copyright
libcurl3-gnutls:amd64: /usr/share/doc/libcurl3-gnutls/NEWS.Debian.gz
libcurl3:amd64: /usr/share/lintian/overrides/libcurl3
libcurl3:amd64: /usr/share/doc/libcurl3/changelog.Debian.gz
libcurl3:amd64: /usr/share/doc/libcurl3/copyright
libcurl3:amd64: /usr/lib/x86_64-linux-gnu/libcurl.so.4
libcurl3:amd64: /usr/lib/x86_64-linux-gnu/libcurl.so.3
libcurl3-gnutls:amd64: /usr/share/doc/libcurl3-gnutls/changelog.gz
libcurl3-gnutls:amd64: /usr/share/lintian/overrides/libcurl3-gnutls
libcurl3-gnutls:amd64: /usr/share/doc/libcurl3-gnutls
libcurl3-gnutls:amd64: /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
libcurl3-gnutls:amd64: /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.3
libcurl3-gnutls:amd64: /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.4.0

I can’t upload .txt for the trace and debug file in the forum (extension not allowed). And the logs is too big to copy paste here.

#4

Also Sonarr is on a separate vm and Nzbhydra too is on another one.

#5

The only thing that I saw that is different from Taloth post is that I have libcurl 4.4.0 instead of 4.3.0

#6

Nobody noticed the ssl error on a http URL? My guess, nzbhydra redirects http url to https. But why would you use https on nzbhydra?

#7

Well I don’t use SSL on nzbhydra :slight_smile: it’s already off in the settings.

The use ssl is off.

But latest update I have the Verify SSL on for indexers. I tried it off and I got the same problems.

#8

Browse to the url yourself, it’ll likely redirect.

#9

Ok I did and I can download fine the .nzb in my browser with no redirection. I didn’t see the https in the beginning.

Also the problems is that Sonarr is working for some downloads and others like 3/4 of the time it doesn’t work and I got this error and Sonarr disable my indexer.

#10

I think I found something. I tried another one that was failling and for some reasons it’s asking my username and password for nzbhydra.

I activated only the username and password for the admin side of it.

Strange.

I’ll try to disable it.

#11

You might not see it if it directly downloads the file. So you may have to use the browser console or other tools to figure it out.

As for the other failing one, could just be timing that the search result is only valid for x amount of time.

Point is that the Sonarr log indicates that it ends up in an ssl connection. but it doesn’t start as one, Sonarr only uses the curl fallback if the original url is https, which it isn’t.

#12

Ok yeah you are right. It’s downloading from my indexer that have the SSL on. Yes it’s a redirection to my indexer.

It’s a bug in Sonarr or I will need to have nzbhydra to have SSL too if Sonarr doesn’t start with SSL ?

#13

Why does it redirect to the indexer? I would’ve expected nzbhydra to download the nzb and proxy it.

It’s a known limitation in Sonarr, we let the http subsystem deal with redirections so it’s unaware of the curl fallback. Normally this isn’t a problem cause with individual indexers you can just configure it for https and be done with it. nzbHydra is a bit more tricky, hence my surprise that hydra doesn’t actually proxy.

1 Like
#14

Ok I understand.

Well by default nzbhydra is redirecting :slight_smile:

From nzbhydra: How access to NZBs is provided when NZBs are downloaded (by the user or external tools). Redirecting is recommended.

In the configuration I have 2 nzb access type configuration.

  1. Redirect to the indexer (the default one)
  2. Proxy NZB from the indexer

I used the Proxy NZB option and it’s works! I also added the environment variable in my systemd because I’m now with Mono 5.

Thanks for the proxy hint and the explanation of the http in Sonarr! I will never have found it.

I suggest the following:

  1. Update the Wiki for NZBhydra
  2. Trow an error in Sonarr to check the wiki if someone is using the NZBhydra port and got this error in the logs of Sonarr.
  3. Maybe the nzbhydra team need to default to the proxy. I don’t know why it’s recommending the redirection.

Note: I think I will report the solution to the Radarr team because I had the same problem with Radarr but was happening more time with Sonarr for some reasons (maybe I had more stuff to download with Sonarr). I will also check with the nzbhydra team that they default to the proxy one.

Or you prefer to contact them ? What do you think is best ?

#15

I’ve created an issue to track what we should do in Sonarr for it: https://github.com/Sonarr/Sonarr/issues/2082
You can link that, so all parties know the progress on it.

#16

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