Como listar os certificados, confiados pelo OpenSSL?
tanto quanto sei, qualquer software que trabalhe com certificados X. 509 pode ter uma base própria para decidir se um certificado é de confiança ou não.
AFAIK OpenSSL apenas Consulta uma lista (como, por exemplo, /etc/ssl/certs) e verifica se o certificado está lá presente.
Há alguma forma do OpenSSL listar todos os certificados em que confia? Eu sei que eu posso consultar esse arquivo eu mesmo (sobre a minha instalação particular do OpenSSL), mas há uma maneira (instalação-independente) de obter a lista de confiança do próprio OpenSSL?3 answers
Não, o OpenSSL não confia em nada por defeito. Tens de lhe dizer no que confiar. Há até um tópico FAQ que o cobre: Porque é queAFAIK OpenSSL apenas Consulta uma lista (como, por exemplo, /etc/ssl/certs) e verifica se o certificado está lá presente.
<SSL program> falha com um erro de verificação do certificado?:
Este problema é normalmente indicado por mensagens de registo a dizer algo. como "incapaz de obter o certificado de emitente local" ou "auto-assinado" certificado". Quando um certificado é verificado, a sua AC raiz deve ser "confiável" pelo OpenSSL isso normalmente significa que o certificado da AC deve ser colocado em um diretório ou arquivo e o programa relevante configurado para ler. O programa OpenSSL 'verificar' comporta-se de forma semelhante e emite mensagens de erro semelhantes: verifique a página de manual do programa verificar (1) para mais informações.
Também pode testar a sua ligação ao Google para ver como o OpenSSL se comporta:
$ openssl s_client -connect google.com:443
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
...
Start Time: 1407377002
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Aviso o acima falha porque o OpenSSL não confia em GeoTrust Global CA por omissão. Na verdade, há outro ponto de confiança na cadeia que é o Google Internet Authority G2 .
Pode remediar a situação dizendo ao OpenSSL em que confiar. Abaixo, eu uso a opção-CAfile com Google Internet Authority G2:
$ openssl s_client -connect google.com:443 -CAfile google-ca.pem
CONNECTED(00000003)
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 = google.com
verify return:1
...
Start Time: 1407377196
Timeout : 300 (sec)
Verify return code: 0 (ok)
cacert.pem. cacert.pem tem muitos CAs em it:
$ openssl s_client -connect google.com:443 -CAfile cacert.pem
CONNECTED(00000003)
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 = google.com
verify return:1
...
Start Time: 1407377356
Timeout : 300 (sec)
Verify return code: 0 (ok)
$ cat cacert.pem | grep -o "\-\-\-\-\-BEGIN" | wc -l
153
O modelo de segurança do OpenSSL está em contraste com o modelo de segurança do aplicativo/navegador web, onde o navegador carrega uma lista de âncoras de confiança ou pontos de confiança conhecidos como autoridades do certificado (CAs). Nota : neste modelo, a AC errada poderia afirmar certificar um site, e o navegador não seria mais sábio.
Isto aconteceu em o passado, e é provável que volte a acontecer no futuro. Para uma boa história de negócios engraçados PKIX, veja a história de risco de CAcert . Por exemplo, você conhece a Google Internet Authority G2 e O GeoTrust Global CA certifica os sites do Google. Não há razão para uma AC neerlandesa chamada Diginotar reivindicar a sua certificação, ou uma agência francesa de Defesa Cibernética reivindicar a sua certificação.Relacionado com modelos de Segurança: outro problema com a web o modelo app / browser é que você não pode empacotar a âncora de confiança ou AC necessária para a sua aplicação e usá-la (assumindo que tem um canal de distribuição de confiança). Os teus certificados são atirados para a pilha com o Zoo da CA. Outros ainda podem reivindicar certificar seu site, e você pode reivindicar certificar outros sites.
O modelo de segurança é uma das razões pelas quais os aplicativos web são relegados para dados de baixo valor. Os aplicativos Web não devem lidar com dados de valor médio ou de alto valor porque não podemos colocar o necessário controlos de segurança.Há alguma forma do OpenSSL listar todos os certificados em que confia?
Não é necessário uma vez que a lista tem 0 membros:)
Ver também como descobrir a localização do certificado de confiança do openssl?.
Estive recentemente a ver isto, e não encontrei maneira de obter o OpenSSL para listar os certificados no seu conjunto de confiança. A melhor maneira que eu encontrei foi, como você aponta, "consultar esse arquivo [/etc/ssl / certs] eu mesmo (na minha instalação particular do OpenSSL)".
Você pode ser mais independente da instalação sobre encontrar o diretório que o OpenSSL consulta. Imprime o caminho para ele.
% openssl version -d
OPENSSLDIR: "/opt/local/etc/openssl"
O OpenSSL procura aqui um ficheiro chamado cert.pem e uma subdiretoria certs/. Certificados que encontra são tratados como confiáveis por openssl s_client e openssl verify (fonte: o artigo, que autoridades de certificação o OpenSSL reconhece?).
% find -H `openssl version -d | sed -E 's/OPENSSLDIR: "([^"]*)"/\1/'`/(cert.pem|certs) \
-type f -exec cat {} \+
Isto imprime todo o conteúdo dos ficheiros que o OpenSSL espera que contenham certificados. Se você quiser menos do que o arquivo inteiro, então substitua cat com os comandos apropriados.
Se eu me submeter: $ openssl S_ Client-connect google.com:443
Funciona com sucesso, recupera 4 certs totais e devolve:
Start Time: 1484661709
Timeout : 300 (sec)
Verify return code: 0 (ok)
Acredito que isto é porque os servidores devem ser configurados para enviar, juntamente com o certificado, quaisquer certificados intermédios e root que sejam necessários para verificar a cadeia completa, certo?