CentOS openLDAP cert trust trust

12
# LDAPTLS_CACERTDIR=/etc/ssl/certs/ ldapwhoami -x -ZZ -H ldaps://ldap.domain.tld
ldap_start_tls: Can't contact LDAP server (-1)
      additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.

# openssl s_client -connect ldap.domain.tld:636 -CApath /etc/ssl/certs
<... successful tls negotiation stuff ...>
    Compression: 1 (zlib compression)
    Start Time: 1349994779
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

openssltampaknya berpikir sertifikat itu baik - baik saja, tetapi openldapperpustakaan ( pam_ldapmenunjukkan perilaku yang sama, yang merupakan bagaimana saya sampai ke kekacauan ini) tidak setuju.
Apa yang saya lakukan salah?

84104
sumber

Jawaban:

17

RHEL sebenarnya tidak menyediakan apa pun yang dapat digunakan sebagai 'direktori sertifikat' untuk tujuan kepercayaan CA. Untuk OpenSSL, direktori sertifikat - 'CApath' - adalah direktori yang berisi file sertifikat individual (dalam format PEM atau format 'sertifikat tepercaya' OpenSSL yang diperluas), dengan nama dalam format tertentu berdasarkan hash dari nama subjek sertifikat. Biasanya ini dicapai dengan meletakkan file dengan nama yang dapat dibaca manusia dan .pemekstensi di direktori dan berjalan c_rehashdi atasnya (lihatman c_rehash). Untuk GnuTLS sejak 3.3.6 (sebelum itu GnuTLS tidak memiliki dukungan direktori), itu hanya direktori dengan file PEM di dalamnya; GnuTLS akan mencoba dan memuat setiap file dalam direktori dan berhasil pada PEM-ish apa pun (tidak dapat menangani format 'sertifikat tepercaya' OpenSSL). Saya tidak benar-benar yakin apakah NSS benar-benar dapat menggunakan direktori yang penuh dengan file sertifikat individu sebagai trust root, tetapi dokumentasi OpenLDAP sepertinya menyarankan itu bisa (tetapi jika direktori tersebut juga berisi database NSS, ia akan memberikan prioritas itu). Apapun, RHEL tidak memiliki apa pun seperti direktori yang penuh dengan file sertifikat CA individu.

