When validating a certificate, be sure to use the context of the DNS service... So, if your service runs under user BIND, you may need to su to BIND to test. This may help flush out issues where the ca.crt file was set so BIND could not read it.
I don't know what happens when you set TLS to strict, but I would think there's a way of trusting a self-signed certificate by adding as a CA file. You could expand your openssl commands to create a self-signed CA, then sign each certificate with that CA. See easy-rsa as way of testing this. You only need to add a few more openssl commands to your list. RW ________________________________ From: bind-users <bind-users-boun...@lists.isc.org> on behalf of Klaus Darilion via bind-users <bind-users@lists.isc.org> Sent: Thursday, February 27, 2025 11:10 AM To: Greg Choules via bind-users <bind-users@lists.isc.org> Subject: XoT Testing: TLS peer certificate verification failed This email originated from outside of TESLA Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi! I want to test XoT between Bind9.20.6 primary and secondary. On the primary I created a self-signed certificate with CN=xot-test-primary.ops.nic.at and configured bind: # Create a 10years valid self-signed certificate: # openssl genpkey -algorithm RSA -out private.key -pkeyopt rsa_keygen_bits:2048 # openssl req -new -key private.key -out request.csr -subj "/CN=xot-test-primary.ops.nic.at" # openssl x509 -req -days 3650 -in request.csr -signkey private.key -out certificate.crt # openssl x509 -text -noout -in certificate.crt # chmod g+r private.key # # Create DH-params file to enable Diffie-Hellman Perfect Forward Secrecy: # openssl dhparam -out dhparam.pem 4096 # # https://bind9.readthedocs.io/en/v9.20.6/reference.html#namedconf-statement-tls tls xot-test { cert-file "/etc/bind/certificate.crt"; dhparam-file "/etc/bind/dhparam.pem"; key-file "/etc/bind/private.key"; }; options { listen-on { 193.46.106.51; }; listen-on-v6 { 2a02:850:1:4::51; }; listen-on tls xot-test { 193.46.106.51; }; listen-on-v6 tls xot-test { 2a02:850:1:4::51; }; }; That seems to work fine. Then I configured the secondary similar: # Create a 10years valid self-signed certificate: # openssl genpkey -algorithm RSA -out private.key -pkeyopt rsa_keygen_bits:2048 # openssl req -new -key private.key -out request.csr -subj "/CN=xot-test-secondary.ops.nic.at" # openssl x509 -req -days 3650 -in request.csr -signkey private.key -out certificate.crt # openssl x509 -text -noout -in certificate.crt # chmod g+r private.key # # Create DH-params file to enable Diffie-Hellman Perfect Forward Secrecy: # openssl dhparam -out dhparam.pem 4096 # # https://bind9.readthedocs.io/en/v9.20.6/reference.html#namedconf-statement-tls tls xot-test { #ca-file "/etc/bind/ca.crt"; # Activating ca-file force client-certificates for incoming TLS connections cert-file "/etc/bind/certificate.crt"; dhparam-file "/etc/bind/dhparam.pem"; key-file "/etc/bind/private.key"; #remote-hostname "xot-test-primary.ops.nic.at"; }; // may occur multiple times zone "test.klaus" { type secondary; file "/var/cache/bind/test.klaus"; // Path to your zone file primaries { 193.46.106.51 key "tsig-key" tls xot-test; 2a02:850:1:4::51 key "tsig-key" tls xot-test; }; I copied the primary’s certificate.crt to the secondary as ca.crt. Using opportunistic TLS, zone transfer works fine. But if I enable strict TLS, either by uncommenting ‘ca-file’ or ‘remote-hostname’ option, the TLS verification fails: transfer of 'test.klaus/IN' from 193.46.106.51#853: failed to connect: TLS peer certificate verification failed But the setup on the primary looks fine. I can successfully open a TLS connection when using curl: # curl -v https://xot-test-primary.ops.nic.at:853 --cacert ca.crt * Host xot-test-primary.ops.nic.at:853 was resolved. * IPv6: (none) * IPv4: 193.46.106.51 * Trying 193.46.106.51:853... * Connected to xot-test-primary.ops.nic.at (193.46.106.51) port 853 * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: ca.crt * CApath: /etc/ssl/certs * 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 / X25519 / RSASSA-PSS * ALPN: server did not agree on a protocol. Uses default. * Server certificate: * subject: CN=xot-test-primary.ops.nic.at * start date: Feb 27 14:02:56 2025 GMT * expire date: Feb 25 14:02:56 2035 GMT * common name: xot-test-primary.ops.nic.at (matched) * issuer: CN=xot-test-primary.ops.nic.at * SSL certificate verify ok. * Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption So, what am I doing wrong? Is Bind using a not-trivial TLS certificate verification? I also failed getting more verbose verification details. Any help is appreciated. Thanks Klaus
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
