Por que não consigo verificar esta cadeia de certificados?


16

Eu tenho três certificados em uma cadeia:

  • root.pem
  • intermediário.pem
  • john.pem

Quando os examino, openssl x509 -in [filename] -text -noouteles parecem bem, o root.pem parece autoassinado (Emissor == Assunto), e o Assunto de cada certificado é o Emissor do próximo, conforme o esperado.

E, de fato, posso verificar a cadeia até o certificado intermediário:

$ openssl verify -CAfile root.pem root.pem
root.pem: OK
$ openssl verify -CAfile root.pem intermediate.pem
intermediate.pem: OK

No entanto, john.pem falha:

$ openssl verify -CAfile root.pem -CAfile intermediate.pem john.pem
john.pem: C = CL, [...redacted data...]
error 2 at 1 depth lookup:unable to get issuer certificate

Que eu saiba, isso significa que o openssl não consegue encontrar o emissor do intermediário.pem. O que não faz sentido, pois o root.pem é realmente o emissor do intermediário.pem.

o que estou perdendo?


Edit: Originalmente, eu tinha postado uma resposta dizendo que root.pem e intermediário.pem devem ser concatenados em um arquivo e, em seguida, deve-se usar esse arquivo como parâmetro para -CAfile. Isso está errado, porque confia implicitamente no intermediário.pem, como Johannes Pille aponta. Leia o link que ele postou na minha resposta excluída: https://mail.python.org/pipermail/cryptography-dev/2016-August/000676.html


Por favor, apague sua resposta, é desinformação perigosa!
Johannes Pille

1
@JohannesPille Feito, obrigado pela informação
Jong Bor

Parabéns por realmente fazê-lo e a reação rápida.
Johannes Pille

Respostas:


14

Você não precisa reunir os dois certificados juntos para verificá-los.

Se você possui os três certificados a seguir:

  • root.pem - armazena um certificado autoassinado.
  • intermediário.pem - armazena um certificado assinado por root.pem
  • john.pem - armazena um certificado assinado por intermediário.pem

E você confia apenas no root.pem, verifique john.pemcom o seguinte comando:

openssl verify -CAfile root.pem -untrusted intermediate.pem john.pem

Se você tivesse muitos intermediários, você poderia apenas encadear -untrusted intermediate2.pem -untrusted intermediate3.pem ...


Este. É a única resposta certa.
Johannes Pille

Eu pensei que, se eu tivesse os Certificados CA intermediário e raiz no pacote openssl, os pegaria e verificaria os certificados. Existe uma razão para isso estar acontecendo? Tipo, a pessoa que assinou o certificado de usuário não o assinou com o Intermediário, mas com a raiz, ou algo assim?
FilBot3

A última frase desta resposta está errada. Se você tiver muitos intermediários, precisará concatená-los em um arquivo intermediário e use o untrustedsinalizador uma vez. Usar o sinalizador não confiável várias vezes não funciona.
AjaxLeung 11/07/19

1
@AjaxLeung - as várias -untrustedopções (em qualquer ordem) ou uma única -untrustedopção apontando para um pacote de intermediários (concatenadas em qualquer ordem) funcionam. Isso ocorre com o OpenSSL versão 1.1.1c no Ubuntu.
garethTheRed 19/01

Sim, eu estava enganado. Acho que não estava usando os arquivos certos no momento em que escrevi o comentário.
AjaxLeung 19/01

3

o que @antiduh disse que só funciona para um caso de certificado intermediário único para mim. Ao adicionar mais de um -untrusted intermediate.pemno comando, parece não funcionar. Não tenho certeza se está relacionado à versão específica do openssl.

De acordo com o documento openssl: [ https://linux.die.net/man/1/verify]

arquivo não confiável

Um arquivo de certificados não confiáveis. O arquivo deve conter vários certificados

No meu caso, eu tenho uma cadeia como: root.pem -> intermediate1.pem -> intermediate2.pem -> john.pem

por cat intermediário1.pem e intermediário2.pem em um único arquivo intermediário-chain.pem e, em seguida, execute as openssl verify -CAfile root.pem -untrusted intermediate-chain.pem john.pemobras para mim.

Também parece a extensão CA que você precisa definir, basicConstraints = CA:truecaso contrário ainda encontro o openssl Verifique o erro do relatório.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.