一部のシステムはldapsを介してldapに接続できませんが、他のシステムはワイルドカード証明書ですか?


15

Novel eDirectory 8.8サーバーへのldaps接続を行おうとするTLS_REQCERT neverと、クライアントサーバーのldap.confファイルを入れなければならないことがあります。明らかに、これは悪い考えです。

私が実行するコマンドは、実際に機能する資格情報を持つこのようなものです...

ldapsearch -x -H ldaps://ldapserver -b 'ou=active,ou=people,dc=example,dc=org' -D 'cn=admin,dc=example,dc=org' -W "cn=username"

Ubuntu 13.10では正常に動作します。

SLESでは正常に動作します。

CentOS 6.5では以下を返します。

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

今、私がインポートした証明書はDigiCertから購入したワイルドカード証明書です。私の同僚は、一部のシステムにワイルドカードに関する問題があることを示すレポートを見つけました。

だから、ワイルドカード証明書は非難するのですか?その場合、どうすれば修正できますか?

ワイルドカード証明書でない場合、それは何ですか?

Andrew Schulmanの提案に従って-d1、ldapsearchコマンドに追加しました。ここに私が終わったものがあります:

ldap_url_parse_ext(ldaps://ldap.example.org)
ldap_create
ldap_url_parse_ext(ldaps://ldap.example.org:636/??base)
Enter LDAP Password: 
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.example.org:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.225.0.24:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: certdb config: configDir='/etc/openldap' tokenDescription='ldap(0)' certPrefix='cacerts' keyPrefix='cacerts' flags=readOnly
TLS: cannot open certdb '/etc/openldap', error -8018:Unknown PKCS #11 error.
TLS: could not get info about the CA certificate directory /etc/openldap/cacerts - error -5950:File not found.
TLS: certificate [CN=DigiCert High Assurance EV Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US] is not valid - error -8172:Peer's certificate issuer has been marked as not trusted by the user..
TLS: error: connect - force handshake failure: errno 2 - moznss error -8172
TLS: can't connect: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

それによると、CentOSはDigiCertを信頼していませんか?または、CentOSには信頼できる発行者のリストがありませんか?


1
「LDAPサーバーに接続できません」は、サーバーがそのクライアントマシンから単に到達できないように聞こえます。実際に接続できることを最初に確認しましたか?たとえば、telnet ldapserver ldapsまたはopenssl s_client -connect ldapserver:636
リチャードE.シルバーマン14年

はい、サーバーに接続できることを確認しました。結局、まったく接続できなければ、まったく機能しません。
デビッドR. 14年

3つの異なるクライアントホストについて言及しました。動作していないものは、ネットワークの問題のために接続できなかったかもしれませんが、他のものはできました。
リチャードE.シルバーマン14年

私の投稿は、すべてのホストでldap.confファイルを編集していることがはっきりしていると思いました。ファイルに行を追加したときのように、それは機能しましたが、行がなければ機能しませんでした。したがって、接続の問題ではありません。
デビッドR. 14年

最初にあなたの投稿を読んだとき、それは私には明らかではありませんでしたが、あなたの今の意味がわかります。とにかく、追加したTLSデバッグ情報は問題を示しています。フォローアップするための回答を追加しました。
リチャードE.シルバーマン14年

回答:


9

ldapsearchは、信頼できるCA証明書のストアを/ etc / openldap / cacertsで探していますが、明らかにセットアップされていないため、信頼チェーンを構築できないため、証明書を拒否しています。ldapsearchがOpenSSLを使用している場合、Red Hatの「authconfig」プログラムなどによって生成される「hashdir」形式のコレクション、または信頼できる証明書のフラットリストを持つ単一のファイルが必要になります。ここでの「moznss」への参照は、このldapsearchがMozilla NSSに対して構築されていることを示唆しています。この場合、「certutil」を使用して証明書データベースを作成する必要があります(または、システムNSS証明書ストアがある場合はそれを指すようにする) 。

動作しているシステムでは、おそらくldapsearchが動作する証明書ストアを持っている必要があります。おそらく、それらのOpenLDAPパッケージは代わりにOpenSSLに対して構築されているためです(または動作中のNSSスタイルのストアがあるかもしれません)。


2
あ。/etc/openldap/certs証明書ストアがある場所です。証明書ではありません。/etc/openldap/ldap.confに移動TLS_CACERTDIR /etc/openldap/cacertsTLS_CACERTDIR /etc/openldap/certsて、ldapsearchコマンドが機能し始めました。ありがとう!
デビッドR. 14年

Ubuntu 16.04にldapsearchをインストールしていますが、/ etc / openldapディレクトリがありません。
vcardillo

13

ldapsearchは、TLS証明書を検証できない場合、「LDAPサーバーに接続できません」と表示します。-d1ldapsearchコマンドに追加し、「TLS:」で始まる出力行を確認して、TLS接続が失敗しているかどうかとその理由に関する詳細情報を取得します。


あなたの提案に応えて質問を編集しました。ありがとう!
デビッドR. 14年

8

解決策はインストールに依存します。

  • あなたがされている場合以外、有効な証明書を使用して、あなたが設定し、それを受け入れる強制することができ/etc/openldap/ldap.conf

    TLS_REQCERT allow
    

    または

    TLS_REQCERT never
    
  • あなたがいる場合は、有効な証明書を使用して、信頼できるCA証明書のストアが(おそらく、インストールするOpenSSLに依存する)された場合、おそらくあなたのLDAPインスタレーションは知りません。次に、場所を設定し、強制的にチェック設定/etc/openldap/ldap.confを試みることができます

    TLS_CACERT /etc/openldap/cacert
    TLS_REQCERT demand
    

    /etc/openldap/cacertこれまたは任意のパスに配置できます。CAの証明書チェーンが含まれている必要があります。信頼できる証明書のフラットリストを持つ単一のファイルにすることができます。

注パスはLDAPプロバイダーに依存します。それは可能性があり/etc/ldap、または/etc/openldapあるいはそう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.