Firefox не загружает цепочку сертификатов

Я бегу lighttpd/1.4.28 (ssl) на Debian Squeeze. Я только что создал сертификат http://startssl.com/, я отлично работаю на всех своих браузерах (Firefox, Chrome, Opera), но мои пользователи сообщают об ошибках сертификатов в Firefox. Я уже прибил его к неудачной загрузке цепочки сертификатов:

Сертификат на моем Firefox:
Сертификат у других Firefox: (обратите внимание на отсутствующие StartCOM-сертификаты здесь)

Я следовал этому руководству для встраивания сертификата в мой lighttpd: https://forum.startcom.org/viewtopic.php?t=719

Соответствующие части моего lighttpd.conf выглядят так:

$SERVER["socket"] == ":443" {
        ssl.engine = "enable"
        ssl.ca-file = "/etc/lighttpd/certs/ca-bundle.pem"
        ssl.pemfile = "/etc/lighttpd/certs/www.bisaboard.crt"
}

ca-bundle.pem был создан так: cat ca.pem sub.class1.server.ca.pem > ca-bundle.pem
Я взял соответствующие файлы отсюда: http://www.startssl.com/certs/

www.bisaboard.crt был создан так: cat certificate.pem ssl.key > www.bisaboard.crt
Где certificate.pem - это мой сертификат StartSSL-Class1, а ssl.key - мой SSL-Root-ключ.

Есть ли у вас идеи, почему второй Firefox некорректно загружает цепочку сертификатов?

Источник

5 ответов

Похоже, ваш веб-сервер неправильно отображает промежуточные сертификаты, потому что он работает в вашем собственном браузере, возможно, потому, что вы сами скачали и установили их локально.

Почему бы вам просто не скачать пакет услуг, который они уже подготовили для вас, по адресу http://www.startssl.com/certs/ca-bundle.crt и использовать его для ssl.ca-file вариант?

Источник

Firefox известен своей строгостью при проверке всей цепочки сертификатов, и, скорее всего, вы не указали все сертификаты в цепочке правильно. Недавно у меня была похожая проблема с Firefox и SSL-сертификатом Comodo на Lighttpd, и проблема заключалась в том, что я неправильно перечислял цепочку в файле ssl.ca.

В соответствии с RFC 2246 сертификат отправителя должен стоять первым, а каждый следующий сертификат должен непосредственно подтверждать предыдущий. Я получил четыре сертификата в цепочке вплоть до корневого центра сертификации.

certificate_list Это последовательность (цепочка) сертификатов X.509v3. Сертификат отправителя должен стоять первым в списке. Каждый следующий сертификат должен непосредственно подтверждать предыдущий. Поскольку проверка сертификата требует, чтобы корневые ключи распространялись независимо, самозаверяющий сертификат, который определяет корневой центр сертификации, может быть опущен из цепочки, при условии, что удаленный конец должен уже обладать им для проверки его в любом случае.

Источник

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

Сегодня я пришел в офис, и половина наших компаний / клиентов увидела это предупреждение о безопасности браузера в своих браузерах.

Даже с той же развернутой версией Firefox ESR здесь, в компании?!

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

Полностью забыл о проблемах SHA1 у StartCom остро.

Получите проверенный промежуточный сертификат SHA2 для текущего домена 1 класса (в моем случае): https://www.startssl.com/certs/sca.server1.crt, замените его старым onesub.class1.server.ca.pem, перезапустите веб-сервер (Apache на моем конце), и он будет работать во всех браузерах.

Источник

У меня была проблема с точно таким же поведением: некоторые Firefox жаловались на отсутствующую цепочку, но не на все. Добавление дополнительного параметра цепочки сертификатов (и файла, который содержал все сертификаты один за другим) в конфигурации сервера, казалось, помогло. Я использую Apache Traffic Server самостоятельно.

Это решение также предлагает SSLhopper в ссылке в комментариях: http://www.sslshopper.com/ssl-checker.html

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

Источник

У меня была такая же проблема (с использованием node.js), и решение было добавить sub.class1.server.ca.pem подать в ssl.crt файл.

Просто скопируйте содержимое sub.class1.server.ca.pem в ssl.crt убедившись, что один находится под другим без промежутков между ними, и он должен работать.

Вы можете прочитать больше об этом здесь.

Источник
Другие вопросы по тегам