https://bugs.openldap.org/show_bug.cgi?id=10291
Issue ID: 10291 Summary: OpenLDAP matches localhost against local hostname incorrectly Product: OpenLDAP Version: 2.6.2 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs@openldap.org Reporter: cmousefi@gmail.com Target Milestone: ---
When connecting to a localhost LDAP server using TLS, I get this in debug log:
# ldapsearch -ZZ -H ldap://localhost/ -d9 <skip...> TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS certificate verification: depth: 1, err: 0, subject: /CN=Test LDAP CA Root, issuer: /CN=Test LDAP CA Root TLS certificate verification: depth: 0, err: 0, subject: /CN=localhost, issuer: /CN=Test LDAP CA Root TLS trace: SSL_connect:SSLv3/TLS read server certificate TLS trace: SSL_connect:TLSv1.3 read server certificate verify TLS trace: SSL_connect:SSLv3/TLS read finished TLS trace: SSL_connect:SSLv3/TLS write change cipher spec TLS trace: SSL_connect:SSLv3/TLS write finished TLS: hostname (1384a4485398) does not match common name in certificate (localhost). TLS: can't connect: TLS: hostname does not match name in peer certificate. ldap_err2string ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match name in peer certificate
Expected behaviour: When connecting to localhost, I would expect the certificate issued to localhost to work. Actual behaviour: Certificate is issued to localhost but ldapsearch matches against local hostname.
Here is the server certificate textual presentation
subject=CN=localhost Certificate: Data: Version: 3 (0x2) Serial Number: 41:68:1b:be:cb:46:95:45:e7:72:03:8b:6c:b4:75:55:ca:5c:cb:c9 Signature Algorithm: ecdsa-with-SHA256 Issuer: CN=Test LDAP CA Root Validity Not Before: Dec 3 19:04:58 2024 GMT Not After : Sep 2 19:04:58 2034 GMT Subject: CN=localhost Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:f5:f1:f4:7d:56:85:87:b2:98:c9:b2:a2:83:ef: 52:71:01:1e:81:64:9f:64:ec:99:5a:e4:38:63:13: 69:de:09:00:1e:a1:e1:83:4a:c6:58:0d:c0:bb:4f: 36:7f:5a:f7:8f:74:b4:e2:96:06:09:9b:2c:0d:fb: 8c:6d:57:44:2e ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Subject Key Identifier: 5A:54:AF:41:E8:A0:EC:3D:28:3D:D6:0D:91:20:97:73:FA:40:AE:9C X509v3 Authority Key Identifier: FB:AF:31:4B:A2:2B:E1:DA:55:6A:3F:EE:D1:A4:74:51:C7:B9:9F:A7 X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Subject Alternative Name: IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1, DNS:localhost, DNS:localhost.localdomain Signature Algorithm: ecdsa-with-SHA256 Signature Value: 30:46:02:21:00:d4:9a:16:ba:6e:1d:c7:df:bd:5b:3d:56:b7: 0d:ea:aa:a7:7a:7f:d0:c1:ed:77:11:48:e8:aa:b1:6a:a8:ac: 28:02:21:00:d8:41:3d:a0:52:c8:2b:cc:13:34:46:1b:34:dd: 96:87:e5:7c:71:62:50:f3:2d:b1:18:3d:ce:27:34:c9:c4:32
https://bugs.openldap.org/show_bug.cgi?id=10291
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #1 from Quanah Gibson-Mount quanah@openldap.org --- This is explicitly tested in test067 in the test suite which passes w/o issue.
It appears you've modified your /etc/hosts to map "localhost" to hostname, which is why this fails.
Explicitly, this error:
TLS: hostname (1384a4485398) does not match common name in certificate (localhost).
https://bugs.openldap.org/show_bug.cgi?id=10291
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=10291
Aki Tuomi cmousefi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|VERIFIED |UNCONFIRMED
--- Comment #2 from Aki Tuomi cmousefi@gmail.com --- Thank you for the reply, unfortunately this does not appear to be the case
# cat /etc/hosts 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters 172.17.0.6 13b06d5f55e4 fd0d:80e3:872f::242:ac11:6 13b06d5f55e4
Shows that this is not the case. Also it does not explain the inconsistent behavior where direct TLS works, and STARTTLS fails.
https://bugs.openldap.org/show_bug.cgi?id=10291
--- Comment #3 from Aki Tuomi cmousefi@gmail.com --- I also checked
$ getent ahosts localhost ::1 STREAM localhost ::1 DGRAM ::1 RAW 127.0.0.1 STREAM 127.0.0.1 DGRAM 127.0.0.1 RAW
$ getent ahosts 127.0.0.1 127.0.0.1 STREAM 127.0.0.1 127.0.0.1 DGRAM 127.0.0.1 RAW
https://bugs.openldap.org/show_bug.cgi?id=10291
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #4 from Quanah Gibson-Mount quanah@openldap.org --- Again, as I noted, this is explicitly tested in test067. Your output *clearly* shows that "localhost" is getting resolved to a hostname. This is not an OpenLDAP issue.
https://bugs.openldap.org/show_bug.cgi?id=10291
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |INVALID
https://bugs.openldap.org/show_bug.cgi?id=10291
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=10291
--- Comment #5 from Aki Tuomi cmousefi@gmail.com --- After looking at the source code of openldap, it seems that my system is resolving things just fine, it's the LDAP client choosing to use server's hostname as validation target instead of localhost.
So this is expected behaviour but for different reason you claimed.