I see this note and some examples on this page that include the DNS: option:
http://wiki.cacert.org/FAQ/subjectAltName FAQ/subjectAltName (SAN) What is subjectAltName ? subjectAltName specifies additional subject identities, but for host names (and everything else defined for subjectAltName) : subjectAltName must always be used (RFC 3280 4.2.1.7, 1. paragraph). CN is only evaluated if subjectAltName is not present and only for compatibility with old, non-compliant software. So if you set subjectAltName, you have to use it for all host names, email addresses, etc., not just the "additional" ones. subjectAltName and CAcert CSR parser The CSR parser strips any commonNames and subjectAltNames if the system can't match the domain in the system to your account, you can view domains listed on your account by going to the domains section of the website after you log in, and then clicking on View<https://www.cacert.org/account.php?id=9>. (For this link to work, you have to log in with your username and password, not with a client certificate.) According to the standards commonName will be ignored if you supply a subjectAltName in the certificates, verified to be working in both the latest version of MS IE and Firefox (as of 2005/05/12)... RW ________________________________ From: bind-users <bind-users-boun...@lists.isc.org> on behalf of Klaus Darilion via bind-users <bind-users@lists.isc.org> Sent: Tuesday, March 4, 2025 8:55 AM To: Klaus Darilion <klaus.daril...@nic.at>; Ondřej Surý <ond...@isc.org> Cc: bind-us...@isc.org <bind-us...@isc.org> Subject: RE: 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. I think I have solved the mistery: Bind (or openssl, who ever does the validation) requires Subject Alternative Name. Regardless if using the hostname or the IP address, they must be in the subject alternative name. When using self-signed certificates, it is probably best to put both in the SAN. Using the following certificate on the server, the validation in dig works fine, regardless if using the hostname or IP address. If somebody wants to test XoT, that might help bootstrapping: openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout san-private.key -out san-certificate.crt -subj "/CN=xot-test-primary.ops.nic.at" -addext "subjectAltName=DNS:xot-test-primary.ops.nic.at,IP:193.46.106.51" regards Klaus From: bind-users <bind-users-boun...@lists.isc.org> On Behalf Of Klaus Darilion via bind-users Sent: Tuesday, March 4, 2025 11:31 AM To: Ondřej Surý <ond...@isc.org> Cc: bind-us...@isc.org Subject: RE: XoT Testing: TLS peer certificate verification failed In my case it should not be SNI relevant, as the server only has 1 certificate to present. Anyways, I will now test with a certificate that uses the IP address in the Subject CN. Regards Klaus -- Klaus Darilion, Head of Operations nic.at GmbH, Jakob-Haringer-Straße 8/V 5020 Salzburg, Austria From: Ondřej Surý <ond...@isc.org<mailto:ond...@isc.org>> Sent: Tuesday, March 4, 2025 10:05 AM To: Klaus Darilion <klaus.daril...@nic.at<mailto:klaus.daril...@nic.at>> Cc: bind-us...@isc.org<mailto:bind-us...@isc.org> Subject: Re: XoT Testing: TLS peer certificate verification failed Sounds like this: https://gitlab.isc.org/isc-projects/bind9/-/issues/3896 -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. On 4. 3. 2025, at 10:01, Klaus Darilion via bind-users <bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>> wrote: May it be, that the validation is just broken? Even when using dig, and explicitely use the hostname of the Primary (which uses its hostname in its certificate) in @... and tls-hostname, the verification fails due to hostname mismatch: # dig @xot-test-primary.ops.nic.at test.klaus +tls axfr +tls-ca=ca.crt +tls-hostname=xot-test-primary.ops.nic.at +tls-certfile=certificate.crt +tls-keyfile=private.key ;; TLS peer certificate verification for 193.46.106.51#853 failed: hostname mismatch Regards Klaus From: Klaus Darilion Sent: Thursday, February 27, 2025 5:11 PM To: Greg Choules via bind-users <bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>> Subject: XoT Testing: TLS peer certificate verification failed 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<mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users
-- 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
