I am making an attempt to arrange DNS-over-TLS (DoT) with unbound resolver. i.e. I am making an attempt to encrypt the connection between the shopper and unbound I am NOT making an attempt to encrypt the unbound resolver → upstream connection, which many guides on the web are speaking about.

I’ve the next within the config file, as defined within the man web page, and likewise described right here:

 server:
   interface: 0.0.0.0@853

   tls-port: 853
   tls-service-key: "/and many others/letsencryp/dwell/DOMAIN/privkey.pem"
   tls-service-pem: "/and many others/letsencryp/dwell/DOMAIN/fullchain.pem"

However when I attempt to restart unbound, I get the next permission denied on the certificates information.

package-helper[778]: /var/lib/unbound/root.key has content material
package-helper[778]: success: the anchor is okay
unbound[813]: [1586107523] unbound[813:0] error: error for cert file: /and many others/letsencryp/dwell/DOMAIN/fullchain.pem
unbound[813]: [1586107523] unbound[813:0] error: error in SSL_CTX use_certificate_chain_file crypto error:0200100D:system library:fopen:Permission denied
unbound[813]: [1586107523] unbound[813:0] error: and moreover crypto error:20074002:BIO routines:file_ctrl:system lib
unbound[813]: [1586107523] unbound[813:0] error: and moreover crypto error:140DC002:SSL routines:use_certificate_chain_file:system lib
unbound[813]: [1586107523] unbound[813:0] deadly error: couldn't arrange pay attention SSL_CTX
systemd[1]: unbound.service: Most important course of exited, code=exited, standing=1/FAILURE

I’ve tried shifting the information out of this listing, and experimented with setting root or unbound because the proprietor. The one means I might make it work was to position the information instantly within the /and many others/unbound/ listing. A symlink in the identical location pointing to letsencrypt managed information did not work both. This isn’t ultimate, as I might must recurrently copy the certificates information out of letsencrypt listing every time a certificates renewal happens and/or unnecessarily restart the DNS resolver.

I’ve completely checked {that a} chroot is just not configured in config information, or default settings, or compiled within the binary. Actually, it has been explicitly disabled by default in Debian (bug report)

How can unbound be unable to learn information, that’s proper there, with unbound:unbound as proprietor:group, and permissions set as readable?

I am utilizing unbound model 1.9.0-2+deb10u1 on Debian buster (10), if it is of any significance.