Почему я не могу проверить эту цепочку сертификатов?


16

У меня есть три сертификата в цепочке:

  • root.pem
  • intermediate.pem
  • john.pem

Когда я проверяю их, используя, openssl x509 -in [filename] -text -nooutони выглядят нормально, root.pem выглядит так, как будто он самоподписан (Issuer == Subject), и субъект каждого сертификата является эмитентом следующего, как и ожидалось.

И действительно, я могу проверить цепочку до промежуточного сертификата:

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

Однако john.pem не работает:

$ 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

Насколько мне известно, это означает, что openssl не может найти эмитента для файла middle.pem. Что не имеет смысла, так как root.pem действительно является издателем для middle.pem.

Что мне не хватает?


Редактировать: я первоначально опубликовал ответ о том, что root.pem и промежуточный.pem должны быть объединены в один файл, а затем следует использовать этот файл в качестве параметра для -CAfile. Это НЕПРАВИЛЬНО, потому что это неявно доверяет промежуточному каналу, как указывает Йоханнес Пилле . Прочитайте ссылку, которую он разместил в моем удаленном ответе: https://mail.python.org/pipermail/cryptography-dev/2016-August/000676.html


Пожалуйста, удалите свой ответ, это опасная дезинформация!
Йоханнес Пилле

1
@JohannesPille Готово, спасибо за информацию
Jong Bor

Слава за то, что на самом деле это сделал и быстрая реакция.
Йоханнес Пилле

Ответы:


14

Вам не нужно связывать два сертификата вместе, чтобы проверить их.

Если у вас есть следующие три сертификата:

  • root.pem - хранит самоподписанный сертификат.
  • middle.pem - хранит сертификат, подписанный root.pem
  • john.pem - хранит сертификат, подписанный Middle.pem

И вы доверяете только root.pem, тогда вы проверите john.pemследующую команду:

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

Если у вас было много промежуточных звеньев, вы могли бы просто цепочку -untrusted intermediate2.pem -untrusted intermediate3.pem ...


Этот. Это единственный правильный ответ.
Йоханнес Пилле

Я думал, что если бы в комплекте были и промежуточные, и корневые сертификаты CA, они opensslбы их забрали и проверили. Есть ли причина, по которой это происходит? Например, тот, кто подписал сертификат пользователя, подписал его не Intermediate, а рутом, или что-то еще?
FilBot3

Последнее предложение этого ответа неверно. Если у вас много промежуточных звеньев, вам нужно объединить их в один промежуточный файл, а затем использовать untrustedфлаг один раз. Многократное использование ненадежного флага не работает.
AjaxLeung

1
@AjaxLeung - работает как несколько -untrustedвариантов (в любом порядке), так и один -untrustedпараметр, указывающий на связку промежуточных продуктов (объединенных в любом порядке). Это с OpenSSL версии 1.1.1c в Ubuntu.
garethTheRed

Да, я ошибся. Я думаю, что я просто не использовал нужные файлы, когда писал комментарий.
AjaxLeung

3

То, что сказал @antiduh, работает только для одного случая промежуточного сертификата для меня. Добавление более одного -untrusted intermediate.pemв команду, кажется, не работает. Не уверен, что это связано с конкретной версией openssl.

Согласно документу openssl: [ https://linux.die.net/man/1/verify]

недоверенный файл

Файл недоверенных сертификатов. Файл должен содержать несколько сертификатов

В моем случае у меня есть такая цепочка: root.pem -> intermediate1.pem -> intermediate2.pem -> john.pem

кошкой промежуточный. промежуточный и промежуточный2.pem в один файл промежуточный-chain.pem и затем запустить openssl verify -CAfile root.pem -untrusted intermediate-chain.pem john.pemработает для меня.

Также кажется, что расширение in ca нужно установить, basicConstraints = CA:trueиначе я все еще сталкиваюсь с сообщением об ошибке openssl verify.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.