[anidex] The SSL connection could not be established, see inner exception.: certificate validation failed: [Subject] CN=anidex.info[Issuer] CN=R3, O=Let's Encrypt, C=US[Serial Number] 04EABAB1D7D8FFB1529EB8A314479AFF7BF1[Not Before] 9/23/2021 2:49:33 AM[Not After] 12/22/2021 2:49:32 AM[Thumbprint] AB9BC7A73706F375E26201BC099191D5A314E40A (Config)

[LoganXShadow]

Have you checked our Troubleshooting page for your issue?

• I have checked the Troubleshooting page

Is there already an issue for your problem?

• I have checked older issues, open and closed

Have you read our Contributing Guidelines?

• I have read the Contributing Guidelines

Environment

- OS:Linux Mint 19
- .Net Runtime: [.Net-Core/.Net-Framework/Mono].Net-Core
- .Net Version:
- Jackett Version:Latest
- Last Working Jackett Version:none
- Are you using a proxy or VPN? [yes/no]no

Description

After upgrading jackett to v0.18.805 and newer I lost contact with several indexers (Anime Tosho and Anidex).
I tried reverting to an older version but the problem remains even when trying to re=add indexer.

Logged Error Messages

System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.Exception: certificate validation failed: [Subject]
CN=anidex.info

[Issuer]
CN=R3, O=Let's Encrypt, C=US

[Serial Number]
04EABAB1D7D8FFB1529EB8A314479AFF7BF1

[Not Before]
9/23/2021 2:49:33 AM

[Not After]
12/22/2021 2:49:32 AM

[Thumbprint]
AB9BC7A73706F375E26201BC099191D5A314E40A

