On 18 Apr 2020, at 02:01, Clayvahn Hunt <hunt(a)xitis.com>
wrote:
Thank you Johannes,
> Can you try again without ignoring the certificate, but specify the server'sFQDN
> instead of localhost?
I have done as you suggest (see dsrc contents below), restarted the instance, then (note:
ldaps://ent-a.aeho.lan):
LDAPTLS_CACERT=/etc/dirsrv/slapd-localhost/ca.crt ldapwhoami -v -H ldaps://ent-a.aeho.lan
-D uid=huncl01,ou=people,dc=aeho,dc=lan -W -x
and the results remains:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
If that worked, I would be very concerned as the whole idea is not *not* be tied to a
specific hostname (unless running multiple LDAP servers, no?)
I've put everything back the way it should (?!) be... but here's my .dsrc file
to test your theory:
dsrc only affects dsconf and dsidm commands. the ldap* commands are from openldap and are
affected by the openldap config at /etc/openldap/ldap.conf. Confusing, no? :)
So your dsrc doesn't affect ldapwhoami.
The LDAP* env variables you are using directly map to options in ldap.conf. So for
example:
/etc/openldap/ldap.conf
BASE dc=example,dc=com
TLS_CACERT /path/to/ca.crt
so ldapwhoami will read ldap.conf and use that config. But you can also use the env vars
to over-load that. The variablse are LDAP<config name>, IE LDAPBASE=dc=foo or
LDAPTLS_CACERT ....
Anyway, by default the value of TLS_REQCERT is "hard",
TLS_REQCERT <level>
Specifies what checks to perform on server certificates in a TLS session, if
any. The <level> can be specified as one of the following keywords:
never The client will not request or check any server certificate.
allow The server certificate is requested. If no certificate is
provided, the session proceeds normally. If a bad certificate is provided, it will be
ignored and the session proceeds nor-
mally.
try The server certificate is requested. If no certificate is provided,
the session proceeds normally. If a bad certificate is provided, the session is
immediately terminated.
demand | hard
These keywords are equivalent. The server certificate is requested.
If no certificate is provided, or a bad certificate is provided, the session is
immediately terminated. This is the
default setting.
This means you have to have a cn=<hostname> or subjectaltname that matches the ldap
server hostname, and that the cert is valid with a proper chain.
So if your cert is still from the unmodified, self-signed creation:
openssl s_client -connect idm.blackhats.net.au:636
CONNECTED(00000003)
depth=1 C = AU, ST = Queensland, L = 389ds, O = testing, CN =
ssca.389ds.example.com
verify error:num=19:self signed certificate in certificate chain
verify return:0
If you connect with:
LDAPTLS_REQCERT=hard LDAPTLS_CACERT=/path/to/ca.crt ldapwhoami -H
ldaps://idm.blackhats.net.au ...
This will fail to connect with:
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
additional info: SSLHandshake() failed: misc. bad certificate (-9825)
I think that later versions of openldap client give the extra details but older versions
give the error you see, which is very confusing :)
Anyway, the bad cert is because the cn (
ssca.389ds.example.com) will never match the
hostname.
So if you use:
LDAPTLS_REQCERT=never ldapwhoami -H ldaps://idm.blackhats.net.au:3636
-x
anonymous
REQCERT=never turns of CA chain checking and the hostname checks.
So you probably need to get at cert that has a correct cn in your instance, and then you
can use the ca.
There are some helpers in 389 for this to configure your instances TLS certs:
dsctl inst tls --help
usage: dsctl [instance] tls [-h]
{list-ca,list-client-ca,show-server-cert,show-cert,generate-server-cert-csr,import-client-ca,import-ca,import-server-cert,import-server-key-cert,remove-cert}
...
positional arguments:
{list-ca,list-client-ca,show-server-cert,show-cert,generate-server-cert-csr,import-client-ca,import-ca,import-server-cert,import-server-key-cert,remove-cert}
action
list-ca list server certificate authorities including intermediates
list-client-ca list client certificate authorities including intermediates
show-server-cert Show the active server certificate that clients will see and
verify
show-cert Show a certificate's details referenced by it's nickname.
This is analogous to certutil -L -d <path> -n <nickname>
generate-server-cert-csr
Generate a Server-Cert certificate signing request - the csr is
then submitted to a CA for verification, and when signed you import with import-ca and
import-server-cert
import-client-ca Import a CA trusted to issue user (client) certificates. This is
part of how client certificate authentication functions.
import-ca Import a CA or intermediate CA for signing this servers
certificates (aka Server-Cert). You should import all the CA's in the chain as
required.
import-server-cert Import a new Server-Cert after the csr has been signed from a CA.
import-server-key-cert
Import a new key and Server-Cert after having been signed from a
CA. This is used if you have an external csr tool or a service like lets encrypt that
generates PEM keys externally.
remove-cert Delete a certificate from this database. This will remove it from
acting as a CA, a client CA or the Server-Cert role.
You can choose to use a self-signed cert with the correct CN/SANs, or you could automate
these commands with something like lets encrypt to inject the PEM files into the 389
instance.
Hope that helps,
[localhost]
uri = ldapi://%%2fvar%%2frun%%2fslapd-localhost.socket
basedn = dc=aeho,dc=lan
binddn = cn=Directory Manager
[localhost-ldaps]
#uri = ldaps://localhost
uri = ldaps://ent-a.aeho.lan
basedn = dc=aeho,dc=lan
binddn = cn=Directory Manager
tls_cacertdir = /389
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs