Beberapa sistem tidak dapat terhubung ke ldap melalui ldaps, tetapi yang lain bisa, apakah itu wildcard cert?


15

Ketika mencoba membuat koneksi ldaps ke server Novel eDirectory 8.8 saya, kadang-kadang saya harus memasukkan TLS_REQCERT neverfile ldap.conf ke server klien. Jelas, ini ide yang buruk.

Perintah yang saya jalankan adalah sesuatu seperti ini dengan kredensial yang benar-benar berfungsi ...

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

Di Ubuntu 13.10, itu berfungsi dengan baik.

Pada SLES berfungsi dengan baik.

Pada CentOS 6.5 ia mengembalikan:

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

Sekarang, sertifikat yang saya impor adalah sertifikat wildcard yang dibeli dari DigiCert. Rekan kerja saya menemukan beberapa laporan yang menunjukkan bahwa beberapa sistem memiliki masalah dengan wildcard.

Jadi, apakah sertifikat wildcard yang harus disalahkan? Jika demikian, bagaimana cara memperbaikinya?

Jika bukan sertifikat wildcard, lalu apa itu?

Mengikuti saran Andrew Schulman, saya menambahkan -d1perintah ldapsearch saya. Inilah yang akhirnya saya dapatkan:

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)

Dari apa yang dikatakan, CentOS tidak mempercayai DigiCert? Atau CentOS tidak memiliki daftar penerbit tepercaya?


1
"Tidak dapat menghubungi server LDAP" terdengar lebih seperti server tidak dapat dijangkau dari mesin klien itu. Sudahkah Anda memeriksa terlebih dahulu bahwa Anda sebenarnya dapat terhubung dengannya? Misalnya telnet ldapserver ldapsatau openssl s_client -connect ldapserver:636.
Richard E. Silverman

Ya, saya telah mengkonfirmasi bahwa itu dapat terhubung ke server. Lagipula, itu tidak akan bekerja sama sekali jika tidak bisa terhubung sama sekali.
David R.

Anda menyebutkan tiga host klien yang berbeda. Yang tidak berfungsi mungkin tidak dapat terhubung karena masalah jaringan sementara yang lain bisa.
Richard E. Silverman

Saya pikir posting saya cukup jelas bahwa saya mengedit file ldap.conf di semua host. Seperti ketika saya menambahkan baris ke file, itu berfungsi, tetapi tanpa garis itu tidak. Jadi, bukan masalah koneksi.
David R.

Itu tidak jelas bagi saya ketika saya membaca posting Anda pada awalnya, meskipun saya mengerti apa yang Anda maksud sekarang. Bagaimanapun, info debug TLS yang Anda tambahkan menunjukkan masalah; Saya telah menambahkan jawaban untuk ditindaklanjuti.
Richard E. Silverman

Jawaban:


9

ldapsearch mencari di / etc / openldap / cacerts untuk penyimpanan sertifikat CA tepercaya, dan yang tampaknya tidak diatur, dan karenanya menolak sertifikat karena tidak dapat membangun rantai kepercayaan untuk itu. Jika ldapsearch menggunakan OpenSSL, itu akan memerlukan koleksi format "hashdir" seperti yang dihasilkan oleh misalnya program Red Hat "authconfig", atau satu file dengan daftar datar sertifikat tepercaya. Referensi di sini untuk "moznss" menunjukkan bahwa ldapsearch ini dibangun melawan Mozilla NSS, dalam hal ini Anda perlu menggunakan "certutil" untuk membuat cert db (atau lebih baik, arahkan ke toko sertifikat sistem NSS, jika ada) .

Pada sistem di mana ia bekerja, ldapsearch harus memiliki toko sertifikat yang berfungsi, mungkin karena paket-paket OpenLDAP dibangun terhadap OpenSSL sebagai gantinya (atau mungkin ada toko gaya NSS yang berfungsi tersedia di sana).


2
Ah. /etc/openldap/certsDisinilah tempat toko sertifikat. Bukan cacerts. Di /etc/openldap/ldap.conf saya berubah TLS_CACERTDIR /etc/openldap/cacertsmenjadi TLS_CACERTDIR /etc/openldap/certsdan perintah ldapsearch saya mulai bekerja. Terima kasih!
David R.

Saya telah menginstal ldapsearch di Ubuntu 16.04, dan tidak ada direktori / etc / openldap.
vcardillo

13

ldapsearch akan mengatakan "Tidak dapat menghubungi server LDAP" jika tidak dapat memverifikasi sertifikat TLS. Tambahkan -d1ke perintah ldapsearch Anda, dan periksa baris output yang dimulai dengan "TLS:" untuk mendapatkan informasi lebih lanjut tentang apakah koneksi TLS gagal dan mengapa.


Saya mengedit pertanyaan saya sebagai tanggapan atas saran Anda. Terima kasih!
David R.

8

Solusi tergantung pada instalasi Anda:

  • Jika Anda menggunakan sertifikat yang tidak valid , Anda dapat memaksa menerimanya /etc/openldap/ldap.confdengan konfigurasi

    TLS_REQCERT allow
    

    atau

    TLS_REQCERT never
    
  • Jika Anda menggunakan sertifikat yang valid, mungkin instalasi ldap Anda tidak tahu di mana penyimpanan sertifikat CA tepercaya (mungkin tergantung pada instalasi OpenSSL Anda). Kemudian Anda dapat mencoba mengaturnya dan memaksa memeriksa /etc/openldap/ldap.confdengan

    TLS_CACERT /etc/openldap/cacert
    TLS_REQCERT demand
    

    /etc/openldap/cacertdapat ini atau berada di jalur apa pun. Itu harus mengandung rantai sertifikat CA Anda. Ini bisa berupa file tunggal dengan daftar datar sertifikat tepercaya.

Catatan jalur tergantung pada penyedia ldap. Ini bisa menjadi /etc/ldapatau /etc/openldapatau lebih.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.