Trên thực tế, RHEL không cung cấp bất cứ thứ gì có thể được sử dụng như một 'thư mục chứng chỉ' cho mục đích tin cậy CA. Đối với OpenSSL, thư mục chứng chỉ - 'CApath' - là thư mục chứa các tệp chứng chỉ riêng lẻ (ở định dạng PEM hoặc định dạng 'chứng chỉ tin cậy' mở rộng của OpenSSL), với các tên ở định dạng cụ thể dựa trên hàm băm của tên chủ đề của chứng chỉ. Thông thường điều này đạt được bằng cách đặt các tệp có tên người đọc được và.pem phần mở rộng trong một thư mục và chạy c_rehashtrên đó (xemman c_rehash). Đối với GnuTLS kể từ 3.3.6 (trước đó GnuTLS không có hỗ trợ thư mục), đó chỉ là một thư mục chứa các tệp PEM trong đó; GnuTLS sẽ thử và tải mọi tệp trong thư mục và thành công trên mọi thứ PEM-ish (nó không thể xử lý định dạng 'chứng chỉ tin cậy' của OpenSSL). Tôi thực sự không chắc chắn nếu NSS thực sự có thể sử dụng một thư mục chứa đầy đủ các tệp chứng chỉ riêng lẻ làm gốc tin cậy bằng cách nào đó, nhưng tài liệu của OpenLDAP dường như đề xuất nó có thể (nhưng nếu thư mục cũng chứa cơ sở dữ liệu NSS thì nó sẽ ưu tiên cho điều đó). Bất kể, RHEL không có bất cứ thứ gì như một thư mục chứa đầy các tệp chứng chỉ CA riêng lẻ.
Debian và các dẫn xuất cung cấp /etc/ssl/certsở định dạng này; /etc/ssl/certslà vị trí cửa hàng ủy thác chính tắc trên Debian và IMO bất cứ thứ gì cung cấp về cơ bản nên đặt nó giống như của Debian, vì thư mục của Debian được đặt theo cách tương tự như năm 1999. RHEL có một /etc/ssl/certsthư mục, nhưng nó nằm trong không ở định dạng này - nó hoàn toàn không chứa bất kỳ tệp chứng chỉ riêng lẻ nào. Bạn không thể sử dụng nó như một CApath. Thành thật mà nói, trên RHEL (và Fedora, và các dẫn xuất) thư mục đó về cơ bản là một cái bẫy. Đừng sử dụng nó. (Xem https://ormszilla.redhat.com/show_orms.cgi?id=572725 và https://ormszilla.redhat.com/show_orms.cgi?id=1053882đối với một số nền tảng về lý do tại sao nó tồn tại ở nơi đầu tiên và cách tôi cố gắng sửa nó). Vì vậy, tôi nghĩ rằng bạn đúng về những gì đang xảy ra, nhưng sai về lý do tại sao. OpenLDAP không làm gì sai cả và nó không thất bại vì "ca-bundle.trust.crt ... là một cơ sở dữ liệu / chứng chỉ Mozilla NSS" (những người được gọi cert8/9.dbvà key3/4.db, và những người trên toàn hệ thống trên RHEL sống /etc/pki/nssdb) , nó chỉ thất bại bởi vì/etc/ssl/certs không thể sử dụng như một 'thư mục chứng chỉ'.
RHEL không cung cấp bất cứ thứ gì có thể sử dụng như một cửa hàng ủy thác kiểu CApath ở bất kỳ nơi nào khác. Cửa hàng ủy thác hệ thống của RHEL được cung cấp dưới dạng tệp bó PEM duy nhất ('CAfile' theo thuật ngữ OpenSSL), có thể được tìm thấy tại /etc/pki/tls/certs/ca-bundle.crtvà /etc/pki/tls/cert.pem. Nó cũng có thể được tìm thấy /etc/ssl/certs/ca-bundle.crtvì /etc/ssl/certsthực sự chỉ là một liên kết tượng trưng /etc/pki/tls/certs, nhưng vị trí đó không hợp quy và thực sự không nên được sử dụng bởi bất cứ điều gì bao giờ. RHEL cũng cung cấp một gói ở định dạng 'chứng chỉ tin cậy' của OpenSSL như /etc/pki/tls/certs/ca-bundle.trust.crt.
Điều chính xác cần làm, như bạn đã tìm ra, là sử dụng tệp bó mà hệ thống cung cấp. Câu trả lời của bạn sẽ hoạt động, nhưng vì những lý do nêu trên, tôi rất muốn giới thiệu TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crthoặc TLS_CACERT=/etc/pki/tls/cert.pemhơn TLS_CACERT=/etc/ssl/certs/ca-bundle.crt.
. đã chuyển từ / usr / share / ssl sang / etc / pki / tls vào năm 2005. Debian đã có cả /etc/ssl/certsthư mục kiểu CApath và /etc/ssl/certs/ca-certificates.crtdưới dạng tệp bó ít nhiều kể từ thời kỳ đồ đá.)