Фон:
- Ubuntu Server 14.10 64-бит на aws.amazon.com/ec2
- Дешевый сертификат сервера PositiveSSL от COMODO
- 1 сертификат сервера, 2 промежуточных сертификата CA и 1 сертификат корневого CA в виде ZIP-архива от COMODO
- Citadel's 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
идентичны.
Что здесь не так?
решение1
OpenSSL по крайней мере до текущей версии (1.0.2a) имеетошибкагде s_clientбез -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которого, как я понимаю, является копией RPM 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, к которым я не могу легко вернуться и проверить, они бы работали, как и ожидалось.
решение2
Недавно я столкнулся с похожей проблемой с сертификатами 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
Этот пример был адаптирован изэта статья StackExchange для Unix и Linux.
После того, как вы определили, какой это сертификат, вы сможете добавить его в локальное хранилище сертификатов.который подробно описан здесь для Ubuntu, и что-то вроде:
Создайте каталог для дополнительных сертификатов CA в /usr/share/ca-certificates
sudo mkdir /usr/share/ca-certificates/extra
Скопируйте файл «.crt» в каталог
sudo cp foo.crt /usr/share/ca-certificates/extra/foo.crt
Позвольте Ubuntu добавить путь к файлу «.crt» относительно /usr/share/ca-certificates в /etc/ca-certificates.conf
sudo dpkg-reconfigure ca-certificates
решение3
Корневой сертификат Comodo больше не является доверенным — погуглите «украденный сертификат Comodo», если не знаете почему.
Хотя сертификат Comodo может быть дешевым, его ценность намного меньше его цены: по сути, он бесполезен, цепочка доверия разорвана.