As a workaround you can set 'ldap_tls_reqcert' to 'allow' or 'never' this disables the certificate checks, but will still give you an encrypted connection.

I'm afraid we currently cannot add a fix based on your suggestion, because we rely here on the OpenLDAP client libraries which use the same URI to connect to the LDAP serve and to validate the certificate.

But maybe there is another solution which can help here. If you have the chance to recreate the server certificate please try to add an 'Subject Alternative Name' (see e.g. http://www.openssl.org/docs/apps/x509v3_config.html#Subject_Alternative_Name_ for details) with the IP address of your server. Then the client should be able to validate the certificate evern if the IP address is used to setup the connection. Please note, I haven't tried this myself so far and I cannot promise that it will work. It would be nice if you can post the results here if you have a chance to test this approach.

I don't think that setting ldap_tls_reqcert to allow would work because that disallows performing authentication by binding against LDAP (if I remember correctly). I think I will try the Subject Alternative Name and see how that goes. I'll report back shortly.

Replying to [comment:2 amcnabb]:

I don't think that setting ldap_tls_reqcert to allow would work because that disallows performing authentication by binding against LDAP (if I remember correctly).

No, it would not prevent authentication by LDAP bind. It would remove the restriction that an invalid certificate would prevent the bind. With "allow", we'd just accept a faulty certificate for setting up the encryption channel, then do the bind within that channel.

Another alternative workaround that you might consider would be to install dnsmasq on the client and point /etc/resolv.conf at that server. Then you could set the appropriate IP address mapping in your /etc/hosts file and the DNS lookup that SSSD does internally would remain local to the machine instead of relying on a remote DNS server.

It worked. Thanks for the suggestion.

I had to do a bunch of hunting to find out how to do this, so I think it would be really helpful to add information to the sssd documentation. When I signed the certificate, I used to run:

openssl x509 -req -in "$cadir/req.pem" -out "$cadir/cert.pem" -days 1000 \
-CA "$cadir/cacert.pem" -CAkey "$cadir/cakey.pem" \
-CAserial "$cadir/ca.srl" -CAcreateserial

but now I run:

extfile="$cadir/extfile"
echo "subjectAltName=IP:10.0.0.10,IP:192.168.36.6" >$extfile
openssl x509 -req -in "$cadir/req.pem" -out "$cadir/cert.pem" -days 1000 \
-extfile "$extfile" -CA "$cadir/cacert.pem" -CAkey "$cadir/cakey.pem" \
-CAserial "$cadir/ca.srl" -CAcreateserial

In other words, I created a file with the contents "subjectAltName=IP:10.0.0.10,IP:192.168.36.6" and passed this in to x509 using the "-extfile" option. Alternatively, if someone is using a custom openssl.cnf, there are more readily available (though somewhat convoluted) instructions out there about how to add an x509 extensions section to openssl.conf.

Thanks again for pointing me in the right direction, and hopefully this information will be able to make its way to documentation to help others figure it out, too.

priority: critical => major
summary: Could not start TLS encryption. TLS: hostname does not match CN in peer certificate => Add documentation about subjectAltName
type: defect => enhancement

Replying to [comment:3 sgallagh]:

Replying to [comment:2 amcnabb]:

I don't think that setting ldap_tls_reqcert to allow would work because that disallows performing authentication by binding against LDAP (if I remember correctly).

No, it would not prevent authentication by LDAP bind. It would remove the restriction that an invalid certificate would prevent the bind. With "allow", we'd just accept a faulty certificate for setting up the encryption channel, then do the bind within that channel.

When I upgraded to Fedora 13, I had to set up SSL certificates to get LDAP authentication to work. I thought that I had tried setting "allow" and that this didn't work, but it's been a long time, so I don't remember any of the details. In any case, our certificates have been working well with SSSD, so I'm not too worried about it.

Another alternative workaround that you might consider would be to install dnsmasq on the client and point /etc/resolv.conf at that server. Then you could set the appropriate IP address mapping in your /etc/hosts file and the DNS lookup that SSSD does internally would remain local to the machine instead of relying on a remote DNS server.

That's a good suggestion, too.

Thanks for your help.

Thank you very much for your feedback. I will add a paragraph about subjectAltName to the sssd-ldap man page.

owner: somebody => sbose

Turn into a doc bug.

milestone: NEEDS_TRIAGE => SSSD 1.5.0

Created https://bugzilla.redhat.com/show_bug.cgi?id=653881

This documentation does not belong in SSSD itself. It is an issue with certificates themselves, and are best addressed elsewhere.

See the Bugzilla ticket in comment 8, which will update Fedora's deployment documentation.

resolution: => wontfix
status: new => closed

Redhat bug #653881 is a RHEL bug, not a Fedora bug, so its getting fixed won't necessarily help Fedora users, right?

Replying to [comment:10 amcnabb]:

Redhat bug #653881 is a RHEL bug, not a Fedora bug, so its getting fixed won't necessarily help Fedora users, right?

Our doc guy does both the Fedora and RHEL documentation for this, so it should make its way into Fedora as well.

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1708

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.