[RPZ | url] ssl handshake failed crypto error:1416F086:SSL

Version 1.10.0

Configure line: --target=arm-openwrt-linux --host=arm-openwrt-linux --build=x86_64-pc-linux-gnu --program-prefix= --program-suffix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --sysconfdir=/etc --datadir=/usr/share --localstatedir=/var --mandir=/usr/man --infodir=/usr/info --disable-dsa --disable-gost --enable-allsymbols --enable-subnet --with-libexpat=/home/beast/beast/workspace/turris-os-packages-dragons-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr --with-ssl=/home/beast/beast/workspace/turris-os-packages-dragons-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/usr --without-pthreads --enable-tfo-server --enable-tfo-client
Linked libs: pluggable-event internal (it uses select), OpenSSL 1.1.1d 10 Sep 2019
Linked modules: dns64 subnetcache respip validator iterator
TCP Fastopen feature available

---

rpz:
   url: https://urlhaus.abuse.ch/downloads/rpz/

Seems that the address resolves to ip 199.232.18.49 | 151.101.114.49 (fastly CDN), however for each unbound log exhibits:

error: ssl handshake failed crypto error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
notice: ssl handshake failed 199.232.18.49 port 443
notice: ssl handshake failed 151.101.122.49 port 443

Yet, with openssl s_client -connect urlhaus.abuse.ch:443 -status there is no such error ->
ssl.log, neither with gnutls-cli -V -p 443 urlhaus.abuse.ch-> gnu_ssl.log

curl -o /tmp/test https://urlhaus.abuse.ch/downloads/rpz/
wget -O /tmp/test https://urlhaus.abuse.ch/downloads/rpz/

no error either.

[juched78]

I am also having this issue with the entware build. Any updates on how to work around?

[spirillen]

I can confirm this in my build ..... <1.10.0>

[deavmi]

Hi, is there a way to force unbound not to try resolve the remote URL to A record and prefer IPv6 rather?

Mine is stuck saying "unreachable IPv4" as I have an IPv6-only container (and network)

It used to work fine, but something must have changed.

[gthess]

If you have no IPv4 you can use do-ip4: no, that should skip the A lookups.

[deavmi]

Figured out the problem. If URL returns a non 200 code, then it falls back to IPv4 and tries that.

Interesting, but verbosity 2 didn't tell me.

Everything is fine, was the remote host I was fetching from (needed to make an exception onit anubis reverse proxy to allwo unbound through).