Кроме того, чтобы заметить что-то вроде этого:
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
Поскольку некоторое программное обеспечение находит правильные ключи, просматривая в настроенном каталоге файл с заданным хешем сертификата.
Хеширование создает символические ссылки от идентификатора ключа к файлам с понятными для человека именами.
Машине нужны такие файлы. Если вы откроете сертификат, вы увидите, что числа соответствуют хешу, указанному в сертификате. Это сделано для того, чтобы канонический хэш сертификата совпадал с именем файла. Помните: сертификат может содержать несколько имен хостов и псевдонимов, но он имеет только один хеш.
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. В вашем примере у вас было противоположное - существовали понятные для человека имена, но не хешированные имена. Имена, удобочитаемые человеком, иногда необязательны.