Чому мені потрібно створити символічні посилання для сертифікатів?

Окрім того, як помітити щось подібне:

yourid@linuxtpf:~/certificates> ls -l
lrwxrwxrwx  1 yourid users   9 2009-04-07 18:06 50a694ac.0 -> cert2.pem #<-- was missing
lrwxrwxrwx  1 yourid users   9 2009-04-07 18:06 5170a0d9.0 -> cert3.pem #<-- was missing too...
-rw-------  1 yourid users 756 2009-04-07 18:02 cert2.pem
-rw-------  1 yourid users 747 2009-04-07 18:02 cert3.pem

відсутній на моєму сервері, і після додавання їх виправлені з'єднання LDAPS, які не вдалися на етапі ldap_bind у процесі з'єднання LDAP.

Що насправді відбувається і чому мені потрібно було створити символьні посилання для CAPATH, виконавши наступну команду?

yourid@linuxtpf:~/certificates> c_rehash /home/yourid/certificates

Оскільки деяке програмне забезпечення знаходить правильні ключі, заглянувши у налаштований каталог для файлу із заданим хешем сертифіката.

Хешинг створює посилання від ключа id до файлів із зрозумілими людьми іменами.

Машина хоче таких файлів. Якщо ви відкриєте сертифікат, ви побачите, що цифри відповідають хешу, наданому в сертифікаті. Це так, що канонічний хеш сертифіката відповідає імені файлу. Пам'ятайте: Сертифікат може містити кілька імен хостів і псевдонімів, але він має лише один хеш .

50a694ac.0
5170a0d9.0

Але я? Я людина, і ці імена важко розшифрувати. Тож я використовую символічні посилання, сприятливі до людини, як це:

www.example.org.pem -> 50a694ac.0 
wiki.example.org.pem -> 5170a0d9.0

Я мій досвід, назви www.example.org.pemта, wiki.example.org.pemяк правило, символічні посилання на файли, названі як 50a694ac.0. У вашому прикладі у вас було навпаки - імена, що стосуються людини, існували, але не були хешовані імена. Імена, прочитані людиною, іноді необов’язкові.