Como alguns softwares encontram as chaves corretas procurando no diretório configurado um arquivo com um determinado hash de certificado.
O hashing cria links simbólicos a partir do id da chave para os arquivos com nomes legíveis por humanos.
Além de perceber algo assim:
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
estava faltando no meu servidor e depois de adicioná-los conexões LDAPS fixas que estavam falhando no estágio ldap_bind no processo de conexão LDAP.
O que realmente está acontecendo e por que preciso criar links simbólicos para o CAPATH executando o seguinte comando?
yourid@linuxtpf:~/certificates> c_rehash /home/yourid/certificates
Como alguns softwares encontram as chaves corretas procurando no diretório configurado um arquivo com um determinado hash de certificado.
O hashing cria links simbólicos a partir do id da chave para os arquivos com nomes legíveis por humanos.
A máquina quer arquivos como este. Se você abrir o certificado, verá que os números correspondem ao hash fornecido no certificado. Isso é para que o hash canônico do certificado corresponda ao nome do arquivo. Lembre-se: um certificado pode conter vários nomes de host e alias, mas tem somente um hash .
50a694ac.0
5170a0d9.0
Mas eu? Eu sou um humano e esses nomes são difíceis de decifrar. Então, eu uso links simbólicos para humanos assim:
www.example.org.pem -> 50a694ac.0
wiki.example.org.pem -> 5170a0d9.0
Na minha experiência, os nomes www.example.org.pem e wiki.example.org.pem são geralmente links simbólicos para os arquivos nomeados como 50a694ac.0 . No seu exemplo, você tinha o oposto - os nomes humanos amigáveis existiam, mas não os nomes com hash. Os nomes legíveis por humanos são às vezes opcionais.