> On 18 Apr 2020, at 02:01, Clayvahn Hunt <hunt@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
