Cert error when trying to access torrent trackers, causing problems with Jackett

Troubleshooting
1

Hi,

I have an issue to get Jackett working correctly on my Rpi4. I first thought the problem came from Jackett, so I asked here:

https://github.com/Jackett/Jackett/issues/12595

But it appears the problem comes from my system.
The problem that I have in Jackett also happens when trying to reach the website from the command line.

Output of

curl -v https://bt4g.org/

:

root@DietPi:~# curl -v https://bt4g.org/
*   Trying ::1:443...
* Connected to bt4g.org (::1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* 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_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=[mypersonaldomain]
*  start date: Oct 19 18:23:13 2021 GMT
*  expire date: Jan 17 18:23:12 2022 GMT
*  subjectAltName does not match bt4g.org
* SSL: no alternative certificate subject name matches target host name 'bt4g.org'
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name 'bt4g.org'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

What’s strange is that the error returned is linked to my personal domain, that I host with Nginx. But how could it be related to my personal cert ?

This error also happens in Jackett, it can’t reach the website and can’t work. Some trackers still work though, but around 50% of them fail with this error.

What does that mean ? How could I fix it ?
Any help, any answer is welcome.
Have a great day !

2

do you use any firewall or router who is doing SSL certificate inspection? Any special think on your network?

3

The resolving of this address is incorrect and points to the localhost.
If I was to guess, maybe some adblocking is interfering.

4

Ah nice spot. Was overlooking this.

5

Thanks for your answer.
The problem of an adblock interfering was also what I was suggested on the Jackett github, but the problem is that I have no firewall or adblocker I know about. There is nothing of that type on my pi, nor on my router. On my PC, I can perfectly access all these trackers, so I think I can exclude the router ?
I really don’t know where I should search for this issue.
Is there things I could test or info I could give you to get clues ?

Thanks in advance for any answer.

6

What happen if you try to ping bt4g.org?

As well you could check DNS server used or hosts file

cat /etc/resolv.conf
cat /etc/hosts
7

Here is what I get when I ping bt4g :

PING bt4g.org(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.067 ms
64 bytes from localhost (::1): icmp_seq=2 ttl=64 time=0.066 ms
64 bytes from localhost (::1): icmp_seq=3 ttl=64 time=0.106 ms
64 bytes from localhost (::1): icmp_seq=4 ttl=64 time=0.119 ms
64 bytes from localhost (::1): icmp_seq=5 ttl=64 time=0.073 ms
64 bytes from localhost (::1): icmp_seq=6 ttl=64 time=0.128 ms
64 bytes from localhost (::1): icmp_seq=7 ttl=64 time=0.061 ms
64 bytes from localhost (::1): icmp_seq=8 ttl=64 time=0.119 ms
64 bytes from localhost (::1): icmp_seq=9 ttl=64 time=0.058 ms
64 bytes from localhost (::1): icmp_seq=10 ttl=64 time=0.075 ms
64 bytes from localhost (::1): icmp_seq=11 ttl=64 time=0.124 ms
64 bytes from localhost (::1): icmp_seq=12 ttl=64 time=0.059 ms
64 bytes from localhost (::1): icmp_seq=13 ttl=64 time=0.057 ms

It is redirecting to localhost, like when using curl.

resolv.conf :

root@DietPi:~# cat /etc/resolv.conf
# Generated by dhcpcd from eth0.dhcp, eth0.dhcp6, eth0.ra
# /etc/resolv.conf.head can replace this line
domain home
nameserver 192.168.1.1
nameserver fe80::229a:7dff:fe37:5970%eth0
nameserver 2a01:cb00:83e7:3b00:229a:7dff:fe37:5970
# /etc/resolv.conf.tail can replace this line

hosts :

root@DietPi:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 DietPi
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.0.1 organizr.local
8

Something happen with local DNS resolution. You could install dnsutils package. Afterwards use dig to try to resolve the DNS

dig bt4g.org
9

To extend the previous command suggested by Joulinar , add the following:

dig bt4g.org @192.168.1.1; dig bt4g.org @fe80::229a:7dff:fe37:5970%eth0 ; dig bt4g.org @2a01:cb00:83e7:3b00:229a:7dff:fe37:5970 ; dig bt4g.org @8.8.8.8
10

Thanks for your answer. Here are my results :

root@DietPi:~# dig bt4g.org

; <<>> DiG 9.16.22-Raspbian <<>> bt4g.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52896
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 33bedbf65d0f1f5b1ec83ac161ab33b69f7ad11863260f7e (good)
;; QUESTION SECTION:
;bt4g.org.                      IN      A

;; ANSWER SECTION:
bt4g.org.               5       IN      A       127.0.0.1

;; Query time: 10 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Dec 04 10:24:17 +01 2021
;; MSG SIZE  rcvd: 81




root@DietPi:~# dig bt4g.org @192.168.1.1

; <<>> DiG 9.16.22-Raspbian <<>> bt4g.org @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29166
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 98b2a435def90ec6985d5d1d61ab3317268e76b33f3c9c35 (good)
;; QUESTION SECTION:
;bt4g.org.                      IN      A

;; ANSWER SECTION:
bt4g.org.               5       IN      A       127.0.0.1

;; Query time: 10 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Dec 04 10:21:38 +01 2021
;; MSG SIZE  rcvd: 81




root@DietPi:~# dig bt4g.org @fe80::229a:7dff:fe37:5970%eth0

; <<>> DiG 9.16.22-Raspbian <<>> bt4g.org @fe80::229a:7dff:fe37:5970%eth0
;; global options: +cmd
;; connection timed out; no servers could be reached




root@DietPi:~# dig bt4g.org @2a01:cb00:83e7:3b00:229a:7dff:fe37:5970

; <<>> DiG 9.16.22-Raspbian <<>> bt4g.org @2a01:cb00:83e7:3b00:229a:7dff:fe37:5970
;; global options: +cmd
;; connection timed out; no servers could be reached




root@DietPi:~# dig bt4g.org @8.8.8.8

; <<>> DiG 9.16.22-Raspbian <<>> bt4g.org @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31803
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;bt4g.org.                      IN      A

;; ANSWER SECTION:
bt4g.org.               300     IN      A       104.21.63.35
bt4g.org.               300     IN      A       172.67.169.112

;; Query time: 10 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Dec 04 10:23:47 +01 2021
;; MSG SIZE  rcvd: 69

Looks like it doesn’t like ipv6

11

there you go. Your router is giving the incorrect DNS answer

;; ANSWER SECTION:
bt4g.org.               5       IN      A       127.0.0.1

;; Query time: 10 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
12

Coming back to that, now that we have pinpointed the culprit.
It is possible that your PC is using other nameservers, without any configuration from your part. For example browsers now support DNS over HTTPS. Or at some point you added some additional nameserver, like GoogleDNS.
The fact of the matter is that your ISP seems to be blocking on DNS level certain sites. You could try to resolve other torrent or possibly banned hostnames to verify that using your ISP router as the resolver.

13

Hi,

Thanks a lot for your answer.
Ok so now we know where the problem is.

But what is strange is that my ISP is not supposed to block any website (mine is known to let everything pass). Plus, I am using Cloudflare DNS on my Pi, so even if it were blocking sites, it should still work because of Cloudflare, right ?

I can’t find any torrent tracker that is known to be blocked by my ISP, because there is none (at least at our knowledge). There is other torrent trackers that don’t work the same way as bt4g, like TorrentFunk, but I find no way to know if it’s because of my ISP or because of my setup.

I don’t know what I could try to know more…

14

Plus, I am using Cloudflare DNS on my PiNot correct. You are using 192.168.1.1 to serve DNS queries on your DietPi device. This is the one assigned via DHCP. You could switch to Static IP and change DNS server.

15

I just noticed something strange :

1446×722 50.3 KB

My static DNS is correctly set as Cloudflare, but the currently used DNS is still 192.168.1.1, you’re right.
I tried setting it up again but it doesn’t set to Cloudflare at the top. Is it a different thing ?

16

Looks like something leftover from DHCP. Can you share

cat /etc/network/interfaces
17 



root@DietPi:~# cat /etc/network/interfaces
# Location: /etc/network/interfaces
# Please modify network settings via: dietpi-config
# Or create your own drop-ins in: /etc/network/interfaces.d/

# Drop-in configs
source interfaces.d/*

# Ethernet
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.31
netmask 255.255.255.0
gateway 192.168.1.1
#dns-nameservers 1.1.1.1 1.0.0.1

# WiFi
#allow-hotplug wlan0
iface wlan0 inet dhcp
address 0.0.0.0
netmask 0.0.0.0
gateway 0.0.0.0
#dns-nameservers 0.0.0.0
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Just checked interfaces.d, it is empty.

18

Remove the leading # from nameservers.

19

and do a reboot.

20

Thanks for your answer

I tried that yesterday, and tried again today.
But the used DNS in DIETPI-config stays 192.168.1.1, even when the line for dns nameservers is active in /etc/network/interfaces :

1080×858 114 KB

I still can’t reach bt4g.