Can XoT use self-signed certificates?

NSD
1

Hi!

I am testing XoT with NSD as secondary.

As far as I see, for certificate validation always the OS installed CA certificates are used. (/etc/ca-certificates.conf in Ubuntu)

Is it possible to use self signed certificates and manually configure a trust-anchor (e.g. ca-file option in many other TLS supported software)?

Is it possbile to use opportunistic/ephemeral TLS as supported by Bind?

Thanks
Klaus

2

Answering myself (untested yet): It seems that ‘tls-cert-bundle:’ may be the solution to manually specify trust anchors. Frankly, this is a ‘server:’ option but I would have expected it under the tls-auth: section to be configurable per tls-context.

Regards

Klaus

3

Answering myself (untested yet): It seems that ‘tls-cert-bundle:’ may be the solution to manually specify trust anchors. Frankly, this is a ‘server:’ option but I would have expected it under the tls-auth: section to be configurable per tls-context.

We could modify that of course, but personally I also feel for the pin authentication that Knot-dns employs. Would that work for you?

Regards,

-- Willem

4

Hi Willem!

I am not sure either what would be the best approach. Knot’s PIN approach is great for private installations, but not for general TLS applications where you do not know the other party but want to know a trusted name (confirmed by some well known CA). So far I like Bind’s approach most, where the TLS configuration is similar to standard webservers where you can use either OS installed certificates or provide a list of trusted CA certs manually. Maybe we should wait for more XoT deployments and more feedback from admins.

Anyway, IMHO all 3 implementations (Knot, Bind, NSD) lacks logging of TLS parameters and helpful error messages when TLS handshakes fail.

For example, NSD’s “axfr for … from …. refused tls-auth-xfr-only” as only error log is not very helpful when I try to understand why the connection fails. For example NSD could add some more info if connection fails, like: Did NSD as primary requested a client cert from the secondary name server? If yes, did the secondary provided a certificate? If yes, what is the host name that was searched in the certificate name? Was it found or not? Why was the client certificate not accepted? Or was everything with the client certificate but the configured policy forbids zone transfer?

Thanks

Klaus

5

Another thing: it seems that mutual TLS with NSD as primary requires tls-cert-bundle to be set explicitly. I.e. my secondary has a public certificate from lets encrypt, and I would expect that the default tls-cert-bundle should work. But it does not. I get the misleading error (debug log level):

nsd[2588241]: client cert does not match my-tls xot-test-secondary.ops.nic.at

nsd[2588241]: axfr for test.klaus. from 193.46.106.61 refused, no acl matches

But after explicitly setting the tld-cert-bundle to the LE root CA it suddenly worked:

tls-cert-bundle: /etc/ssl/certs/ISRG_Root_X1.pem

nsd[2600852]: my-tls xot-test-secondary.ops.nic.at verified

nsd[2600852]: axfr for test.klaus. from 193.46.106.61 tls-auth xot-test-secondary.ops.nic.at

So, the above error was wrong and should be something like “failed to verify certificate issuer”.

Further, why is it necessary to explicitly set the tls-cert-bundle? I guess there is a reason as Bind9 also requires to manually set the ca-file for mutual TLS and client verification. I just don’t understand why. Further it complicates life. If my Secondary-DNS provider has a certificate from a well known CA, and the hostname verification succeeds, I want to accept the client cert, regardless if the certificate was issued by Lets Encrypt, Sectigo or Comodo.

Thanks

Klaus

6

Hello Klaus,

Klaus Darilion via nsd-users:

Further, why is it necessary to explicitly set the tls-cert-bundle? I guess there is a reason as Bind9 also requires to manually set the ca-file for mutual TLS and client verification. I just don’t understand why.

different OS flavors have different places for a "default set of certs
trusted by the os vendor" (CA/B truststor)
I think, for that reason, it's nessesary to be explicit in nsd.conf

I assume similiar reasons in unbound...

Andreas

7

Further, why is it necessary to explicitly set the tls-cert-bundle?
I guess there is a reason as Bind9 also requires to manually set the
ca-file for mutual TLS and client verification. I just don’t
understand why.

different OS flavors have different places for a “default set of certs
trusted by the os vendor” (CA/B truststor)
I think, for that reason, it’s nessesary to be explicit in nsd.conf

The confusing thing is, that for “strict TLS” there is no need to configure ‘tls-cert-bundle’ and the OS installed CAs are used for validation. Only for mutual TLS it is mandatory to configure ‘tls-cert-bundle’, for which I do not see any reason.

regards
Klaus