at Jackett.Common.Utils.Clients.HttpWebClient2.ValidateCertificate(HttpRequestMessage request, X509Certificate2 certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) in /home/vsts/work/1/s/src/Jackett.Common/Utils/Clients/HttpWebClient2.cs:line 50
at System.Net.Http.ConnectHelper.<>c__DisplayClass3_0.b__0(Object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
at System.Net.Security.SecureChannel.VerifyRemoteCertificate(RemoteCertificateValidationCallback remoteCertValidationCallback, ProtocolToken& alertToken, SslPolicyErrors& sslPolicyErrors, X509ChainStatusFlags& chainStatus)
at System.Net.Security.SslStream.CompleteHandshake(ProtocolToken& alertToken, SslPolicyErrors& sslPolicyErrors, X509ChainStatusFlags& chainStatus)
at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm)
at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Boolean async, Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Boolean async, Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.DecompressionHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
at System.Net.Http.DiagnosticsHandler.SendAsyncCore(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
at FlareSolverrSharp.ClearanceHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpClient.SendAsyncCore(HttpRequestMessage request, HttpCompletionOption completionOption, Boolean async, Boolean emitTelemetryStartStop, CancellationToken cancellationToken)
at Jackett.Common.Utils.Clients.HttpWebClient2.Run(WebRequest webRequest) in /home/vsts/work/1/s/src/Jackett.Common/Utils/Clients/HttpWebClient2.cs:line 170
at Jackett.Common.Utils.Clients.WebClient.GetResultAsync(WebRequest request) in /home/vsts/work/1/s/src/Jackett.Common/Utils/Clients/WebClient.cs:line 185
at Jackett.Common.Indexers.BaseWebIndexer.RequestWithCookiesAsync(String url, String cookieOverride, RequestType method, String referer, IEnumerable1 data, Dictionary2 headers, String rawbody, Nullable1 emulateBrowser) in /home/vsts/work/1/s/src/Jackett.Common/Indexers/BaseIndexer.cs:line 591 at Jackett.Common.Indexers.BaseWebIndexer.<>c__DisplayClass11_0.<<RequestWithCookiesAndRetryAsync>b__0>d.MoveNext() in /home/vsts/work/1/s/src/Jackett.Common/Indexers/BaseIndexer.cs:line 568 --- End of stack trace from previous location --- at Polly.Retry.AsyncRetryEngine.ImplementationAsync[TResult](Func3 action, Context context, CancellationToken cancellationToken, ExceptionPredicates shouldRetryExceptionPredicates, ResultPredicates1 shouldRetryResultPredicates, Func5 onRetryAsync, Int32 permittedRetryCount, IEnumerable1 sleepDurationsEnumerable, Func4 sleepDurationProvider, Boolean continueOnCapturedContext)
at Polly.AsyncPolicy1.ExecuteAsync(Func3 action, Context context, CancellationToken cancellationToken, Boolean continueOnCapturedContext)
at Jackett.Common.Indexers.BaseWebIndexer.RequestWithCookiesAndRetryAsync(String url, String cookieOverride, RequestType method, String referer, IEnumerable1 data, Dictionary2 headers, String rawbody, Nullable1 emulateBrowser) in /home/vsts/work/1/s/src/Jackett.Common/Indexers/BaseIndexer.cs:line 567 at Jackett.Common.Indexers.Anidex.PerformQuery(TorznabQuery query) in /home/vsts/work/1/s/src/Jackett.Common/Indexers/Anidex.cs:line 183 at Jackett.Common.Indexers.Anidex.ApplyConfiguration(JToken configJson) in /home/vsts/work/1/s/src/Jackett.Common/Indexers/Anidex.cs:line 142 at Jackett.Server.Controllers.IndexerApiController.UpdateConfig(ConfigItem[] config) in /home/vsts/work/1/s/src/Jackett.Server/Controllers/IndexerApiController.cs:line 97 at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.TaskOfIActionResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Awaited|12_0(ControllerActionInvoker invoker, ValueTask1 actionResultValueTask)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
at Microsoft.AspNetCore.Routing.EndpointMiddleware.g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at Jackett.Server.Middleware.CustomExceptionHandler.Invoke(HttpContext httpContext) in /home/vsts/work/1/s/src/Jackett.Server/Middleware/CustomExceptionHandler.cs:line 26

Screenshots

No response

[garfield69]

It looks to me like this is a CA validation failure.
Both sites you mentioned use CA issued by R3 that are valid for just 3 months at a time, and both sites have updated their CA in Aug or Sep.
If going back versions of Jackett is not resolving this then its not the Jackett code that is the problem, but more likely some Mint library that needs updating, either OpenSSL, or the .Net Core, or something else?
But I'm not a linux man, so I will defer to @ilike2burnthing who is more likely to know what needs to be checked further.

[ilike2burnthing]

Only other thing that comes to mind is that your system clock needs resynced.

[skuizy]

Same here since the update of ca-certificates to 20210119~20.04.2.

Every indexer that uses Let's Encrypt fails.

I don't know if this has something to do with DST Root CA X3 Expiration (https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/)

The command openssl s_client -connect url:443 succeeds for these indexers but last CA validation is really slow.

[ilike2burnthing]

Check what version of openssl you're running. If it's not 3.0.0 then try updating to that.

[Mannekino]

I'm having the same issue with Jackett inside a TrueNAS jail.

[garfield69]

Jackett uses the OpenSSL library on linux flavoured platforms to process certificates so check your library version and upgrade if you can.

[garfield69]

unless that is, you are using the mono version of jackett in which case you may need to update your mono library

[Haxiboy]

I have the same issue on Truenas Jail, R3 certificate on website (ncore.pro)
Edit: And on other websites that use R3 cert too. OpenSSL Client connects without issue.
I'm on Mono 6.8.0.105
According to the packages, everything is up to date.

[ilike2burnthing]

Try running pkg install ca_root_nss

If that doesn't help, have a look at: https://www.truenas.com/community/threads/lidarr.72538/post-502541
and
https://www.truenas.com/community/threads/lidarr.72538/post-502606

[Haxiboy]

Try running pkg install ca_root_nss

If that doesn't help, have a look at: https://www.truenas.com/community/threads/lidarr.72538/post-502541 and https://www.truenas.com/community/threads/lidarr.72538/post-502606

The package is the newest version, tried various methods, still using the old chain for authentication.

[SleepingPanda]

I'm also experiencing these issues on TrueNAS and the provided solutions don't work.

[De-Gun]

I'm also experiencing these issues on TrueNAS and the provided solutions don't work.

+1

[ilike2burnthing]

Seemingly the last time this happened the conclusion was that this is a Mono issue rather than a Jackett one, and the general advice was to switch to the .NetCore version of Jackett if possible, e.g. a Docker install - #7237 (comment)

Mono have known about the issue for over a year with no progress - mono/mono#19886
leading to patches like Sonarr's - https://github.com/Sonarr/Sonarr/blob/develop/src/Sonarr.RuntimePatches/Mono/BoringTLSVerifyFlagsPatch.cs
and now Electron - electron/electron#31213

A new issue has been opened, so we'll see if that does anything - mono/mono#21233

In that new issue there is a suggested workaround:

sed -i 's#mozilla/DST_Root_CA_X3.crt#!mozilla/DST_Root_CA_X3.crt#' /etc/ca-certificates.conf && update-ca-certificates

[SleepingPanda]

Thanks for your help, I'll try switching to the .NetCore version.

[Nerdy314159265]

.NetCore version of Jackett if possible

Unless this has changed recently, any users on TrueNAS are unable to switch over. M$ have been dragging their feet on releases a FreeBSD version of .NetCore, which leaves Mono as the only thing usable on TrueNAS.

TrueNAS Scale will fix this by switching to Linux as well integrating Docker but anyone not running that version of TrueNAS is SOL.

[ilike2burnthing]

Add Docker Capabilities to TrueNAS Core
https://www.youtube.com/watch?v=XBVjuwgz0Cg
https://getmethegeek.com/blog/2021-01-07-add-docker-capabilities-to-truenas-core/

[Nerdy314159265]

I may have been exaggerating when I said SOL since there are definitely backup options.
However, I don't think that VMs can really be considered properly supporting something.

[ilike2burnthing]

Oh sorry, that wasn't supposed to be a 'you are wrong' comment, just a workaround (which it definitely is) for those who need it.

[Nerdy314159265]

It's perfectly fine! I'm on the defensive lately because I've had some annoying issues getting closed without fixes lately.

[jackettbot]

Hi @LoganXShadow,

No response has been received for 7 days. To prevent issue tracker clutter, this issue will now be closed. To re-open the issue, please provide the information requested and the issue will automatically re-open.

[Commissar0617]

debian is still openssl 1.1.1

[geoffgs]

Anyone have an idea what the workaround might be in a TrueNAS cage? Our packages don't make use of /etc/ca-certificates.conf and I've tried moving the two DST X3 certs I found in /etc/ssl/certs/ to /etc/certs/blacklisted/ but couldn't solve it.

I'll move to docker if necessary but if I can get away with a workaround a little bit longer that would be helpful.

[Commissar0617]

yeah, disabling in /etc/ca-certificates.conf fixed it.

[geoffgs]

yeah, disabling in /etc/ca-certificates.conf fixed it.

Unfortunately that conf file doesn't exist as it isn't in use in my TrueNAS/mono6.8 cage. Blacklisted with certctl didn't solve it either:

# certctl list | grep DST
2e5ac55d.0 DST Root CA X3
# certctl blacklist 2e5ac55d.0 

Used certmgr to do the same for the specific serial number. Manually edited the pem in /etc/ssl/certs to remove the one that expired Sept 30 and rehashed, but still no luck.

[Commissar0617]

yeah, disabling in /etc/ca-certificates.conf fixed it.

Unfortunately that conf file doesn't exist as it isn't in use in my TrueNAS/mono6.8 cage. Blacklisted with certctl didn't solve it either:

# certctl list | grep DST
2e5ac55d.0 DST Root CA X3
# certctl blacklist 2e5ac55d.0 

have you tried contacting Truenas support? assuming you're using the plugin?

[fulder]

yeah, disabling in /etc/ca-certificates.conf fixed it.

Unfortunately that conf file doesn't exist as it isn't in use in my TrueNAS/mono6.8 cage. Blacklisted with certctl didn't solve it either:

# certctl list | grep DST
2e5ac55d.0 DST Root CA X3
# certctl blacklist 2e5ac55d.0 

Used certmgr to do the same for the specific serial number. Manually edited the pem in /etc/ssl/certs to remove the one that expired Sept 30 and rehashed, but still no luck.

I don't think your certctl blacklist command here is really correct @geoffgs. From my understanding you should point it to a blacklist file and not the cert ID, so something like certctl blacklist /usr/local/share/certs/blacklist/my_ca.pem (see man page at: https://www.freebsd.org/cgi/man.cgi?query=certctl&apropos=0&sektion=0&manpath=FreeBSD+12.2-RELEASE&arch=default&format=html)

I tried it fast with the Let's Encrypt DST cert but it didn't work either as the certificate is expired so certctl didn't like it. Don't know if there's a more pretty way of doing this than removing it manually from the CA trust file.

There is a related FreeBSD issue about it here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258834

I'm actually the maintainer of the Jackett plugin for TrueNAS and just added a (ugly) quickfix for this problem simply fallbacking to an older mono version, manually removing the CA cert and finally running the cert-sync command. After that it seems like Jackett is able to reach the endpoints with Let's Encrypt certificates properly once again.

See issue comment: fulder/iocage-plugin-jackett#4 (comment) for more info.

[geoffgs]

yeah, disabling in /etc/ca-certificates.conf fixed it.

Unfortunately that conf file doesn't exist as it isn't in use in my TrueNAS/mono6.8 cage. Blacklisted with certctl didn't solve it either:

# certctl list | grep DST
2e5ac55d.0 DST Root CA X3
# certctl blacklist 2e5ac55d.0 

Used certmgr to do the same for the specific serial number. Manually edited the pem in /etc/ssl/certs to remove the one that expired Sept 30 and rehashed, but still no luck.

I don't think your certctl blacklist command here is really correct @geoffgs. From my understanding you should point it to a blacklist file and not the cert ID, so something like certctl blacklist /usr/local/share/certs/blacklist/my_ca.pem (see man page at: https://www.freebsd.org/cgi/man.cgi?query=certctl&apropos=0&sektion=0&manpath=FreeBSD+12.2-RELEASE&arch=default&format=html)

I tried it fast with the Let's Encrypt DST cert but it didn't work either as the certificate is expired so certctl didn't like it. Don't know if there's a more pretty way of doing this than removing it manually from the CA trust file.

There is a related FreeBSD issue about it here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258834

I'm actually the maintainer of the Jackett plugin for TrueNAS and just added a (ugly) quickfix for this problem simply fallbacking to an older mono version, manually removing the CA cert and finally running the cert-sync command. After that it seems like Jackett is able to reach the endpoints with Let's Encrypt certificates properly once again.

See issue comment: fulder/iocage-plugin-jackett#4 (comment) for more info.

You solved it! If another TrueNAS jackett user finds this, follow the issue comment in fulder's comment above for a fix.

[swannie-eire]

I found this fix on truenas forum and can confirm it works on truenas.

here are the steps.

# copy the crt
cp /usr/local/share/certs/ca-root-nss.crt copied_file.crt
# find and remove the crt that contains DST Root CA X3
vi copied_file.crt
# remove mono directory
rm -rf /usr/share/.mono/
#  sync certs
cert-sync copied_file.crt
# go to jackett and test to see if the indexers that were previously giving you the error still are.

[Commissar0617]

yeah, disabling in /etc/ca-certificates.conf fixed it.

Unfortunately that conf file doesn't exist as it isn't in use in my TrueNAS/mono6.8 cage. Blacklisted with certctl didn't solve it either:

# certctl list | grep DST
2e5ac55d.0 DST Root CA X3
# certctl blacklist 2e5ac55d.0 

Used certmgr to do the same for the specific serial number. Manually edited the pem in /etc/ssl/certs to remove the one that expired Sept 30 and rehashed, but still no luck.

Was referring exclusively to debian fix.

[gitthangbaby]

on Synology, i removed the famous certificate from /usr/share/ca-certificates/mozilla and it started working. No docker needed thanksgod. v0.19.

[LordMedric]

Telling someone to run it in another system is not a fix.
I have resolved this issue of certificate validation failed due to SSL this is an issue where Synology does not have the updated Intermediate and Root Certificate in its store.

1st This updates the system will all new CA good for systems running Synology DSM 6.2.3 and oldersystems
sudo -i && cp /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt.ORIG && curl -k "https://letsencrypt.org/certs/isrgrootx1.pem" >> /etc/ssl/certs/ca-certificates.crt && synoservice --restart DSM

2nd This adds Lets encrypt the Cert store for checking.
download
https://letsencrypt.org/certs/isrgrootx1.pem
https://letsencrypt.org/certs/lets-encrypt-r3.pem
and copy them to /etc/ssl/certs

sudo -i && curl -k "https://letsencrypt.org/certs/isrgrootx1.pem" >> /etc/ssl/certs && curl -k "https://letsencrypt.org/certs/lets-encrypt-r3.pem" >> /etc/ssl/certs && synoservice --restart DSM

this worked for me after a few weeks of bagging my head against the wall

[LordMedric]

admin@test:~$ sudo -i
Password: 
root@test:~# sudo -i && cp /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt.ORIG && curl -k "https://letsencrypt.org/certs/isrgrootx1.pem" >> /etc/ssl/certs/ca-certificates.crt
root@test:~# cp /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt.ORIG && curl -k "https://letsencrypt.org/certs/isrgrootx1.pem" >> /etc/ssl/certs/ca-certificates.crt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1939  100  1939    0     0   7126      0 --:--:-- --:--:-- --:--:--  7154
root@test:~# synoservice --restart DSM
root@test:~#