Bug 51352
Summary: | SSL/TLS query fails | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | David Wright <ichbin> |
Component: | openldap | Assignee: | Jay Fenlason <fenlason> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Aaron Brown <abrown> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | gabriel_donnell_redhat, jfeeney |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-08-04 20:25:53 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 97675, 97676 |
Description
David Wright
2001-08-09 19:03:17 UTC
We (Red Hat) should really try to fix this before next release. This is almost certainly a mismatch between your host name and the common name recorded in /usr/share/ssl/certs/slapd.pem, especially if slapd.pem was auto-generated. To check if this is the case, run: openssl x509 -in /usr/share/ssl/certs/slapd.pem -noout -text If the "CN" attribute of the "Subject" is something other than the host name you're using to connect to the server (even if the certificate contains "foo.example.com", and you need only use "foo" to establish a connection without TLS). The fix is to remove slapd.pem, generate a new certificate by running "make slapd.pem", and to make certain that the ldap user or group can read the new certificate file. Since this will behavior is sure to break a large number of cases in a hard-to-pinpoint way, I'll revert the automatic creation of certificates for openldap-2.0.11-12 and later. Nalin, you are a minor diety. Minor, not major, because authough you put me on the track of this extremely obscure problem, you didn't quite nail it. :-) My slapd's certificate was completely accurate -- it said cn=128.95.53.190 and that is true. Furthermore, that's the name ldaps://128.95.53.190 under which ldapsearch contacted it. But apparantly 2.0.11 contains new code (relative to 2.0.7) that FIRST RESOLVES the server IP and THEN COMPARES it to the asserted cn. So when I regenerated my slapd's certificate with cn=merleau.rprc.washngton.edu it all worked, even when I give ldapsearch the IP insead of the FQDN. I find this behaviour on the part of OpenLDAP rather absurd. What would it do if an IP resolved to more than one FQDN? Certainly terminiating without any error message doesn't help. I don't know if you have any influence with OpenLDAP, but please do chime in if you do -- I'll also send mail to the OpenLDAP list. *** Bug 97675 has been marked as a duplicate of this bug. *** *** Bug 97676 has been marked as a duplicate of this bug. *** Red Hat Linux and Red Hat Powertools are currently no longer supported by Red Hat, Inc. In an effort to clean up bugzilla, we are closing all bugs in MODIFIED state for these products. However, we do want to make sure that nothing important slips through the cracks. If, in fact, these issues are not resolved in a current Fedora Core Release (such as Fedora Core 5), please open a new issues stating so. Thanks. |