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