Я администрирую корпоративный веб-прокси, работающий под управлением Squid 3.5.10 на CentOS 7 (устройство Diladele), выполняю SSL-проброс, и у меня возникли некоторые проблемы с добавлением новых сертификатов CA в системное хранилище доверенных сертификатов, из-за чего наши пользователи не могут получить доступ к нескольким защищенным SSL сайтам, хотя они должны иметь к ним доступ. Один из таких сайтов —https://www.sexierdating.com/(да, это именно то, на что это похоже, но наша политика заключается в том, чтобы не беспокоиться о том, чем люди занимаются в интернете во время обеденного перерыва, если это законно).
Сообщение об ошибке от Squid обычное X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY, означающее, что по какой-то причине Squid не доверяет или не может проверить сертификат сервера назначения. До сих пор для решения проблемы было достаточно взять корневой сертификат CA в формате PEM со страниц поддержки CA, поместить его в /etc/pki/ca-trust/source/anchors, запустить update-ca-trustи перезапустить Squid, но в моем случае это не так. Пакет ca-certificates находится в текущей версии, так как я только что запустил целое обновление yum на машине.
Все домены, с которыми у меня сейчас проблемы, имеют сертификат "Go Daddy Secure Certificate Authority - G2". Я скачал каждый сертификат с их страницы поддержки (https://certs.godaddy.com/repository/), установил их, как описано выше, перезагрузил squid, но ошибка осталась. Я даже наблюдал за update-ca-trust с помощью strace, чтобы убедиться, что он действительно подбирает правильные файлы PEM — и он это делает.
Что меня немного смущает, так это то, что страница загрузки certs.godaddy.com, похоже, использует тот же самый корневой и промежуточный сертификат, что и некоторые проблемные домены, но эта страница отлично работает через Squid. Когда я сравниваю сертификаты в Firefox, я не вижу никакой разницы в общей спецификации и алгоритмах, но все равно один работает, а другой нет.
Я в тупике и надеюсь, кто-нибудь сможет подтолкнуть меня в правильном направлении, чтобы решить эту проблему. Я не могу добавить исключения прокси для каждой второй страницы с сертификатом GoDaddy..
решение1
Хранилища CA на компьютерах и в браузерах включают корневые сертификаты CA.
Сертификаты веб-сайтам НИКОГДА не должны выдаваться корневыми центрами сертификации, вместо этого их должен выдавать посредник.
Веб-сайт обязан возвращать как свой собственный сертификат, так и промежуточный сертификат, чтобы браузеры могли связать посредника с одним из корневых сертификатов, которым он доверяет.
В приведенном вами примере веб-сайта они не включают промежуточный сертификат, поэтому ваши пользователи не могут доверять сайту. Это можно увидеть с помощью сканирования ssllabs здесь:https://www.ssllabs.com/ssltest/analyze.html?d=www.sexierdating.com. Как вы видите, он отправляет только один сертификат вместо двух и получает неполное предупреждение из-за этого. Развернув раздел Certificate Paths, вы увидите полную цепочку и сможете загрузить этого посредника, если захотите его установить.
Следует отметить, что браузеры часто справляются с этой ситуацией — либо потому, что у них есть общие промежуточные кэшированные данные от посещения других сайтов, либо потому, что они пытаются найти отсутствующий промежуточный сертификат. Поэтому часто эти неправильные конфигурации не замечаются большинством пользователей и операторов сайтов. Предполагать, что ssl bumping здесь не совсем так дружелюбен к пользователю, чтобы обрабатывать эти ошибки.
Это отличается от certs.godaddycom (https://www.ssllabs.com/ssltest/analyze.html?d=certs.godaddy.com), который отправляет полную цепочку. На самом деле, у него обратная проблема, и он отправляет слишком много сертификатов, поскольку нет необходимости отправлять корневой сертификат (но, возможно, это связано с историческими причинами, поскольку вы можете видеть, что есть два пути цепочки сертификатов — один из которых требует, чтобы корневой сертификат был подписан другим сертификатом, что, вероятно, используется старыми браузерами, в хранилищах доверия которых нет нового корневого сертификата).
В любом случае, у вас есть следующие варианты:
- Сообщите своим пользователям, что проблема в неправильной настройке веб-сайта, и что им следует вернуться к работе и прекратить тратить рабочее время на просмотр сомнительных сайтов.
- Добавьте промежуточный сертификат в корневое хранилище Squid CA. Конечно, это не корневой CA и на самом деле не должен быть в хранилище, и если он когда-либо будет отозван по какой-либо причине, вы все равно будете доверять ему (это одна из причин, по которой сертификаты не выпускаются из корневых сертификатов, поскольку их очень сложно удалить из хранилищ доверия). Таким образом, вы создаете риск безопасности, включая это.
- Свяжитесь с сайтом, объясните им проблему и попросите ее исправить. А затем будьте готовы в основном устранять неполадки на каждом другом сломанном сайте, который хотят ваши пользователи!
Без сомнения, я бы выбрал вариант 1, если бы это был я :-)