Estou usando este comando:
openssl s_client -connect example.com:443 -CAfile /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem Funciona. Se eu não especificar esse arquivo CA, recebo um código 20. O certificado está em /etc/ssl/certs e /usr/lib/ssl/certs -> /etc/ssl/certs Também está incluído no ca-certificates.crt
O que está governando se o openssl pode encontrar meu certificado ou não e como posso fazer com que ele aceite este certificado sem especificá-lo explicitamente?
Comentários
Resposta
Existe um bug OpenSSL conhecido em que s_client não verifica o armazenamento de certificados padrão quando você não passa no -CApath ou -CAfile. O OpenSSL no Ubuntu 14.04 sofre com esse bug, conforme demonstrarei:
Versão:
ubuntu@puppetmaster:/etc/ssl$ openssl version OpenSSL 1.0.1f 6 Jan 2014 Falha ao usar o armazenamento padrão quando eu não passe `-ca:
ubuntu@puppetmaster:/etc/ssl$ openssl s_client -quiet -connect gmail.com:443 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify error:num=20:unable to get local issuer certificate verify return:0 Agora, passo nulo como -CApath e funciona:
ubuntu@puppetmaster:/etc/ssl$ openssl s_client -quiet -connect gmail.com:443 -CApath /dev/null depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = mail.google.com verify return:1 Infelizmente, não acho que exista uma lista de versões afetadas do OpenSSL. A única maneira de saber é testá-la.
Comentários
- Obrigado. Eu estava usando essa versão. OpenSSL 1.1.0 não parece ter corrigido o problema. I ' m não vejo o problema listado aqui: github.com/openssl/openssl/issues Você pode mencionar o problema?
- É ' s no rastreador de problemas RT antigo . Há um patch lá, ele ' s por trás de um login (convidado: convidado) É ' s problema nº 3697, marcado como resolvido. rt.openssl.org/Ti cket / Display.html? id = 3697
- Ok, eu confirmei que isso foi corrigido no 1.1, pelo menos na bifurcação richsalz dele. Quando fiz a atualização, inicialmente não notei que o diretório base mudou para
/usr/local/ssl, que tinha um diretório certs não mapeado para/etc/ssl/certs. - Posso verificar se o bug existe no CentOS 6.8 (OpenSSL 1.0.1e-fips 11 de fevereiro de 2013).
- Além disso,
openssl version -dfornece o diretório de configuração básico …
Resposta
"How to get openssl to use a cert without specifying it via -CAfile". Eu tive o mesmo requerimento. Eu queria usar um diretório de CAs em que " confiava " localmente. Eu não queria nenhum resultado Trust store poluente padrão.
c_rehash
Antes de chamar o comando verify, a página de ajuda: man verify me orientou a usar c_rehash:
O rehash verifica os diretórios e calcula um valor hash de cada " .pem ", " .crt ", " .cer " ou " .crl " arquivo no lista de diretórios especificada e cria links simbólicos para cada arquivo
export CERTS=/Users/{path_to_your_certs} [path to openssl]/openssl/bin/c_rehash ${CERTS} Verificar um certificado folha
openssl verify -CApath ${CERTS} local_leaf.pem local_leaf.pem: OK Você carrega o Root CA e o IntCA dentro do diretório CERTS.Se eu não fizesse a etapa de refazer, receberia o erro 20 unable to get local issuer certificate.
GTE_CyberTrust_Global_Root.pemé uma CA intermediária? Em caso afirmativo, pode ser que o seu servidor web não esteja servindo aquele certificado CA intermediário junto com o certificado do seu site. Essa deficiência por parte do seu servidor da web pode causar problemas de compatibilidade com alguns computadores. Por outro lado, se oGTE_CyberTrust_Global_Root.pemfor um certificado raiz de nível superior, ele deve estar funcionando por padrão.opensslnão esteja configurado com nenhum certificado de raiz de nível superior? Você já tentougoogle.com:443?