Debian dan turunannya menyediakan /etc/ssl/certsdalam format ini; /etc/ssl/certsadalah lokasi toko kepercayaan kanonik di Debian, dan IMO apa pun yang menyediakannya pada dasarnya harus menjabarkannya seperti milik Debian, karena Debian memiliki direktori yang ditata kurang lebih dengan cara yang sama sejak 1999. RHEL memiliki /etc/ssl/certsdirektori, tetapi masih dalam tidak dalam format ini - tidak mengandung file sertifikat individual sama sekali. Anda tidak dapat menggunakannya sebagai CApath. Jujur, di RHEL (dan Fedora, dan turunannya) direktori itu pada dasarnya adalah jebakan. Jangan gunakan itu. (Lihat https://bugzilla.redhat.com/show_bug.cgi?id=572725 dan https://bugzilla.redhat.com/show_bug.cgi?id=1053882untuk beberapa latar belakang mengapa itu ada di tempat pertama, dan bagaimana saya mencoba untuk memperbaikinya). Jadi saya pikir Anda benar tentang apa yang terjadi, tetapi salah tentang alasannya. OpenLDAP tidak melakukan kesalahan, dan itu tidak gagal karena "ca-bundle.trust.crt ... adalah basis data kunci / sertifikat Mozilla NSS" (yang disebut cert8/9.dbdan key3/4.db, dan yang di seluruh sistem di RHEL tinggal /etc/pki/nssdb) , itu hanya gagal karena /etc/ssl/certstidak dapat digunakan sebagai 'direktori sertifikat' sama sekali.

RHEL tidak menyediakan apa pun yang dapat digunakan sebagai toko kepercayaan gaya CApath di tempat lain, baik. Penyimpanan trust sistem RHEL disediakan sebagai file bundel PEM tunggal ('CAfile' dalam istilah OpenSSL), yang dapat ditemukan di /etc/pki/tls/certs/ca-bundle.crtdan /etc/pki/tls/cert.pem. Ini juga dapat ditemukan pada /etc/ssl/certs/ca-bundle.crtsaat /etc/ssl/certssebenarnya hanya symlink ke /etc/pki/tls/certs, tetapi lokasi itu tidak kanonik dan benar-benar tidak boleh digunakan oleh apa pun. RHEL juga menyediakan bundel dalam format 'sertifikat tepercaya' OpenSSL sebagai /etc/pki/tls/certs/ca-bundle.trust.crt.

Hal yang benar untuk dilakukan, seperti yang Anda ketahui, adalah menggunakan file bundel yang disediakan sistem. Jawaban Anda akan berhasil, tetapi untuk alasan yang disebutkan di atas, saya akan sangat menyarankan TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crtatau TLS_CACERT=/etc/pki/tls/cert.pemlebih TLS_CACERT=/etc/ssl/certs/ca-bundle.crt.

(Tidak ada yang baru dalam hal ini, btw, tetapi kebingungan pada jalinan luas. RH dan turunannya tidak pernah memberikan direktori-penuh-sertifikat, tidak pernah. Mereka telah menyediakan file bundel sejak tahun 2000. Itu adalah pindah dari / usr / share / ssl ke / etc / pki / tls pada tahun 2005. Debian memiliki keduanya /etc/ssl/certssebagai direktori gaya CApath dan /etc/ssl/certs/ca-certificates.crtsebagai file bundel kurang lebih sejak zaman batu.)

Adam Williamson
sumber
Jawaban ini layak mendapatkan banyak +1 karena detailnya.
Christopher Schultz
10

/etc/ssl/certs/berisi /etc/ssl/certs/ca-bundle.trust.crtsebagai bagian dari ca-certificates-2010.63-3.el6_1.5.noarch, yang merupakan basis data kunci / sertifikat Mozilla NSS. Dimasukkannya file ini di dalam TLS_CACERTDIRmenyebabkan semua file lainnya diabaikan.

TLS_CACERTDIR
Menentukan jalur direktori yang berisi sertifikat Otoritas Sertifikat dalam file terpisah. TLS_CACERT selalu digunakan sebelum TLS_CACERTDIR.` Parameter ini diabaikan dengan GnuTLS.

Saat menggunakan Mozilla NSS, mungkin berisi database kunci / sertifikat Mozilla NSS. Jika berisi basis data kunci / sertifikat Mozilla NSS dan file CA cert, OpenLDAP akan menggunakan basis data cert / key dan akan mengabaikan file CA cert.`

Namun, openldap-2.4.23-26.el6_3.2.i686sepertinya tidak menangani ini dengan benar.


Penggunaan Jawaban SingkatLDAPTLS_CACERT=/etc/ssl/certs/ca-bundle.crt
(file konfigurasi TLS_CACERT=/etc/ssl/certs/ca-bundle.crt)
File ini juga disertakan oleh ca-certificates-2010.63-3.el6_1.5.noarch.

84104
sumber
1

Orang lain mengalami hal ini; inilah yang bekerja untuk saya di centos 6 openldap dan sssd:

catatan: a. Beberapa "orang pintar" memutuskan untuk membuat sssd memerlukan TLS / SSL; perubahan perilaku dari centos5; ini bagus untuk sistem eksternal; tetapi ketika Anda memiliki 300 + node pada alat internal dengan jaringan internal yang tidak dapat dijangkau ke kluster mesin; ini adalah fitur keamanan yang sangat tidak berguna.

b. Lebih lanjut, sertifikat yang dinyanyikan sendiri tampaknya tidak berfungsi lagi; akan terus berusaha

c. Hindari NSLCD di semua biaya; diganggu dengan masalah non-stop ketika saya mengatur bendera warisan dan digunakan sebagai ganti sssd (netgroups; deadlocking syslog, dll.).

Untuk bangkit dan berjalan menggunakan sssd;

  1. sssd.conf

    [domain/default]
    ldap_id_use_start_tls = True
    id_provider = ldap
    auth_provider = ldap
    chpass_provider = ldap
    cache_credentials = True
    ldap_search_base = dc=local
    enumerate = True
    ldap_uri = ldap://192.168.1.2/
    ldap_tls_cacertdir = /etc/openldap/cacerts
    ldap_tls_reqcert = allow
    ldap_schema = rfc2307bis
    
  2. slapd.conf

    TLSCACertificateFile   /etc/openldap/cacerts/ca-bundle.crt
    TLSCertificateFile      /etc/openldap/cacerts/slapd.pem
    TLSCertificateKeyFile   /etc/openldap/cacerts/slapd.pem
    TLSCipherSuite HIGH:MEDIUM:-SSLv2
    
  3. ldap.conf

    URI ldap://192.168.1.2/
    BASE dc=local
    
    TLS_CACERTDIR /etc/openldap/cacerts
    
Zerobane
sumber
Saya tidak akan mengatakan itu fitur yang tidak berguna. Anda menghindari menjatuhkan internal atap untuk satu. Anda menghindari peralatan agar dapat memasuki lalu lintas di tempat yang tidak Anda inginkan. Ada sejumlah alasan mengapa ini tidak sia-sia.
Torxed
Di jaringan internal menjalankan 40gig-100gig? Serius? Apa yang akan Anda gunakan untuk mengetuk backend HPC? Hanya FYI; itu 1gigabyte data per detik. Ini adalah masalah dengan model keamanan paksa ... Itu membuat asumsi umum untuk semua pengguna akhir. Seperti yang baru saja Anda lakukan ... Pada model di mana saya menjalankan jaringan internal 100% milik; dengan MTU 16megabyte dan pipa mengerikan; 100% tidak berguna. Kami menggunakan model lain untuk keamanan dan tidak bergantung pada LDAP / TLS untuk mengenkripsi data yang sedang berjalan.
zerobane
Saya tidak masuk ke kontes kencing dengan penulis kepala panas di Internet. Tetapi jika Anda hanya mendorong pertunjukan per detik dan menjalankan 100-500 host saya benar - benar tidak melihat masalah di sini. Tentu TLS memang membutuhkan lebih banyak beban CPU tetapi ada cara untuk mengoptimalkan ini dan merestrukturisasi jaringan (sepertinya ini mungkin diperlukan jika overhead marginal dari TLS sangat mempengaruhi ini). Ini juga tidak dipaksakan pada Anda, pergi dengan perpustakaan yang kurang aman daripada sssdmisalnya.
Torxed
Tidak ada alasan untuk komentar dan serangan yang merendahkan; Mari tetap berpegang pada fakta. Pergi menebak Anda mengirimkan model keamanan paksa atau mendukung model. Hanya FYI; 1-2% di dunia HPC dianggap luar biasa. Itu bukan 100-500 host; jika Anda mempertimbangkan hosts = cpu; Anda berbicara lebih dari 10.000 host. Kami mungkin akan berakhir dengan kode percabangan atau kembali ke nslcd sebagai gantinya. Masalah dengan menggunakan model aman "kurang" adalah dukungan net-groups. Mengoptimalkan dan merestrukturisasi jaringan; lol; hanya perusahaan komputer super terkemuka; tentu beri tahu kami cara melakukannya dan tunjukkan kami patennya.
zerobane
0

Ini adalah masalah yang sangat umum, jangan khawatir saya punya jawaban untuk Anda.

Pertama RHEL Klon telah memiliki dua ldap.conffile, /etc/ldap.confatau di RHEL6 yang sudah ditinggalkan tetapi Anda dapat menggunakan /etc/nslcd.confuntuk otentikasi sekarang /etc/openldap/ldap.confhanya untuk permintaan , sehingga ldapsearch, ldapmodify, ldapremove, itu benar-benar profil Anda sehingga Anda tidak perlu memiliki string panjang jahat setiap kali Anda ingin untuk menjalankan perintah ldap.

Sekarang dengan itu, Anda memiliki dua parameter,

  • tls_cacertfile - secara eksplisit mendefinisikan sertifikat dan Anda harus baik untuk pergi
  • tls_cacertdir- masukkan ca cert ke dalam direktori tetapi itu tidak akan berfungsi, karena itu perlu di -hash ...

gunakan openssl x509 -hash -noout -in $file , ln -s $file $file.0, maka sertifikat CA Anda akan berfungsi.

Perhatikan juga jika file konfigurasi dalam CAPS, Anda bekerja di /etc/openldap/ldap.conf, mereka adalah file yang sangat berbeda.

Semoga ini jelas.

side_control
sumber
-1

Menurut halaman manual setiap orang yang saya lihat (tapi saya bukan pengguna CentOS) tidak ada yang namanya LDAPTLS_CACERTDIR. Variabel yang benar untuk ditetapkan adalah TLS_CACERTDIR. Anda harus mengaturnya secara permanen di /etc/openldap/ldap.confatau di mana pun CentOS menyimpan file konfigurasi pustaka LDAP. Juga, Anda mungkin perlu mengkonfigurasi pam-ldap sendiri untuk mencari sertifikat CA. Dalam CentOS ini /etc/pam_ldap.conf, saya pikir, dan variabel yang akan ditetapkan adalah tls_cacertdir.

daff
sumber
Saya mencoba metode file terlebih dahulu, tetapi memilih untuk menggunakan variabel shell untuk singkatnya. Jika Anda membaca halaman manualEnvironmental variables may also be used to augment the file based defaults. The name of the variable is the option name with an added prefix of LDAP. For example, to define BASE via the environment, set the variable LDAPBASE to the desired value.
84104
Anda tentu saja benar, salah saya. Saya tidak pernah membaca bagian halaman manual itu karena saya selalu menggunakan file konfigurasi. Saya sedang memindai halaman manual untuk mencari LDAPTLS_CACERTDIRdan tidak menemukan, jadi saya berasumsi Anda mencampuradukkan variabel Anda. Maaf.
daff