5

Фон:

  • 64-битная версия Ubuntu Server 14.10 на aws.amazon.com/ec2
  • Дешевый сертификат сервера PositiveSSL от COMODO
  • 1 сертификат сервера, 2 промежуточных сертификата CA и 1 корневой сертификат CA в виде ZIP-архива от COMODO
  • Цитадель WebCit httpsd

Проблема:

Связанная цепочка сертификатов кажется правильной, но проверка не удалась.

openssl s_client myhost:port

показывает цепочку сертификатов и пары эмитент-субъект правильно выстраиваются в цепочке, но:

verify error:num=19:self signed certificate in certificate chain

Сертификат корневого ЦС не принимается openssl, хотя по умолчанию он находится в доверенном хранилище сервера Ubuntu.

В частности:AddTrustExternalCARoot.crt полученный по электронной почте от COMODO, и /etc/ssl/certs/AddTrust_External_Root.pem который ссылается на /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt являются идентичными.

Что здесь не так?

3 ответа3

4

OpenSSL, по крайней мере, через current (1.0.2a), содержит ошибку, в которой s_client с аргументом NO -CA{path,file} фактически не использует хранилище доверенных сертификатов по умолчанию, как это должно быть, и поэтому не может проверить сертификаты, действительные в соответствии с этим хранилищем доверенных сертификатов. , (Также s_server и s_time , но забота о проверке в них редка.) См. Https://serverfault.com/questions/607233/how-to-make-openssl-s-client-using-default-ca . Исправление объявляется в dev, но может потребоваться некоторое время для его выпуска и распространения. В то же время вам нужно явно указать аргумент (ы) -CA* . Обратите внимание, что openssl verify не имеет этой ошибки, и поэтому правильно сообщило, что сертификат / цепочка действительный.

ОБНОВЛЕНИЯ 2015/08/26: исправление было выпущено 2015/06/12 в версиях 1.0.1o и 1.0.2c. Кроме того, исследуя что-то еще, я обнаружил, что пакеты RedHat могли быть в порядке. Точнее, исходная RPM -версия CentOS для openssl-1.0.1e-30.el6.11 которая, как я понимаю, является копией RedHat (но не может легко подтвердить), содержит openssl-1.0.1c-default-paths.patch который содержит изменения в s_client.c s_server.c s_time.c от 2012/12/06, которые выглядят эквивалентно (хотя и не совпадают по тексту) вышестоящим исправлениям 2015/06/12. Предполагая, что этот патч был применен в пакетах RedHat и CentOS, и я не могу легко вернуться и проверить, они будут (работать), как и ожидалось.

3

Недавно я столкнулся с аналогичной проблемой с сертификатами Comodo при разработке сценария с использованием Ruby. В конце концов, у OpenSSL его не было в магазине, хотя все выглядело так.

Чтобы проверить это, загрузите все промежуточные сертификаты Comodo и создайте набор сертификатов примерно так (вам нужно использовать разные имена сертификатов в зависимости от того, что вы загрузили):

cat EssentialSSLCA_2.crt ComodoUTNSGCCA.crt UTNAddTrustSGCCA.crt AddTrustExternalCARoot.crt > yourDomain.ca-bundle

У Comodo есть статья о том, как это сделать.

После этого попробуйте снова проверить сертификат с помощью OpenSSL и указать хранилище сертификатов в командной строке:

openssl verify -untrusted yourDomain.ca-bundle cert.pem

Этот пример был адаптирован из этой статьи о Unix и Linux StackExchange.

После того, как вы определили, какой это сертификат, можно добавить сертификат в локальное хранилище сертификатов, которое подробно описано здесь для Ubuntu, и выглядит примерно так:

Создайте каталог для дополнительных сертификатов CA в /usr /share /ca-сертификаты

sudo mkdir /usr/share/ca-certificates/extra

Скопируйте файл .crt в каталог

sudo cp foo.crt /usr/share/ca-certificates/extra/foo.crt

Пусть Ubuntu добавит путь к файлу .crt относительно /usr /share /ca-сертификаты в /etc/ca-certificates.conf

sudo dpkg-reconfigure ca-certificates
0

Корневой сертификат comodo больше не является доверенным - поищите в Google "сертификат украденный comodo", если вы не знаете, почему.

Хотя сертификат comodo может быть дешевым, его стоимость намного ниже его цены: он фактически бесполезен, цепь доверия разорвана.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .